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 tha
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
On Nov 27, 2012, at 5:39 PM, Andre Klapper wrote:
> On Mon, 2012-11-26 at 17:36 -0800, James Forrester wrote:
>> On 26 November 2012 17:25, Rob Lanphier wrote:
>>> Timeframes seem like a pretty good proxy for priority. If something
>>> is "highest" priority, and yet is not on track to be comple
On Tue, Nov 27, 2012 at 2:57 PM, Platonides 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
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 bug
Le 27/11/12 17:49, David Gerard a écrit :
> On 27 November 2012 16:39, Andre Klapper 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 a
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
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 b
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 ex
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
On 27 November 2012 16:39, Andre Klapper 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
On Mon, 2012-11-26 at 17:36 -0800, James Forrester wrote:
> On 26 November 2012 17:25, Rob Lanphier 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
On Nov 27, 2012, at 2:36 AM, James Forrester wrote:
> On 26 November 2012 17:25, Rob Lanphier 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 disagr
On 26 November 2012 17:25, Rob Lanphier wrote:
> On Mon, Nov 26, 2012 at 1:54 PM, Arthur Richards
> 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 us
On Mon, Nov 26, 2012 at 1:54 PM, Arthur Richards
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
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
On 26 November 2012 10:51, Andre Klapper 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 "A
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 th
On Mon, Nov 19, 2012 at 7:54 PM, MZMcBride 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 hav
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: Sh
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
21 matches
Mail list logo
