So what are the 2 labels applied for the milestones ? Was that
1. PREDICTIVE MILESTONES 2. MATURITY MILESTONES ?? On Mon, Apr 22, 2013 at 10:44 PM, Graydon Hoare <[email protected]> wrote: > 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<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 > ______________________________**_________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> > -- -Thad http://www.freebase.com/view/en/thad_guidry
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
