We manage our open source work here on thepavilion.io in a workflow is laid out below. If you have any questions or ideas to improve this workflow, post in this topic.
Step 1. Reporting and Requesting
Users of a plugin can make a bug report or feature request using the Bug Report and Feature Request wizards. These wizards are designed to structure the reports and requests to get as much useful information from the user as possible. Once completed they automatically create topics in #open-source:bug-reports and #open-source:feature-requests.
Members of Pavilion also need to use the wizards to report bugs or request features, even if you’re responsible for the work the report or request is about. This is important as the report and request are the inputs into a system that tries to balance work priorities in a fair and efficient way.
Sometimes when you’re working on something it is tempting to work on a related issue or feature. Try to resist this temptation. Create a bug report or feature request instead. That way, you keep your work organised and prioritised in a global sense and don’t get sucked into hacking away at multiple related issues for days on end.
Step 2. Assessment
Feature Requests and Bug Reports need to be assessed before they are turned into tasks. They are assessed according to a few heuristics
Bugs are more important than features. In most cases a bug should be fixed and worked on before a feature.
Bugs that break a site are the most important. Bugs that entirely break a site or prevent it from being updated are the most critical requests and should be fixed as soon as possible.
Features are assessed according to their impact. Features are prioritised according to how many users of the plugin they will benefit. This is why features have voting enabled on them, to indicate popular support.
Bug Report and Feature Request topics are used to project manage the report or request, i.e. to clarify what the issue is, or what the desired outcome is. Or to dismiss the report or request.
Step 3. Task
Once Bug Reports and Feature Requests have been assessed, if they are going to be worked on they are moved to the #open-source:tasks category and assigned to a member. They can also have a due date and priority assigned, but that is optional.
Once in the #open-source:tasks category the assigned member works on the request or report and uses the task topics to discuss technical matters relating to the task.
Step 4. Completion
Upon completion of a task, the relevant stakeholders in that task are notified.