It may help to know a bit more context.
The original underlying problem this process is aiming to solve is where a change is proposed but they're not entirely sure what approach to take, and the contributor feels blocked due to lack of guidance. Similar kinds of uncertainty can pop up in bug triage, and with developers who implement a new feature but need advice on how to optimize the UI/UX for it.
So, the idea is sort of an anti-bureaucracy, where instead of slowing things down by requiring approval steps, to instead focus on where there is uncertainty or disagreement and figure out how to help the contributor get through those blocks.
Bryce
On Wed, Mar 13, 2019 at 06:44:36PM -0400, doctormo@...400... wrote:
- How are presenters chosen? - Usually the person who wants the
change. 2. I believe by the "to forecast" label? Yes 3. If so, who assigns the label? - Anyone when there is an obvious conflict between changing and not changing. 4. The reporter? Any dev? The "forecast team"? Yes 5. Is the person who assigns the label also the person presenting the issue 6. and making sure the necessary info (like the gif) is available? - If they want it, they should provide the materials to present it.
Martin,