-
Notifications
You must be signed in to change notification settings - Fork 28
Updating the contributions flow diagram
Ian Edwards edited this page May 22, 2017
·
4 revisions
The open source contributions diagram is being tested for the first time with issue #193.
- After Issue raised on GitHub we may need an extra box to make it clear that everyone can take part in the discussion.
- The Lead Developers decide whether or not to Proceed with issue?, but the Technical Advisory Group or the Steering Group may need to override a decision by the Lead Developers to close an issue, on the basis of wider strategic need. This may cause issues may go into limbo (hanging around for a long time without much attention) if they are currently not implementable, but are strategically important. But the issues should still remain open and have a suitable label.
- Should we continue to try to separate the early decision (on whether or not to accept the issue) from the later more technical discussion. If so, before proceeding to the technical points we should probably:
- vote on the issue
- assign the appropriate labels, projects and milestones
- move onto discussing the implementation in depth
There are a number of coordination tasks that may be best not on the main diagram, but that need to happen as issues are progressed (Steve described this as a meta-process).
In September 2016, GitHub released new features for managing projects that we can use instead of Jira, see details here: