Design Workflow
Table thingy outlining the appropriate places for use at different stages of the workflow for both design and resolution of issues. Experimenting with tables:). Still WIP, feel free to reformat/fix/make clearer.
| Stage 1.
Informally bounce ideas off people to see if they are worth bringing to the attention of the entire community |
Stage 2.
Put things up for discussion |
Stage 3.
Detailed discussion |
Stage 4.
Documenting outcomes |
|---|---|---|---|
| IRC - the most feedback. Engine room of opensource projects and used for collaboration exlusively by a lot of contributors. | Issue tracker - is focused enough to allow immediate solution. Workflow ends here. | Mailing list and possibly a pirate pad for issues that are too extensive or benefit from realtime or re-structurability aspects. | Wiki |
| Forums | Mailing list - Discussion of project policy or wider design issues | It's possible to use wiki pages like a piratepad | Multiple issues in Issue tracker - focused and implementable tasks |
| Detailed proposal on the Wiki then linked to the Mailing list |
The different media for communication are there for a reason. For instance, discussion on the IRC cannot be regarded as official, as it's not used as a medium of collaboration by all - some contributors are available only through Github/mailinglist or forum for collaboration and new contributors only observe Github or the Wiki. Similarly it is not appropriate to discuss aspects of project management/policy or non-relevant topics in a focused Github Issue or on a Pull Request - it is not visible to the critical audience, it disturbs the process of reviewing a Pull Request or discussing the present issue, and it makes things hard to find later.
If a new Policy or Design issue arises during a Pull Request,Issue, or Discussion please follow the stages above:)
