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

Thad Guidry thadguidry at gmail.com
Mon Apr 22 21:01:20 PDT 2013


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 <graydon at mozilla.com> 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
> Rust-dev at mozilla.org
> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev>
>



-- 
-Thad
http://www.freebase.com/view/en/thad_guidry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20130422/ff4f7b2f/attachment-0001.html>


More information about the Rust-dev mailing list