... | ... | @@ -62,20 +62,17 @@ We recommend the following usage of the OHR project functionality: |
|
|
Think of issues as "tickets" they allow you to plan tasks and future
|
|
|
features, as well as to be used for bug tracking.
|
|
|
- For any problem found, create an Issue.
|
|
|
- Show in the title on which version a problem appeared, like "V1
|
|
|
- power connector wrong".
|
|
|
- Set the Target version for the Issue (see *Roadmap*).
|
|
|
- Show in the title on which version a problem appeared, like "V1 - power connector wrong".
|
|
|
- Set the Milestone for the Issue (see *Roadmap*).
|
|
|
- When it's resolved, let the engineer who solved it add comments
|
|
|
and set the Issue status to *Resolved*.
|
|
|
- Then the project manager will verify if everything is OK (he may
|
|
|
verify things like if the documentation is updated and other
|
|
|
actions to be taken). Once he agrees, he may set the Issue
|
|
|
status to *Closed*.
|
|
|
4. The **Roadmap** tab will appear when Versions have been defined in
|
|
|
the Setting tab. This may be helpful to track when Issues have been
|
|
|
solved and gives a very nice overview (see [SVEC
|
|
|
Roadmap](https://www.ohwr.org/project/svec/roadmap?completed=1)).
|
|
|
For this the Issues need to have a "Target version" set.
|
|
|
4. The **Milestone** tab will be helpful to track when Issues have been
|
|
|
solved and gives a very nice overview.
|
|
|
For this to work the Issues need to have a "Milestone" set.
|
|
|
5. The **Discourse forum** is the preferred way of communication.
|
|
|
6. Use Git for all kinds of files
|
|
|
requiring **version management**: HDL and software/firmware,
|
... | ... | |