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.
Jacob Santos, 
Xavier 8:53 pm on June 20, 2010 Permalink
In general, when filing tickets, I simply set to the next milestone (either major or minor), and leave the rest to default, letting core-devs do as they feel is best.
Alex M. 6:26 am on June 21, 2010 Permalink
The proper thing to do is to set it to “Future Release” unless it’s a major bug.
demetris 9:58 pm on June 20, 2010 Permalink
I don’t understand how this helps.
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.
Don’t make things complex for no real reason.
Mark Jaquith 11:31 pm on June 20, 2010 Permalink
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.”
demetris 1:10 pm on June 22, 2010 Permalink
Correcting after the fact is not bad, I think. It is better. It helps people learn. (Aha… I thought I knew how to do this, but it obviously does not work that way!)
And it’s not like new tickets have to be reviewed specifically for those two fields. Each new tickets is checked by several experienced member in any case.
In addition, this new system introduces a new and potentially disruptive layer of judgement of merit into the way contributors are treated — the last thing we need.
I think this change will do more harm than good.
I believe a better way to deal with the issue would be to imrpove the note under Create New Ticket:
1. Abbreviate and improve what we have now, so that the important message gets across easily.
2. Add a new bit. Something like: “Remember to set the version in which the issue appears. Other fields can be left as is, to be set appropriately when the ticket is reviewed.”
hakre 12:13 pm on June 22, 2010 Permalink
> Unknown Trac users will not be able to set them when creating or updating tickets.
Then I must be an “unknown Trac user” now. Or a misusing casual one. Amusing.
Andrew Nacin 2:05 pm on June 22, 2010 Permalink
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.
Andrew Nacin 2:28 pm on June 22, 2010 Permalink
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.
(Designed as a reply to comment 7958 by demetris.)
Jacob Santos 8:53 pm on June 22, 2010 Permalink
http://lostgarden.com/2008/05/improving-bug-triage-with-user-pain.html
Jacob Santos 8:55 pm on June 22, 2010 Permalink
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.
Matt 9:22 pm on June 22, 2010 Permalink
That’s pretty neat.
Jacob Santos 10:19 pm on June 22, 2010 Permalink
I believe I found the link from you, but I have been wrong before with such details before.
And no, there isn’t a plugin for Trac. One would have to be written.
Jane Wells 6:29 pm on June 24, 2010 Permalink
@Jacob: Ha, that happens to me all the time — Matt tells me something is cool and it will turn out I heard about it from him in the first place.