I marked the 2.9.3 milestone as “completed” on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., even though it never shipped, I removed the 2.9.3 milestone on Trac and shifted those tickets to 3.0, which means the minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. reports now reflect 3.0.1.
That milestone is for “security and blockerblocker A bug which is so severe that it blocks a release.-level bugs” only. That doesn’t mean all other tickets belong in 3.1, though. I’m going to suggest tickets are triaged in the following fashion:
- Anything in the 3.1 milestone that is not owned by a committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers – a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. or seriously deserving of 3.1 consideration will be moved to future release (prior to our scope meeting) to keep 3.1 clear of debris. After a scope meeting, we can selectively pull tickets into 3.1 as we go. (Currently 340 tickets are marked for 3.1.)
- The Unassigned milestone should be emptied, sans reporter-feedback-like tickets that we can’t place into a milestone yet. All new tickets should start here. (There are currently 169 tickets without a milestone.)
- The Future Release milestone needs a good drudging for it to become truly useful again, as there are probably hundreds of tickets there that can be closed as duplicate, invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid., worksformeworksforme A resolution on the bug tracker (and generally common in software development) that indicates the bug reported cannot be reproduced., or wontfixwontfix A resolution on the bug tracker (and generally common in software development) that indicates the ticket will not be addressed further. This may be used for acceptable edge cases (for bugs), or enhancements that have been rejected for core inclusion.. (876 tickets currently.)