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.
| Stage 4.
|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:)