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 Zulip 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:
- It must have been tagged with the label milestone candidate - bug by one person.
- It must have had the milestone added by a different person than the one who added the milestone candidate - bug label.
- It must be suitable for a bug-fix release, meaning the issue meets any of the following criteria:
- It must be tagged with the label type - bug report, the label type - task, or the label type - documentation
- 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.
There is one exception to the above for bug-fix release milestones:
- If an issue has an accompanying Pull Request in a near-ready state that has earned either of the labels pr - ready to be committed or pr - works for me, then the milestone can be added even by the same person who added the milestone candidate - bug label.
Minor release milestones
In order for an issue to remain tagged for the next minor release, it must meet all of the criteria below:
- It must have been tagged with the milestone candidate - minor label.
- It must have an advocate* (preferably, you!).
- 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 with either of the labels pr - ready to be committed or pr - works for me.
There is one exception to the above for minor release milestones:
- If an issue has an accompanying Pull Request in a near-ready state that has earned either of the labels pr - ready to be committed or pr - works for me, 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.