... | @@ -34,34 +34,46 @@ Redmine provides the following modules per Project |
... | @@ -34,34 +34,46 @@ Redmine provides the following modules per Project |
|
|
|
|
|
## Recommended setup & usage
|
|
## Recommended setup & usage
|
|
|
|
|
|
We recommend the following usage:
|
|
We recommend the following usage of the OHR project functionality:
|
|
|
|
|
|
1. Use the issues tracker to create issues, tasks, milestones and
|
|
1. Use the **Wiki** for storing the information you want to conserve
|
|
|
|
about your project, but for which you don't have specific documents;
|
|
|
|
meeting minutes, informal, high-level descriptions, objectives, etc.
|
|
|
|
Also, the wiki is the entry place for most people into the project,
|
|
|
|
so it's good to have a quick intro and a status table in it. Here's
|
|
|
|
an [example](https://www.ohwr.org/project/spec/wiki) (sample source
|
|
|
|
code at attachment:spec\_wiki.txt).
|
|
|
|
2. Use the **News** section for publishing important events, such as a
|
|
|
|
new exposition or review meeting.
|
|
|
|
3. Use the **Issues tracker** to create issues, tasks, milestones and
|
|
deadlines for your project, and assign it to your team members.
|
|
deadlines for your project, and assign it to your team members.
|
|
Think of issues as "tickets" they allow you to plan tasks and future
|
|
Think of issues as "tickets" they allow you to plan tasks and future
|
|
features, as well as to be used for bug tracking.
|
|
features, as well as to be used for bug tracking.
|
|
2. The mailing list is the preferred way of communication, but you can
|
|
- For any problem found, create an Issue
|
|
also use forums.
|
|
- When it's resolved, let the engineer who solved it add comments
|
|
3. Use subversion (SVN) or Git for all kinds of files requiring version
|
|
and set the Issue status to *Resolved*.
|
|
management: HDL and software/firmware, schematics, PCB layout,
|
|
- Then the project manager will verify if everything is OK (he may
|
|
manufacturing files, etc.
|
|
verify things like if the documentation is updated and other
|
|
4. Use the Documents module for providing "release" versions of
|
|
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.
|
|
|
|
5. The **mailing list** is the preferred way of communication, but you
|
|
|
|
can also use forums.
|
|
|
|
6. Use subversion (SVN) or Git for all kinds of files requiring
|
|
|
|
**version management**: HDL and software/firmware, schematics, PCB
|
|
|
|
layout, manufacturing files, etc.
|
|
|
|
7. Use the **Documents** module for providing "release" versions of
|
|
Documents; Typically you would show versions 1.0, 2.0 and 3.0 on the
|
|
Documents; Typically you would show versions 1.0, 2.0 and 3.0 on the
|
|
Documents section, and all the intermediate steps (1.1, 2.3.1, etc)
|
|
Documents section, and all the intermediate steps (1.1, 2.3.1, etc)
|
|
would be managed via the SVN.
|
|
would be managed via the SVN.
|
|
5. Similarly, use the Files section for "release" versions of important
|
|
8. Similarly, use the **Files** section for "release" versions of
|
|
files, such as binary installation programs, drivers, schematics,
|
|
important files, such as binary installation programs, drivers,
|
|
gerber files, firmware etc. Again, intermediate versions of these
|
|
schematics, gerber files, firmware etc. Again, intermediate versions
|
|
should be managed via subversion.
|
|
of these should be managed via subversion.
|
|
6. Use the wiki for storing the information you want to conserve about
|
|
|
|
your project, but for which you don't have specific documents;
|
|
|
|
meeting minutes, informal, high-level descriptions, objectives, etc.
|
|
|
|
Also, the wiki is the entry place for most people into the project,
|
|
|
|
so it's good to have a quick intro and a status table in it. Here's
|
|
|
|
an [example](https://www.ohwr.org/project/spec/wiki) (sample source
|
|
|
|
code at attachment:spec\_wiki.txt).
|
|
|
|
7. Use the News section for publishing important events, such as a new
|
|
|
|
exposition or review meeting.
|
|
|
|
|
|
|
|
One alternative to the use of the Documents and Files modules is to have
|
|
One alternative to the use of the Documents and Files modules is to have
|
|
a dedicated documentation wiki page with links to important files in the
|
|
a dedicated documentation wiki page with links to important files in the
|
... | @@ -204,6 +216,8 @@ Please read its comments and configure it properly before using it. |
... | @@ -204,6 +216,8 @@ Please read its comments and configure it properly before using it. |
|
|
|
|
|
-----
|
|
-----
|
|
|
|
|
|
|
|
20 November 2013
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Files
|
|
### Files
|
... | | ... | |