Difference between revisions of "Design Workflow"

From PioneerWiki
Jump to: navigation, search
(Removing mailing list and simplifying a bit.)
 
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.
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 11: Line 11:
  
 
! '''Stage 3.'''  
 
! '''Stage 3.'''  
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)
 
Documenting outcomes<br/> (When a solution has been found or discussion has slowed down/stalled and is unlikely to resume in the near future)
  
Line 19: Line 16:
 
| '''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.''
 
| '''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 for Docs.'''
| '''Wiki'''
 
 
|-
 
|-
 
| '''Forums'''
 
| '''Forums'''
| '''Mailing list''' - Discussion of project policy or wider design issues
+
| '''Forums, IRC'''
| It's possible to use wiki pages like a piratepad
 
 
| Multiple issues in '''Issue tracker''' - ''focused'' and ''implementable'' tasks
 
| Multiple issues in '''Issue tracker''' - ''focused'' and ''implementable'' tasks
|-
 
| &nbsp;
 
| Detailed proposal on the '''Wiki''' then linked to the '''Mailing list'''
 
| &nbsp;
 
| &nbsp;
 
 
|}
 
|}
  
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''&nbsp;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]]
 
[[Category:Design]]

Latest revision as of 09:29, 3 September 2017

Table thingy outlining the appropriate places for use at different stages of the workflow for both design and resolution of issues.

Stage 1.

Informally bounce ideas off people to see if they are worth bringing to the attention of the entire community
(purely optional)

Stage 2.

Put things up for discussion

Stage 3.

Documenting outcomes
(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. Issue tracker - is focused enough to allow immediate solution. Workflow ends here. Wiki for Docs.
Forums Forums, IRC Multiple issues in Issue tracker - focused and implementable tasks

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 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:)