Mark A. Hershberger wrote: Andre didn't refer to that page, but he edited it on November 2, 2012: https://www.mediawiki.org/w/index.php?title=Bugzilla/Fields&action=hist… So I think it's fair to assume that he's familiar with it. ;-) For what it's worth (and not to ruin the "silence is consensus" model), the proposed priority scheme sounds fine to me. Traditionally these fields have been mostly ignored by just about everyone (developers included). High priority bugs have many other ways of making themselves high priority; they really don't need help from a drop-down menu, but if you can increase the utility (or perceived utility) of that field, go for it. :-) MZMcBride

Thanks for tackling this, Andre! I don't think 'importance' should necessarily map to a timeframe for resolution - at least not one that is set in stone. Different teams/products use bugzilla to varying degrees and in different ways, and a reasonable time frame resolving a 'high' priority bug may be different depending on the specific component. Additionally, a bug's 'importance' in bugzilla may not directly map to other priorities they have (managed elsewhere), and it's up to each team/maintainer/etc to figure out how to prioritize bugzilla bugs relativel to everything else on their plates. That said, I think it makes a LOT of sense to have a shared understanding of what things like 'importrance' in bugzilla actually means. It might be more useful to come up with a rubric of meanings for the different priorities instead of time constraints (or at least instead of thinking of bugs in terms of 'this should be resolved within the week') - eg: * Highest = a mission-critical component is broken in such a way as to make the component completely unable to fulfill its purpose (eg credit card processing is broken in DonationInterface), or is a serious security or privacy vulnerability, or otherwise immediately threatens the health of the cluster * High = a mission-critical component is broken in such a way that does not prevent the component from totally fulfilling its purpose but greatly impedes its functioning/utility, or an issue that might not immediately threaten the health of the cluster but has potential to cause major problems if left unattended to (eg a performance issue that isn't causing problems now but will start causing problems a month from now) * Normal = an issue that does not affect a mission-critical component in such a way to to prevent it from fulfilling its purpose, but has a significant negative impact on users that may be addressable with a workaround * Low = an issue that does not affect a mission-critical component in such a way as to prevent it from fulfilling its purpose, is has low impact on users, and may be addressable with a simple workaround * Lowest = an issue that does not affect a mission-critical component in such a way as to prevent it from fulfilling it purpose, has minimal impact on users, addressable with trivial workaround or can otherwise be easily ignored I'm not suggesting we necessarily go with these definitions, but rather offering these as an example of potential meanings for the different priorities. To me this is a much more useful approach than trying to define importance using timeframes, as timeframes are going to be (and should be) totally dependent on the responsible teams/maintainers/etc to figure out. Thanks again for working to get bugzilla on track - I look forward to the bright future of our bug tracking system :) On Mon, Nov 26, 2012 at 1:29 PM, James Forrester <jforrester(a)wikimedia.org>wrote;wrote: -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687

On 26 November 2012 17:25, Rob Lanphier <robla(a)wikimedia.org> wrote: I disagree. In 1962, NASA's "highest" (most-high?) priority was to put a human on the Moon; that doesn't mean they achieved it before 1969. High priority and soonness-to-be-done are orthogonal. More prosaically, VE's most-high priority task in July was to deploy a test version of the VisualEditor to the English Wikipedia in December; it's now only a few weeks away, but for the past five months it's remained our most-high priority, whilst we've worked on things to support that. No? If you have a few dozen bugs in "your" area of the product/component, two or three of them being the "ones I really must get done before the others" isn't a bad concept. It's always /nice/ if you have at most one bug in "highest" (ideally, none) but that's an ideal case rather than the real world in most cases. To put it another way: in my mind, "highest" refers to the box these bugs sit in, not the individual bugs themselves. You can have lots of bugs in the "top" priority, or none, and in general you start at the "top" of these boxes and work "down". Indeed, completely agreed with that. Agreed, but I think that this is inextricably linked with the wider set of fields in Bugzilla and whether they're fit for purpose; I thought there was an RFC about changing BZ's fields, but I can't find it now... J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

On 27 November 2012 16:39, Andre Klapper <aklapper(a)wikimedia.org> wrote: Has anyone suggested a separate "urgency" parameter? - d.

On 27/11/2012 09:55, Andre Klapper wrote: Perhaps merging the priority and severity ones, and only then adding the urgency, might work, though, since then the wording could be a lot less ambiguous. Not that it would make a whole lot of difference what anything is called so long as the specific fields aren't even bloody labelled, but that's another issue entirely. -- -— Isarra

On Tue, 2012-11-27 at 17:39 +0100, Andre Klapper wrote: 1) Look at the current distribution of priorities at https://bugzilla.wikimedia.org/report.cgi?y_axis_field=&cumulate=0&… and see that "Normal" in the center is the clear peek. Realistically, a way larger amount of reports should be low priority: Nobody working on it, and nothing will happen soon without sudden unlimited manpower. 2) Look at our priority definitions in https://www.mediawiki.org/wiki/Bugzilla/Fields#Priority a) "normal" means "Should be fixed by the next release."[1] This is extremely unrealistic with above usage of "Normal". b) There is no real difference between "would be good to get fixed somewhere in the future" (low) and "can be fixed, but we're not going to worry about it" (lowest). Hence no good reason to keep them separately. We need to be able to differentiate on *important* stuff instead. So in a mysterious future not that far away, I'd like to merge "Normal" and "Low", or "Low" and "Lowest" priorities. Combined with a new "Immediate" priority as proposed above (quoting myself), we would keep the same number of priorities, but we'd communicate way more realistic expectations on fixing issues by moving the peek from the center to the right, where "Low priority" lives. andre [1] "normal" priority meaning "Should be fixed by the next release" should be questioned too, but I'd prefer to NOT do it as part of this thread but do that later. PS: Bonus material: Which priorities do other Bugzillas use?: KDE: {VHI, HI, NOR, LO, VLO} Mozilla: {P1, P2, P3, P4, P5, --} Mer: {High, Normal, Low, Undecided} GNOME: {Immediate, Urgent, High, Normal, Low} FreeDesktop.org: {Highest, High, Medium, Low, Lowest} -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

Andre Klapper <aklapper(a)wikimedia.org> wrote: If at the moment the priority field neither necessarily triggers action nor reflects the actual state of affairs, why even bother and not just delete/hide it from view? This would free more time to fix bugs. Not to quote from another video about GitHub (where "issues" have only title and comment), let's not forget Git: No bug- tracker at all :-). Tim

On Tue, 2012-11-27 at 22:23 +0000, Tim Landscheidt wrote: I don't see how dropping it all together helps planning or how it "frees more time". Obviously anybody is free to work on anything but some stuff simply is more important than other stuff. I understand that there are many options and ways to express that importance though, and that "severity", "priority", "target milestones", "blocker bugs" have some ambiguity to discuss in the long run. Right now I'd like to introduce a clear way to mark issues that should be handled immediately. I'm happy if using http://dir.gmane.org/gmane.comp.version-control.git works well for the Git developers and if important issues don't get lost. There are many ways and tools how to do software development, some work well for some, others work well for others, and not every tool is needed by everybody. GitHub itself has a bugtracker ("Issues" tab) by the way. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

On Wed, Nov 28, 2012 at 5:32 AM, Andre Klapper <aklapper(a)wikimedia.org> wrote: This. Also.... On Wed, Nov 28, 2012 at 9:56 AM, bawolff <bawolff+wn(a)gmail.com> wrote: I'm comfortable with this as a compromise. Also, it's worth noting that the most productive use of Bugzilla is going to be for things that take less than a month of dedicated, focused developer time. Any task that's bigger should be broken down into smaller tasks. Using the moon landing metaphor, it's not as though the NASA folks basically went to work every day saying "this is the day we're going to land on the moon", trying and failing every day until July 21, 1969. There were a few interim steps in there, and heck, I'll bet you they even wrote them down somewhere. Point being: it's fine for something big to be "highest" priority, so long as it's a tracking bug, and there's a smaller subtask somewhere that is also "highest". I would maintain that the subtask is the *only* thing that should have "highest" priority, because saying that the ultimate goal is the "highest" priority, while maybe strictly accurate, is an empty gesture. It doesn't help us organize our work. It's also not even terribly accurate, since the whole "landing on the moon" thing wasn't the highest priority until Apollo 11 got to the moon, and before that got off the ground, and before that...yadda yadda. Yes, it was always helpful to have the ultimate goal in mind, but I'm going to go out on a limb and say that they didn't use an issue tracker for that. However, I don't care as we take care of this: On Wed, Nov 28, 2012 at 5:32 AM, Andre Klapper <aklapper(a)wikimedia.org> wrote: Rob

On Nov 27, 2012, at 5:39 PM, Andre Klapper <aklapper(a)wikimedia.org> wrote: I don't think adding more fields/values is the solution. Perhaps use milestone for "immediate"? So both "Get man on the moon (tracking)" and "[Regression] Bike shed should not be on fire" have highest priority. But one is a regression milestoned for the current release, and the other is on track for N+2 release or maybe "Future release". Besides an "immediate" bug without a milestone doesn't make sense to start with? If that is possible, there is a missing milestone I guess. We should make more use of being able to combine and query different fields to express clarity instead of adding more options that represent a multiple of values in other fields which then also need to be set separately (Commons categories comes to mind, like "Category:Blue objects made of recycled glass hanging upside-down in Amsterdam, Netherlands"). -- Krinkle

On Nov 27, 2012, at 2:36 AM, James Forrester <jforrester(a)wikimedia.org> wrote: I agree with Rob, there is a strong correlation between priority and milestone. However, I don't believe they are linked enough to be able to merge them. Last year I proposed to replace Priority, Severity and Milestone with just Milestones. However I now believe that Priority and Timeframe (milestone) should stay separate. On Nov 27, 2012, at 2:25 AM, Rob Lanphier <robla(a)wikimedia.org> wrote: It seems Severity (or Priority) is redundant in practice. Severity may be useful for statistical purposes afterwards, but given that it is rarely useful for anything other than "enhancement", we might as well drop it and just have a tag for "enhancement" (like for "regression"). Highest priority is the next primary feature in a component and/or a critical bug that needs fixing. Both are very important, but one is long-term the other short-term (as James demonstrates well with the NASA example). On Tue, 2012-11-20 at 02:33 +0100, Andre Klapper wrote: I'd recommend we also require a Milestone to be set for "Highest" priority tickets. That way it is clear to both the assigned developer and the community what the expectations are. -- Krinkle

Rob and Andre, I hear what you're saying. I think I've always had a lack of clarity around the meanings of priority/urgency/severity/whatever in bugzilla, and it sounds like I'm not alone :p. That said, I still do not think timeframes are a good proxy for priority (a la James' example). I think of priority in terms of value - the highest priority items should be the ones that result in the most value - that could be fixing totally broken credit card processing in DonationInterface in the middle of the fundraiser, enabling a new mobile feature for editing an article, etc. Of course, it's difficult to define what that means in our case since we're not selling anything, but the principle remains the same. I think priorities should always be relative to one another and I think defining the temporal scope of a bug without actually knowing what the bug is is a very arbitrary and not particularly useful way to approach the problem. The 'highest' priority items should be getting worked on ahead of 'normal' priority items, and they should be finished as soon as whoever is working on them is... finished. Part of the reason I suggested the rubric the way that I did is because that's what we wound up doing to define task priorities in the midst of the 2011 fundraiser. After the 2011 fundraiser started and issues started sprouting up, it was difficult to not feel like every issue was a 'fire' - that is something that needed to be dealt with immediately. We then defined a rubric for what a 'fire' actually was, or what made one thing more important to work than another. This gave us a shared understanding of what was most valuable. This made prioritizing issues in a way that everyone could mostly agree on/understand trivial. Temporality had nothing to do with it, but it was understood that we always work on issues in priority order. After thinking about this some more, I realized that my reaction to the proposal in part came from feeling apprehensive about external forces defining bug priorities/resolution timelines, and thereby defining how a team must respond to issues in bugzilla. Who would be (is?) responsible for setting bug priorities? Given that teams rely on bugzilla in different ways, organize their work in different ways, and likely have differing criteria for defining what priority a bug/task/etc should have, it seems it ought to be fully up to the team responsible for dealing with issues in bugzilla to prioritize them (rather than directly from some external actor). Of course this prioritization should be informed by people/things beyond the team, but at the end of the day prioritization should be managed by the team/maintainer responsible for the issue. On Tue, Nov 27, 2012 at 9:50 AM, Andre Klapper <aklapper(a)wikimedia.org>wrote;wrote: -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687

On Tue, Nov 27, 2012 at 2:57 PM, Platonides <Platonides(a)gmail.com> wrote: I agree - and I dont mean to suggest we ban people from touching the priority/severity fields, but rather determine a sound approach as a matter of policy. A part of my concern is setting expectations around temporally based priorities that may not jive with a team's use of bugzilla, and/or setting a precedent for somehow interrupting a team's normal flow. But if I'm the only one who doesn't agree with assigning temporal values to priorities I don't want to bikeshed or otherwise stand in the way of this getting done - we can always revisit it later if it turns out to be problematic/ineffective/etc. -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687