Documentation Level: 
Introduction
Documentation Status: 
No known problems

Milestones help us prioritize our work.

Milestones are added to issues to schedule them for a specific release. The 1.12.0 milestone, for example, would indicate that an issue is scheduled to be included in the 1.12.0 release.

Adding milestones

Anyone who has added a comment to an issue, or created a new issue, should have automatically been granted access to add milestones to all issues. If you don't have this ability, please ask someone in the Gitter chat for help.

Please note, milestones should not be added arbitrarily; they must meet the criteria below, otherwise they may be removed.

Bug-fix release milestones

In order for an issue to remain tagged for the next bug fix release, it must meet all of the criteria below:

  1. It must have been tagged with the label "milestone candidate - bug" by one person.
  2. It must have had the milestone added by a different person than the one who added the label.
  3. It must have a recent pull-request in a near-ready state.
  4. It must be suitable for a bug-fix release, meaning: 
    • It must be tagged with either the label "type - bug report", or the label "type - task", OR
    • It must be marked as a user-experience improvement, with [UX] in the issue title, OR
    • a core committer must have stated that this issue is suitable for a bug-fix release.

Minor release milestones

In order for an issue to remain tagged for the next minor release, it must meet all of the criteria below:

  1. It must have been tagged with the "milestone candidate - minor" label.
  2. It must have an advocate* (preferably, you!).
  3. The advocate for this issue cannot also be the advocate for another open issue in this milestone, unless, of course, the other issue has a Pull Request in a near-ready state.

There is one exception to the above for minor release milestones: 

  1. If an issue has an accompanying Pull Request that has earned the label "pr - ready to be committed", but is not suitable for a bug-fix release, this issue can also be added to the next minor release milestone.

*Issue advocates

  • An advocate is not necessarily the person who will be writing the code; but if not, it must be someone who can steadily move the issue forward by recruiting others for help where needed.
  • An advocate would ideally be able to attend most of our weekly meetings to report on the status of the issue. If that is not possible, then a short update/summary of the status of the issue they are advocating for should be left in a in a dedicated section of the top post in the thread.