Difference between revisions of "Design Workflow"
m |
|||
| Line 1: | Line 1: | ||
| + | |||
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. | 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. | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| − | ! '''Stage 1. | + | ! '''Stage 1.''' |
| − | Informally bounce ideas off people to see if they are worth bringing to the attention of the entire community | + | Informally bounce ideas off people to see if they are worth bringing to the attention of the entire community<br/> '''(purely optional)''' |
| − | ! '''Stage 2. | + | |
| − | Put things up for discussion | + | ! '''Stage 2.''' |
| − | ! '''Stage 3. | + | Put things up for discussion |
| − | Detailed discussion | + | |
| − | ! '''Stage 4. | + | ! '''Stage 3.''' |
| − | Documenting outcomes <br />(When a solution has been found or discussion has slowed down/stalled and is unlikely to resume in the near future) | + | Detailed discussion |
| + | |||
| + | ! '''Stage 4.''' | ||
| + | Documenting outcomes<br/> (When a solution has been found or discussion has slowed down/stalled and is unlikely to resume in the near future) | ||
| + | |||
|- | |- | ||
| '''IRC''' - the most feedback. Engine room of opensource projects and used for collaboration ''exlusively'' by a lot of contributors. | | '''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''' | | '''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. | + | 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:)''''' | '''''If a new Policy or Design issue arises during a Pull Request,Issue, or Discussion please follow the stages above:)''''' | ||
| + | |||
| + | [[Category:Design]] | ||
Revision as of 08:03, 16 June 2017
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:)
