Re: [Wikitech-l] Standardizing highest priority in Bugzilla: IMMEDIATE priority added
Thanks for all the good and valuable feedback, explaining your workflows, and discussing current flaws potential improvements in the long run. For the short term I have now created a priority called Immediate which should be used to identify issues that need immediate attention. This means that teams don't have to change their use of highest. Please set IMMEDIATE PRIORITY when it is appropriate. The documentation at http://www.mediawiki.org/wiki/Bugzilla/Fields has been updated accordingly: * Immediate priority: Must be fixed immediately (means: Drop any other work). Reports should have an assignee set in the Assigned to field. * Highest priority: Should be fixed next by a team. Teams should only have very few issues (preferably one) with highest priority at the same time. Reports should have an assignee set in the Assigned to field. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
On Wed, 2012-11-28 at 00:36 +0100, Krinkle wrote: I don't think adding more fields/values is the solution. Perhaps use milestone for immediate? Currently milestones are used in MediaWiki for tarballs (that we don't create for MW 1.21), in VisualEditor for deployments (VE-2012-12-34), and globally in MediaWiki Extensions for branches refering to a MediaWiki version. See my last two lines down there in this email. 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. For the MediaWiki Bugzilla product: The conflict would be wmf deployments vs MW tarballs. We currently use TMs for MW tarballs and we have a 1.20.x, 1.21.0 there. We tag regressions with a code-update-regression keyword. For issue that should block wmf deployments the blocker bug 38865 is used (which is not great but I plan to tackle this later, not now). 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. It's possible. Immediate means immediate. ;) If it should block wmf deployment, also mark it as blocking bug 38865. If it should block an MW tarball, set the Target Milestone accordingly. 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 I agree in the long run, but it might interfere with teams and their use of Bugzilla again. Global workflows vs. this works for my team. Right now I'd like to introduce a clear way to mark issues that should be handled immediately. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
On Tue, Nov 27, 2012 at 2:57 PM, Platonides platoni...@gmail.com wrote: Well, I don't think you would need to ban people not in your group from touching those fields. You only need to take into account who said that as well as what they said. Even when having a shared meaning, it doesn't hold the same meaning the priority set by the reporter (how he thinks it should be treated), other developers/bugzilla gnomes (a more accurate view) or your boss (this is how you must consider it). 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
On Nov 27, 2012, at 5:39 PM, Andre Klapper aklap...@wikimedia.org wrote: On Mon, 2012-11-26 at 17:36 -0800, James Forrester wrote: On 26 November 2012 17:25, Rob Lanphier ro...@wikimedia.org wrote: Timeframes seem like a pretty good proxy for priority. If something is highest priority, and yet is not on track to be completed for several months, then.wait, what? 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. I've been made aware (off-list) of some concerns of this proposal, and your comment provides the same sentiment. The term highest priority has some ambiguity in human language. It's perfectly fine to state that a bunch of bug reports are highest priority: Issues that a team is working on currently, or should work on as the very next task. My initial proposal was to make highest priority mean really urgent or immediate. Consequently, this should also be reflected by its name. Still there should be a way to express what's highest priority for a team. == Reworked proposal: New Immediately priority == I propose adding a *new* priority called Immediate which should only be used to mark really urgent stuff to fix. This priority would be added above the existing Highest priority. [I'm going to respond to the wider priority vs. severity vs. target milestones vs. does this all make sense together discussion in a separate email.] 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
On Mon, 2012-11-26 at 17:36 -0800, James Forrester wrote: On 26 November 2012 17:25, Rob Lanphier ro...@wikimedia.org wrote: Timeframes seem like a pretty good proxy for priority. If something is highest priority, and yet is not on track to be completed for several months, then.wait, what? 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. I've been made aware (off-list) of some concerns of this proposal, and your comment provides the same sentiment. The term highest priority has some ambiguity in human language. It's perfectly fine to state that a bunch of bug reports are highest priority: Issues that a team is working on currently, or should work on as the very next task. My initial proposal was to make highest priority mean really urgent or immediate. Consequently, this should also be reflected by its name. Still there should be a way to express what's highest priority for a team. == Reworked proposal: New Immediately priority == I propose adding a *new* priority called Immediate which should only be used to mark really urgent stuff to fix. This priority would be added above the existing Highest priority. [I'm going to respond to the wider priority vs. severity vs. target milestones vs. does this all make sense together discussion in a separate email.] andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
On 27 November 2012 16:39, Andre Klapper aklap...@wikimedia.org wrote: I propose adding a *new* priority called Immediate which should only be used to mark really urgent stuff to fix. This priority would be added above the existing Highest priority. Has anyone suggested a separate urgency parameter? - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
Hi Arthur, On Mon, 2012-11-26 at 14:54 -0700, Arthur Richards wrote: I don't think 'importance' should necessarily map to a timeframe for resolution - at least not one that is set in stone. With regard to the wider picture, the confusing and partially unclear concept severity vs priority vs target milestone vs importance can and should be discussed in the long run. For the specific problem I'd like to solve in the short run, we need to agree on a way to mark an issue as we must fix this report as soon as possible and should drop nearly all over ongoing work. It might be more useful to come up with a rubric of meanings for the different priorities - eg: * Highest = [snip] * Lowest = I like your definitions a lot as they are very descriptive and provide clear criteria, but to me they fit very well with what severity (blocker, critical, ..., trivial, enhancement) in Bugzilla is supposed to mean. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
On Tue, 2012-11-27 at 16:49 +, David Gerard wrote: Has anyone suggested a separate urgency parameter? I don't think adding another parameter in the user interface improves anything. We have already Priority, Severity, Target milestone and blocker bugs that are all used to somehow express some ranking of issues (to avoid terms like prioritization or severness). andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
On 27/11/2012 09:55, Andre Klapper wrote: On Tue, 2012-11-27 at 16:49 +, David Gerard wrote: Has anyone suggested a separate urgency parameter? I don't think adding another parameter in the user interface improves anything. We have already Priority, Severity, Target milestone and blocker bugs that are all used to somehow express some ranking of issues (to avoid terms like prioritization or severness). andre 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
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 aklap...@wikimedia.orgwrote: Hi Arthur, On Mon, 2012-11-26 at 14:54 -0700, Arthur Richards wrote: I don't think 'importance' should necessarily map to a timeframe for resolution - at least not one that is set in stone. With regard to the wider picture, the confusing and partially unclear concept severity vs priority vs target milestone vs importance can and should be discussed in the long run. For the specific problem I'd like to solve in the short run, we need to agree on a way to mark an issue as we must fix this report as soon as possible and should drop nearly all over ongoing work. It might be more useful to come up with a rubric of meanings for the different priorities - eg: * Highest = [snip] * Lowest = I like your definitions a lot as they are very descriptive and provide clear criteria, but to me they fit very well with what severity (blocker, critical, ..., trivial, enhancement) in Bugzilla is supposed to mean. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
Le 27/11/12 17:49, David Gerard a écrit : On 27 November 2012 16:39, Andre Klapper aklap...@wikimedia.org wrote: I propose adding a *new* priority called Immediate which should only be used to mark really urgent stuff to fix. This priority would be added above the existing Highest priority. Has anyone suggested a separate urgency parameter? Usually the priority is the result of both severity and urgency and is determined using a matrix. Severity would be how much it impacts our mission, for example how many users are facing the issue. Gerrit being down is less a severity than having a US datacenter in fire (literally). Urgency is how fast you are required to fix the incident, this is usually associated with service level agreement contracted with the users. Not providing the database dump would probably be an SLA of one week whereas providing the wikis main pages is probably a 1 minute SLA. Whenever an incident is triaged, people evaluate the impact and urgency depending on the context of the incident. Given a very simple system with only two levels (low / high) here are four examples representing all possibilities: Change a MediaWiki setting for the Klingon wikipedia urgency : low (the change request the links to be green) severity : low (there is only a few reader for that wiki) A database is almost out of disk space: urgency : high (whenever it is filled up we will have a major outage) severity : low (nobody is affected yet) People get disconnected from they sessions and need to relog urgency : low (that is annoying but users can still read content) severity: high (a lot of people are facing the issue) Wiki serving blank pages: urgency : high (our mission to share knowledge is no more fulfilled) severity: high (nobody can read content) So now how do you determine the priority? Just assign increasing scores to each level, sum them, the highest score deserves all your attention. Given low receives 0 points and high receives 1 point, the priorities would be something like: 0 : low - respond under 1 week, resolution target is month 1 : high - respond in 1 day, resolution target is week 2 : critical - respond immediately, resolution target is hour Then you could add a specific status known as a major incident that would have a very specific process attached to it. Usually because you want C-Level to be made aware of it, have to gather peoples from different teams in the same place, assign someone managing everyone and finally having someone in charge of communicating with the users. Building an incident process is definitely a though task but we are lucky to have smart people in our teams and lot of available literacy available from people that had to implements such process before us :-) -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
On 27/11/12 19:26, Arthur Richards wrote: 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. Well, I don't think you would need to ban people not in your group from touching those fields. You only need to take into account who said that as well as what they said. Even when having a shared meaning, it doesn't hold the same meaning the priority set by the reporter (how he thinks it should be treated), other developers/bugzilla gnomes (a more accurate view) or your boss (this is how you must consider it). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
On Tue, 2012-11-20 at 02:33 +0100, Andre Klapper wrote: == Proposal == Proposing the following definitions for Priority: * highest: Needs to be fixed as soon as possible, a week at the most. A human assignee should be set in the Assigned to field. * high: Should be fixed within the next four weeks. Any other opinions, especially by project/product managers? Or does silence mean I don't really care, go ahead? andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
On 26 November 2012 10:51, Andre Klapper aklap...@wikimedia.org wrote: On Tue, 2012-11-20 at 02:33 +0100, Andre Klapper wrote: == Proposal == Proposing the following definitions for Priority: * highest: Needs to be fixed as soon as possible, a week at the most. A human assignee should be set in the Assigned to field. * high: Should be fixed within the next four weeks. Any other opinions, especially by project/product managers? Or does silence mean I don't really care, go ahead? For VisualEditor, this is pretty much how I use it *when in conjunction with a release window* - i.e. Highest and 2012-11-26 meant that it was one of the top priority things for the milestone that went out on the deploy train this morning, so it would have been worked on and hopefully closed within that two-week period (of course, some things take longer). However, I'd also expect High-tagged bugs to get fixed in that two week period; I suppose that the one week / four weeks split it about right, but I worry about Highest-tagged bugs for work that doesn't need to land for months. Just because it's not urgent doesn't mean it's not important. The problem is that our priority field refers mostly to the second and a little to the first, and our Severity refers mostly to the first, but partially to release management work (Blocker is not a statement of severity of the problem, but a prioritisation flag about whether we can release the code; Enhancement similarly is not about severity but about work priority). J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
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 jforres...@wikimedia.orgwrote: On 26 November 2012 10:51, Andre Klapper aklap...@wikimedia.org wrote: On Tue, 2012-11-20 at 02:33 +0100, Andre Klapper wrote: == Proposal == Proposing the following definitions for Priority: * highest: Needs to be fixed as soon as possible, a week at the most. A human assignee should be set in the Assigned to field. * high: Should be fixed within the next four weeks. Any other opinions, especially by project/product managers? Or does silence mean I don't really care, go ahead? For VisualEditor, this is pretty much how I use it *when in conjunction with a release window* - i.e. Highest and 2012-11-26 meant that it was one of the top priority things for the milestone that went out on the deploy train this morning, so it would have been worked on and hopefully closed within that two-week period (of course, some things take longer). However, I'd also expect High-tagged bugs to get fixed in that two week period; I suppose that the one week / four weeks split it about right, but I worry about Highest-tagged bugs for work that doesn't need to land for months. Just because it's not urgent doesn't mean it's not important. The problem is that our priority field refers mostly to the second and a little to the first, and our Severity refers mostly to the first, but partially to release management work (Blocker is not a statement of severity of the problem, but a prioritisation flag about whether we can release the code; Enhancement similarly is not about severity but about work priority). J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
On Mon, Nov 26, 2012 at 1:54 PM, Arthur Richards aricha...@wikimedia.org wrote: 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. Hi Arthur, Timeframes seem like a pretty good proxy for priority. If something is highest priority, and yet is not on track to be completed for several months, then.wait, what? Your definitions of priority strike me as redefining the field as a severity field, which makes it redundant and also not terribly useful as a prioritization tool. Sometimes, if a feature isn't very important, it can have a very severe bug against it that is low priority. At a minimum, can we agree that no single developer should have multiple highest priority bugs assigned to them? Can we also agree that highest/unassigned is a state that we shouldn't leave any bug in for very long at all? Maybe we'll need to cede the priority field to a team-only status, but I'm pretty skeptical that each team is such a unique and delicate flower that we can't agree to some rough guideline for at least highest priority. High and normal are more debatable, but I suspect we can also come up with very broad definitions that everyone can abide by. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
On 26 November 2012 17:25, Rob Lanphier ro...@wikimedia.org wrote: On Mon, Nov 26, 2012 at 1:54 PM, Arthur Richards aricha...@wikimedia.org wrote: 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. Timeframes seem like a pretty good proxy for priority. If something is highest priority, and yet is not on track to be completed for several months, then.wait, what? 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. At a minimum, can we agree that no single developer should have multiple highest priority bugs assigned to them? 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. Can we also agree that highest/unassigned is a state that we shouldn't leave any bug in for very long at all? Indeed, completely agreed with that. Maybe we'll need to cede the priority field to a team-only status, but I'm pretty skeptical that each team is such a unique and delicate flower that we can't agree to some rough guideline for at least highest priority. High and normal are more debatable, but I suspect we can also come up with very broad definitions that everyone can abide by. 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. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
On Nov 27, 2012, at 2:36 AM, James Forrester jforres...@wikimedia.org wrote: On 26 November 2012 17:25, Rob Lanphier ro...@wikimedia.org wrote: Timeframes seem like a pretty good proxy for priority. If something is highest priority, and yet is not on track to be completed for several months, then.wait, what? 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. 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 ro...@wikimedia.org wrote: Your definitions of priority strike me as redefining the field as a severity field, which makes it redundant and also not terribly useful as a prioritization tool. 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: == Proposal == Proposing the following definitions for Priority: * highest: Needs to be fixed as soon as possible, a week at the most. A human assignee should be set in the Assigned to field. 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
On Mon, Nov 19, 2012 at 7:54 PM, MZMcBride z...@mzmcbride.com wrote: 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. :-) Andre has been tasked with curating the list of highest priority bugs so that it makes sense to pay attention to the list. For the engineers in Platform Engineering, we've been pretty good at paying attention to the priorities of bugs assigned to team members. We've fallen off the wagon when it comes to triaging unassigned issues with the platformeng keyword, but that may be something we ask for Andre's help on as well (later) Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Standardizing highest priority in Bugzilla
== Situation == In Wikimedia Bugzilla you can set a priority for a bug report. Some people and teams set highest priority often (meaning These issues should get fixed first in the next weeks). Some don't set it at all (and likely related: Some teams don't really use Bugzilla but other tools). Some are in-between. This use might work well for each team. * Currently there are 15 open tickets with highest priority: https://bugzilla.wikimedia.org/buglist.cgi?priority=Highestresolution=---order=product%2Ccomponent (You might only see 14 if you don't have access to security bugs) * 5 of them have highest priority for more than 30 days: https://bugzilla.wikimedia.org/buglist.cgi?priority=Highestresolution=---chfieldto=-30dquery_format=advancedchfield=prioritychfieldvalue=Highest * 2 of them for more than 90 days (Huggle vs IPv6; moving to EQIAD): https://bugzilla.wikimedia.org/buglist.cgi?priority=Highestresolution=---chfieldto=-90dquery_format=advancedchfield=prioritychfieldvalue=Highest The latter imply either missing maintainership (Huggle?) or tasks that take longer (EQIAD) and could be broken down into subtasks. == Problem == Currently Highest Priority has no single (cross-team) meaning. This makes it hard for people outside of a team (e.g. Engineering Management) to see at a glance what's most important and urgent for each team. == Proposal == Proposing the following definitions for Priority: * highest: Needs to be fixed as soon as possible, a week at the most. A human assignee should be set in the Assigned to field. * high: Should be fixed within the next four weeks. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
On 11/19/2012 08:33 PM, Andre Klapper wrote: == Proposal == Proposing the following definitions for Priority: * highest: Needs to be fixed as soon as possible, a week at the most. A human assignee should be set in the Assigned to field. * high: Should be fixed within the next four weeks. You don't refer to it, so I assume you haven't seen https://www.mediawiki.org/wiki/Bugzilla/Fields#Priority where all this was spelled out before. (I don't see the assignee bit there -- A human assignee should be set... -- but that sounds like how I tried to use highest before.) Mark. -- http://hexmode.com/ Any time you have one overriding idea, and push your idea as a superior ideology, you're going to be wrong. ... The fact is, reality is complicated -- Linus Torvalds http://hexm.de/mc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
Mark A. Hershberger wrote: On 11/19/2012 08:33 PM, Andre Klapper wrote: == Proposal == Proposing the following definitions for Priority: * highest: Needs to be fixed as soon as possible, a week at the most. A human assignee should be set in the Assigned to field. * high: Should be fixed within the next four weeks. You don't refer to it, so I assume you haven't seen https://www.mediawiki.org/wiki/Bugzilla/Fields#Priority where all this was spelled out before. (I don't see the assignee bit there -- A human assignee should be set... -- but that sounds like how I tried to use highest before.) Andre didn't refer to that page, but he edited it on November 2, 2012: https://www.mediawiki.org/w/index.php?title=Bugzilla/Fieldsaction=history 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
