How we manage open source work

How we manage open source work

We manage our open source work here on 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

  1. Bugs are more important than features. In most cases a bug should be fixed and worked on before a feature.

  2. 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.

  3. 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.


@fzngagan I’m going to go through and give you a clearer sense of prioritization of the tasks I’ve already assigned you, and more generally, first thing next week. In the meantime, I think you have a enough to get your teeth sunk into.

1 Like

Sure. Right now I am working on the wiki page and later today, I’ll look at the plugin code and possibly, the review related issue.

@fzngagan Ok, the way we will manage priority for now is using the ticketing tag system I’ve been using. I haven’t been using it formally, but let’s start using it here to help manage priorities.

The tickets plugin is installed on this instance. There are three tag groups set up for this plugin:

  • tickets_priority: low, medium, high
  • tickets_status: to-do, doing, done
  • tickets_reason: bug, feature

Bugs always have priority over features, so for a current ‘to do’ list with priorities attached see:

Let’s start there and see how we go!

cc @members