[rust-dev] Refactoring the milestones on the issue tracker

Hey, Rustlings! During the bug triage meeting today we decided to make a few changes to how our milestones on GitHub are organized in order to be better oriented towards our goals for the near future. Recently the core team has been putting a lot of thought into what it's going to take to get a major, stable release of Rust finished, and it's become clear that the way we've been organizing the milestones is not representative of the actual work we believe must be done. We previously triaged the entire set of issues into 5 categories: well-defined, backwards compatible, well-covered, feature complete, and production ready. It's not clear though how useful this exercise was; certainly figuring out the set of issues with backwards-compatibility implications was important, but it appears both that the scope of all these milestones together is much greater than anything we can accomplish in a reasonable timeframe, and also that there were many issues triaged into the backwards-compatible milestone that don't necessarily need to be resolved. In the end, this scheme did not well capture the actual work that we need to do. For reference this approach was previously described here: https://mail.mozilla.org/pipermail/rust-dev/2013-April/003668.html Today we're simplifying our triage scheme in the following ways: * The previous 'maturity milestones' have been converted to 'P' (priority) tags on the issue tracker: P-backcompat-lang, P-backcompat-libs, P-high, and P-low; and all of the previously triaged issues have been tagged. Converting from milestones to tags emphasizes that these are simply categories, not singular goals that occur in any specific order, and the naming emphasizes that what we mostly care about for completing a major release is backwards compatibility of the language and libraries. * We now have an upcoming [milestone] called "first major release". This is tentatively Rust 1.0 and is intended to represent the complete set of work that we need to do to get a major release out of the door. Unlike our typical point releases, this will be a feature-based release. * We'll keep the [nomination] process intact, but instead of triaging bugs into maturity milestones, they will be given P-tags and possibly assigned to the first major release milestone. The [criteria] for nomination is still the same as for the previous maturity milestones. [milestone]: https://github.com/mozilla/rust/issues/milestones [nomination]: https://github.com/mozilla/rust/wiki/Note-development-policy#milestone-and-priority-nomination-and-triage [criteria]: https://github.com/mozilla/rust/wiki/Note-priority-issue-criteria In the past few weeks we've already triaged all the "well-defined" and "backwards compatible" issues to determine the subset to move into the "first major release" milestone. The remaining issues from the maturity milestones are temporarily tagged P-high-untriaged and will be re-triaged to determine which belong on the release milestone. It's not clear where the P-low tag fits into the triage process yet, but conceivably we'll expand triage to include all bugs in the future, not just 'nominated' bugs, giving all bugs a P-tag. OK, I hope that's clear, relatively simple, and not too objectionable to anybody. As to the actual criteria for what is in-scope and what is out-of-scope for the first major release of Rust, I'd like to hold off that discussion a little longer. Some time soon we'll have another thread to discuss release plans in more detail. Regards, Brian