[rust-dev] New milestones, bug triage, maturity and completion

Graydon Hoare graydon at mozilla.com
Mon Apr 22 20:44:28 PDT 2013


Mozilla research had a workweek recently where we discussed a number of 
process changes to the Rust project to try to bring a little more order 
to the chaos and wind down the rapid-growth, everything-on-fire phase of 
the project. This email explains those process changes in a little more 

If you're employed on this project full time, please read this email 

0. Bors, incoming and master

Bors has been generally judged a success (modulo annoyingly regular 
timeouts on the buildbot) so we will be deleting the incoming branch and 
switching bors to move master directly. I'll send another notice when 
this is ready to happen.

1. Milestones split into two groups

Previous rust releases have used milestones ineffectively, as they 
blurred the distinction between aspirations ("we think this bug _should_ 
get done") and prediction ("we think this bug _will_ get done"). As a 
result, they served neither purpose and were frequently overlooked or 

We will attempt to breathe new life into the "milestone" facility by 
splitting their roles into separate sets: for 0.7 and onwards, 
release-numbered milestones (0.7, 0.8, 0.9, etc.) will be _predictive 
only_. Bugs should be placed on those milestones only if they are 
assigned to you, and represent your best guess about _what you will do_ 
during a release cycle. You can take something off that milestone if 
it's assigned to you and you don't think you'll get it done, whenever 
you see fit. These milestones will have associated target dates, which 
we will aim to maintain on the quarterly cadence we've maintained so far.

A separate set of milestones has been added called "maturity" 
milestones. These have no dates, and are "aspirational": they define 
subjective concepts "backwards compatible" or "feature complete" in 
terms of specific bugs, for external measurement of the project's state. 
The project's maturity can be judged against these more usefully than it 
can be judged against milestones like "0.7" (which tells the reader very 

Bugs will be assigned to maturity milestones by a nomination process. 
That's point #2. Maturity milestones will be reached "when we get 
there"; we will not hold releases for them. What we call "1.0" is a 
different conversation, but I imagine it needs to be somewhere after the 
"backwards compatible" milestone, just to suit the concept of 
major-version numbers in semantic versioning.

2. Nomination and acceptance

Maturity milestones represent a subjective judgment about product 
maturity, as seen through the eyes of the repository owners (that is, 
mozilla engineers). Of course you're welcome to consider maturity in 
different terms, but this is for our own planning and measurement of the 
project. As such we'll be accepting _nomination_ of a bug for inclusion 
in one of these milestones liberally -- anyone should feel free to 
nominate a bug if they think it's really important -- but meeting weekly 
to either _accept_ or _decline_ inclusion in these milestones. This way 
we hope to establish and communicate a consensus concerning the project 
status and path towards completion. There is a new tag I-nominated for 
tagging a bug with nomination. These will be cleared weekly, at the meeting.

Bugs that we decline to add to a maturity milestone will remain in the 
general bug pool, and will be addressed "best effort" by the repository 
owners, or (of course) through contributed pull requests. It's still 
worth keeping non-milestone bugs around.

I should reiterate: the maturity milestones are there to _sharpen a 
concept_ like "feature complete" or "backwards compatible" into a 
particular bug-set. They are not there for scheduling a bug you "want to 
get done because it seems cool". The idea is that a bug should be 
assigned to a maturity milestone where it would be a _untenable_ to 
claim or argue the terms of the milestone were met without that bug.

As such, the maturity milestones have extensive text associated with 
them. Please read them to make sure you understand the idea behind each:


3. Randomized triage and fixing in the general bug pool

I've added a new script to our repertoire of project automation that 
selects a set least-recently-edited bugs every week and randomly assigns 
them in batches for triage to a set of project participants (who have 
signed up for this fate -- email me if you want to join in). This way we 
hope to visit, self-nominate, review and close bugs at a better rate and 
a more uniform breadth than we've been doing so far; and to improve this 
rate as we advance towards feature completion and can focus more and 
more energy on bug fixing.

If you received a set of bugs from this script this week, please take a 
look at the bugs you were given and make time to look through them and 
post at least one change to them so they don't come up again next week. 
This could be as little as simply confirming that the bug still exists 
and makes sense, though searching for duplicates, narrowing cases, 
investigating causes and/or actually fixing bugs is also great if you 
can spare the effort.

4. WIP on "1.0 bugs"

I'm presently mass-reassigning bugs that were formerly marked "1.0" to 
the maturity milestones (and doing a small amount of filtering and 
triage along the way). We will spend some time reviewing these in the 
next few nomination meetings, as a sort of backlog of implicit 
nominations, since "accepting" carries a bit more weight now than it did 
when a lot of them were put on "1.0" (back when that seemed "infinitely 
far away"). Hopefully it doesn't take _too_ many meetings to sort out; 
but in case you were wondering, that's why the maturity milestones 
currently already have (some) bugs assigned to them.

I should be finished with the initial mass-reassignment of those 1.0 
bugs before the meeting this week. At that point I'll remove the 1.0 
milestone. We should probably also have a look through the 0.7 milestone 
to make sure it corresponds to the definition given above for numeric 
milestones (only bugs assigned-to-users and expected-to-complete by next 
release mark).

If you have any questions on any of this, please mention them here. I'm 
happy to discuss further anything that's unclear, either here or on IRC 
/ through direct email to me. We'd like the process to become more 
transparent and better-organized, so everyone should feel like they 
understand what's going on.

Thanks for your attention,


More information about the Rust-dev mailing list