RFC Figure out feature request workflow

[djbusstop]

This is a proposal for how feature concepts and requests make it in to the the development process. It relates to this issue #112 which is about HOW features are documented. This issue however is about the project management processes and communication on how we decide to approve feature ideas.

We want that people in different roles and different experience levels be involved in the process. Deciding on features should not be done in a top down way.

Deciding on features

• Write a detailed issue explaining the proposal and possibly tag it as "RFC" (Request for Comment).
• Ping people until the relevant people have weighed in (this would mean Teresa, core devs, and people who give a shit. Probably best to post publicly on slack #dev if it's an RFC).
• If the issue requires more thought, the person who made the issue can host a meeting or wait until the next planning meeting to present it
• We would decide by "concensus" which is very nebulous but generally will work. As long as there's no strong objection, it's best to move forward rather than be bogged down in arguments.

Simple workflow explaination

• Someone has an idea that would change the interaction of the web extension
• They write an RFC for how the feature would work
• Ideally they would write requirements and a usage scenario, perhaps in an MR that only updates the documentation? (Please see RFC Organise feature specifications #112)
• They would post a link to the issue in slack and see if anyone objects to it
• Iterate on the ideas
• Update / Finalise the requirements and usage scenarios
• Design spec can be created
• Once design work is done (if needed) development work can start

[lucie-docs]

Sounds good to me!