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

Hi, 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 detail. If you're employed on this project full time, please read this email carefully. 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 ignored. 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 little). 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: https://github.com/mozilla/rust/issues/milestones 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, -Graydon