The ability to set “priority” and “mi…

The ability to set “priority” and “milestone” for WordPress Core Trac tickets has been restricted. Unknown Trac users will not be able to set them when creating or updating tickets. These fields were being somewhat misused by casual Trac users — e.g. setting priority higher than it should be, or sticking things in the 3.0 milestone when 3.0 was in RC. We are adding the ability to set these fields to known WP contributors based on frequency and quality of code and ticket contributions. That list is not complete, so don’t micro-analyze the inclusion or non-inclusion of anyone at this point! 🙂

This should help WordPress avoid having hundreds of tickets on a milestone that need to be punted in the weeks before release. We can be more judicious in assigning a milestone to a ticket.

Tickets opened by people unfamiliar with issue tracking in WordPress need to be reviewed for correctness in any case. So, experienced members review and correct them, and inexperienced members learn to report better.

Yet we still punt hundreds of tickets late in the cycle that shouldn’t have been on the current milestone. Many have been defaulting to “next milestone” by default, as Xavier notes. This change just enforces “undefined” as the default, and lets experienced contributors do the initial setting of priority and milestone, which should result in less cruft in the active milestones. It’s also a subtle change in tone: from “no, you set the wrong priority” (correcting after the fact) to “here’s the priority we’re assigning this ticket.”

The permission was removed from authenticated users. We then granted it to a few contributors. We’re going to experiment with this for a bit, make some adjustments as necessary, then expand the permission further. Don’t micro-analyze, as Mark wrote.

Each ticket is going to start out Unsassigned and normal priority, which then allows those guiding each release to then set a specific priority and milestone. To allow a ticket to be created under any milestone or priority causes scope creep, it makes ticket management more difficult, and it suddenly renders those fields arbitrary. The priority field has never been effectively used. But now we can use it effectively to set priorities. It’s not about training new users how to use a bug report system, it’s about ensuring that each milestone isn’t filled with noise, and it’s the just the latest step we’ve made to improve our workflow where we see it deficient.

I don’t see how this harms our meritocratic system. We’re empowering and giving more responsibility to trusted contributors while experimenting with and hopefully greatly improving our ticket workflow in the process. Win-win.

This came out of discussions that 3.1 is likely to be limiting and/or different in scope. I actually suggested we move every 3.1 ticket to Future Release, that way we can use the first month of the cycle to build up a release by moving selected tickets back.

We will probably discuss all of this in a dev chat, this week or next week, once we talk about 3.1.

This is something that you might want to look into. There might be a plugin for Trac, but at the time I looked into it, there was not. Part of the problem is not so much the tools (new people or experienced people) but the tool (Trac). By fixing the tool, you have less tools.