QA -> Developers communication

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

QA -> Developers communication

R Kent James
A few weeks ago on IRC dmose and I discussed the general issue of how QA
communicates priorities to developers. I'd like to hear some comments on
that from others, and possibly participate in some sort of trial of
improvements.

The issue here is that I see lots of good work going on by people who
are mostly involved in QA, such as wsmwk, WADA, and Ludo, but I as a
developer don't really know how to make the best use of that work.

I assume there is supposed to be a waterfall here, from (bug
reporter)->(QA)->(developer)->(code reviewer)->(bug landing). I
understand all of the steps of the process except this (QA)->(developer)
handoff. I would be curious to hear from people involved in QA about
what they view the main outcome of their work is supposed to be, as
viewed by a developer.

Here's what my understanding is of the current process. After bugs are
submitted, QA has three main responsibilities: 1) get the bug in the
correct component, 2) move the status to NEW or one of the inactive
states (DUPE, INVALID, etc.) 3) clarify the bug information to get clear
steps to reproduce.

Is this accurate?

Let's look to see how that is working by looking at my recent work. In
the last three months, I fixed eight bugs (that's a little off my
desired pace, but we were frozen a lot of that time). What brought those
bugs to my attention?

(3) bugs I reported myself, either due to issues I observed or as a
result of following support forums.

(3) bugs are fixes of crashes that wsmwk reported from crash stats

(2) bugs were filed earlier by others. If I recall correctly, both of
those bugs were items that I noticed first in support forums, then
located the bug in Bugzilla and fixed it.

In no cases did the standard QA waterfall process play a significant
role in bringing a bug to my attention. And that concerns me, because I
see some very competent and dedicated people working hard on QA, but I
don't seem to be making effective use of that work.

Am I somehow not following the process that I am supposed to be
following, or is that process flawed? In theory I am probably in a
better position than most people here, because I primarily track items
that appear in the mailnews core/filters component.

I wish there was a clear way for the QA people to bring a limited number
of bugs to my attention that are 1) important, 2) clearly defined and
reproducible, and 3) likely to be fairly easy to fix.

The mailnews core/filters category currently has 326
NEW/ASSIGNED/REOPENED bugs in it. I could probably fix a few per month
that were brought to my attention. A reasonable expectation might be
that 10% of those are addressed in the next year. How are the QA folks
supposed to influence the selection of which 32 bugs actually get my
attention?

(posted to http://mesquilla.com and m.d.a.thunderbird, followup to
m.d.a.thunderbird please.)

rkent
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

Ludovic Hirlimann-3
On 22/01/10 19:45, Kent James wrote:

> The issue here is that I see lots of good work going on by people who
> are mostly involved in QA, such as wsmwk, WADA, and Ludo, but I as a
> developer don't really know how to make the best use of that work.
>
> I assume there is supposed to be a waterfall here, from (bug
> reporter)->(QA)->(developer)->(code reviewer)->(bug landing). I
> understand all of the steps of the process except this (QA)->(developer)
> handoff. I would be curious to hear from people involved in QA about
> what they view the main outcome of their work is supposed to be, as
> viewed by a developer.
>
> Here's what my understanding is of the current process. After bugs are
> submitted, QA has three main responsibilities: 1) get the bug in the
> correct component, 2) move the status to NEW or one of the inactive
> states (DUPE, INVALID, etc.) 3) clarify the bug information to get clear
> steps to reproduce.
>
> Is this accurate?

I don't think putting the bug in the correct component adds much value.
We do it for two reasons, some people are following some components and
not others , and that might help the triage process (but frankly tot do
that I usually cc people). Some bugs are very well writen (too few),
with those it's quite easy for us to mark them new.

> Let's look to see how that is working by looking at my recent work. In
> the last three months, I fixed eight bugs (that's a little off my
> desired pace, but we were frozen a lot of that time). What brought those
> bugs to my attention?
>
> (3) bugs I reported myself, either due to issues I observed or as a
> result of following support forums.
>
> (3) bugs are fixes of crashes that wsmwk reported from crash stats
>
> (2) bugs were filed earlier by others. If I recall correctly, both of
> those bugs were items that I noticed first in support forums, then
> located the bug in Bugzilla and fixed it.
>
> In no cases did the standard QA waterfall process play a significant
> role in bringing a bug to my attention. And that concerns me, because I
> see some very competent and dedicated people working hard on QA, but I
> don't seem to be making effective use of that work.

I agree the issue we have is the following - How do we know the bug will
be interesting for you to fix ? How long is it going to take you to fix
it ? Why if you fix that bug, while in the same time you could fix 4
others. I think I have a problem here, in determining what will pop your
interest , and you now the component and code better than we do.

> Am I somehow not following the process that I am supposed to be
> following, or is that process flawed? In theory I am probably in a
> better position than most people here, because I primarily track items
> that appear in the mailnews core/filters component.

I think you are following the natural flow. We never had to my knowledge
any process. Something that would help us would be to know what your
roadmap for filter is so we could better tail what bugs you are after.

> I wish there was a clear way for the QA people to bring a limited number
> of bugs to my attention that are 1) important, 2) clearly defined and
> reproducible, and 3) likely to be fairly easy to fix.

So we could easily get 1 out of bugzilla (number of dupes, maybe number
of votes). Clearly define, might be for us in QA, but not always for you
(say a bad example we all do reproduce in QA, but you don't).

For the third point - we can't as we don't know the code and how easy it
is to fix implement. We would probably get a better idea with time. But
I personally don't follow much  bug once it's assigned, I just notice
that it lands and that I'll try to verify it.

> The mailnews core/filters category currently has 326
> NEW/ASSIGNED/REOPENED bugs in it. I could probably fix a few per month
> that were brought to my attention. A reasonable expectation might be
> that 10% of those are addressed in the next year. How are the QA folks
> supposed to influence the selection of which 32 bugs actually get my
> attention?

In an ideal world, all of them with your idea of where the component
should go .. Roadmaping it would help us figure out which one are good ,
which aren't.

We could cc you and add a keyword in the whiteboard, would that help ?
Or we could assign you to the bug, but if you don't have time to tackle
it those list will grow.
I know that from time to time I ping devs on IRC - but I don't always do
it , because I don't want to bother them too much and being put in some
/ignore list.

I'm open to suggestion as I think the last part of the process is
somewhat not defined.


Ludo
--
Ludovic Hirlimann MozillaMessaging QA lead
http://www.spreadthunderbird.com/aff/79/2
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

R Kent James
On 1/22/2010 12:27 PM, Ludovic Hirlimann wrote:
> On 22/01/10 19:45, Kent James wrote:
>
>> I would be curious to hear from people involved in QA about
>> what they view the main outcome of their work is supposed to be, as
>> viewed by a developer.
>>

I didn't get a clear answer from you on this, you just commented on my
guess of what it is. Could you describe *your* view of what you do?

rkent
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

Tony Mechelynck-2
In reply to this post by R Kent James
On 22/01/10 19:45, Kent James wrote:

> A few weeks ago on IRC dmose and I discussed the general issue of how QA
> communicates priorities to developers. I'd like to hear some comments on
> that from others, and possibly participate in some sort of trial of
> improvements.
>
> The issue here is that I see lots of good work going on by people who
> are mostly involved in QA, such as wsmwk, WADA, and Ludo, but I as a
> developer don't really know how to make the best use of that work.
>
> I assume there is supposed to be a waterfall here, from (bug
> reporter)->(QA)->(developer)->(code reviewer)->(bug landing). I
> understand all of the steps of the process except this (QA)->(developer)
> handoff. I would be curious to hear from people involved in QA about
> what they view the main outcome of their work is supposed to be, as
> viewed by a developer.
>
> Here's what my understanding is of the current process. After bugs are
> submitted, QA has three main responsibilities: 1) get the bug in the
> correct component, 2) move the status to NEW or one of the inactive
> states (DUPE, INVALID, etc.) 3) clarify the bug information to get clear
> steps to reproduce.
>
> Is this accurate?
>
> Let's look to see how that is working by looking at my recent work. In
> the last three months, I fixed eight bugs (that's a little off my
> desired pace, but we were frozen a lot of that time). What brought those
> bugs to my attention?
>
> (3) bugs I reported myself, either due to issues I observed or as a
> result of following support forums.
>
> (3) bugs are fixes of crashes that wsmwk reported from crash stats
>
> (2) bugs were filed earlier by others. If I recall correctly, both of
> those bugs were items that I noticed first in support forums, then
> located the bug in Bugzilla and fixed it.
>
> In no cases did the standard QA waterfall process play a significant
> role in bringing a bug to my attention. And that concerns me, because I
> see some very competent and dedicated people working hard on QA, but I
> don't seem to be making effective use of that work.
>
> Am I somehow not following the process that I am supposed to be
> following, or is that process flawed? In theory I am probably in a
> better position than most people here, because I primarily track items
> that appear in the mailnews core/filters component.
>
> I wish there was a clear way for the QA people to bring a limited number
> of bugs to my attention that are 1) important, 2) clearly defined and
> reproducible, and 3) likely to be fairly easy to fix.
>
> The mailnews core/filters category currently has 326
> NEW/ASSIGNED/REOPENED bugs in it. I could probably fix a few per month
> that were brought to my attention. A reasonable expectation might be
> that 10% of those are addressed in the next year. How are the QA folks
> supposed to influence the selection of which 32 bugs actually get my
> attention?
>
> (posted to http://mesquilla.com and m.d.a.thunderbird, followup to
> m.d.a.thunderbird please.)
>
> rkent

Sorry, I noticed the ending parenthesis too late, so I'm reposting here
what I posted over there:

I'm coming to this problem from the other side (as a triager, and not a
very active one), and there's a lot here that baffles me too. I think
there are two possible mechanisms to bring bugs to developers'
attention, and that neither is perfect:
- If the developer is particularly interested in bugs concerning some
Product/Component pair, he should "watch" the default QA address for
that Product/Component (the way I, as a triager, watch
[hidden email] which is where most new SeaMonkey bugs get
filed). He will then get bugmail whenever a new bug is filed in that P/C
or reassigned to it.
- If the triager knows (or thinks) that a bug is in some particular
developer's (or developers') ballpark, he should add the corresponding
entry or entries to the bug's Cc list in the hope of getting that
dev's/s' attention.
- One flaw of the above system is that it is easy to become flooded by a
lot of bugmail, to the point of not paying attention to all of them. So
what should we do? I don't know. Maybe timeless, who AFAICT gets at
least one (and sometimes several) bugmail message(s) for *every* bug
filed or changed at b.m.o., would have something better to contribute
than I can, about how to cope with all that bugmail.

P.S. An additional mechanism is that some people have predefined queries
and run them at intervals, to see if they bring out anything
interesting. Examples of searches that a triager might run could be
"SeaMonkey bugs unchanged in the latest 365 days" or "All Toolkit
Unconfirmed" etc. For a developer, it might be something slightly
different, like "NEW MailNews Core [but not ASSIGNED]" or "All bugs
assigned to me" etc.


Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
245. You use Real Audio to listen to a radio station from a distant
      city rather than turn on your stereo system.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

Ludovic Hirlimann-3
In reply to this post by R Kent James
On 23/01/10 00:31, Kent James wrote:

> On 1/22/2010 12:27 PM, Ludovic Hirlimann wrote:
>> On 22/01/10 19:45, Kent James wrote:
>>
>>> I would be curious to hear from people involved in QA about
>>> what they view the main outcome of their work is supposed to be, as
>>> viewed by a developer.
>>>
>
> I didn't get a clear answer from you on this, you just commented on my
> guess of what it is. Could you describe *your* view of what you do?

No I missed the question, sorry. There two sides of it.
The first side is to make sure that you don't loose too much coding time
maintaining bugzilla, and you only have to touch bugs when they are
clear and easily reproductible. So make sure that you spent the least
time in bugzilla so you have time to make the product better. That's the
first side.
Second side is testing new features and make sure that used of them ,
that weren't tested by the developer don't introduce new bugs - but that
doesn't fit into the how does QA signals the developer that some bug
should be fixed.


There's also something I forgot to mention in my previous reply. If I'm
affected by the bug and it's a feature I use a lot, I 'know I'll
pressure the developer to fix it faster.

Ludo
--
Ludovic Hirlimann MozillaMessaging QA lead
http://www.spreadthunderbird.com/aff/79/2
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

Ludovic Hirlimann-3
In reply to this post by Tony Mechelynck-2
On 23/01/10 02:38, Tony Mechelynck wrote:
> - One flaw of the above system is that it is easy to become flooded by a
> lot of bugmail, to the point of not paying attention to all of them. So
> what should we do? I don't know. Maybe timeless, who AFAICT gets at
> least one (and sometimes several) bugmail message(s) for *every* bug
> filed or changed at b.m.o., would have something better to contribute
> than I can, about how to cope with all that bugmail.

I asked timeless how he managed to almost alwys comment on crashers, the
answer was, querying his emails. So He does get everything that's
touched in bugzilla, he doesn't read everything and does some queries on
things he thinks are important to him or his work.

Ludo
--
Ludovic Hirlimann MozillaMessaging QA lead
http://www.spreadthunderbird.com/aff/79/2
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

WADA
In reply to this post by R Kent James
On Jan 23, 3:45 am, Kent James <[hidden email]> wrote:
> Here's what my understanding is of the current process. After bugs are
> submitted, QA has three main responsibilities: 1) get the bug in the
> correct component, 2) move the status to NEW or one of the inactive
> states (DUPE, INVALID, etc.) 3) clarify the bug information to get clear
> steps to reproduce.
>
> Is this accurate?

I don't know  there is *responsibilities* or not in our QA work.
But, main objectives in my QA works at B.M.O is those three, in order
to relief developers from such useless works for patch creation to
resolve bug.

> In no cases did the standard QA waterfall process play a significant
> role in bringing a bug to my attention.

Because I don't know who is responsible to fix bug, I simply change to
NEW if UNCOFIRMED, and change to blocker/critical/major if I believe
important bug.
If I know that someone fixed similar bugs and I think very important
bug, I sometimes cc the bug to a few developers I know name(you Kent,
David:B,  Dave M, Magnus, .....)
It's same for Fx/Sm's no-mail bug. I cc-ed to Asa Dotzler several
times in the past to ask him for help.

I think refinement of bugzilla.mozilla.org is required.
   Distinguish at least (a) "Problem Report" and (b) "real Bug Report"
Until release of Fx 1.0 and Tb 1.0, majority of "bug at B.M.O" was (b)
which was opened by developers or nightly testers.
But after release of Fx/Tb 1.0, majority of "bug at B.M.O" is (a), and
(a) is also used for support or help like request by general users. I
believe flood of (a) interfered bug fixing work by developers.
If we who are working for QA can change (a) to (b) when QA work is
successful, I think number of bugs which developer has to watch will
be significantly reduced.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

Nathan Tuggy
On 2010-01-23 01:35, WADA wrote:
 > I think refinement of bugzilla.mozilla.org is required.
 >    Distinguish at least (a) "Problem Report" and (b) "real Bug Report"
 > Until release of Fx 1.0 and Tb 1.0, majority of "bug at B.M.O" was (b)
 > which was opened by developers or nightly testers.
 > But after release of Fx/Tb 1.0, majority of "bug at B.M.O" is (a), and
 > (a) is also used for support or help like request by general users. I
 > believe flood of (a) interfered bug fixing work by developers.
 > If we who are working for QA can change (a) to (b) when QA work is
 > successful, I think number of bugs which developer has to watch will
 > be significantly reduced.

WADA, what would this look like? Are you thinking an additional keyword,
flag, state, or similar, perhaps, to denote "actual bug that needs to be
fixed by changing Mozilla code"? And how would this interact with the
existing infrastructure, e.g. NEW, WONTFIX, etc; components and so on;
and all the other bug metadata?
Would there have to be a way of filtering outgoing bugmail on it, or
would it be enough to just allow developers to write their own
in-Thunderbird filters to get rid of "useless" bugs?
I'm curious, partly because I'm trying to ramp up my own triaging work
and become more useful, and partly just as a general thing.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

R Kent James
In reply to this post by WADA
On 1/23/2010 1:35 AM, WADA wrote:
> On Jan 23, 3:45 am, Kent James<[hidden email]>  wrote:

> But, main objectives in my QA works at B.M.O is those three, in order
> to relief developers from such useless works for patch creation to
> resolve bug.

This comment, plus Ludo's similar "The first side is to make sure that
you don't loose too much coding time maintaining bugzilla", gives your
main mission as "saving time" to the developers. I think that you
undervalue the contribution that you could make, though maybe these are
just issues of wording in English. I would think that the goal is, or at
least should be, to ensure that the organization focuses its precious
resources on addressing the most important issues, so that we don't
waste time working on less important bugs while we ignore more important
bugs.

>
> Because I don't know who is responsible to fix bug, I simply change to
> NEW if UNCOFIRMED, and change to blocker/critical/major if I believe
> important bug.
> If I know that someone fixed similar bugs and I think very important
> bug, I sometimes cc the bug to a few developers I know name(you Kent,
> David:B,  Dave M, Magnus, .....)
> It's same for Fx/Sm's no-mail bug. I cc-ed to Asa Dotzler several
> times in the past to ask him for help.

Neither you nor Ludo seem to give the same importance to setting the
proper component that I thought was important. I watch at least Mailnews
Core/Filters, so setting the component to that is much more useful to me
than adding my name as a "cc". I can see that from your point of view
you don't know who is watching what, so it is not clear that the
component is important.  Is there some way in bz to see who is watching
each component implicitly through the qa email contact?

I see that you are using the severity field, which I pretty much ignore.
If we could agree that QA is managing that field, I could pay more
attention to it - though we would need to quit setting each and every
crasher to critical as is current policy. Also "enhancements" are
currently lower than "trivial" in the pecking order, and the same
triaging issues exists for enhancements as flaws. So the two extremes of
the importance status are currently meaningless, which does not help its
effectiveness IMHO.

>
> I think refinement of bugzilla.mozilla.org is required.
>     Distinguish at least (a) "Problem Report" and (b) "real Bug Report"

Isn't that the purpose of the UNCONFIRMED->NEW transition?

> Until release of Fx 1.0 and Tb 1.0, majority of "bug at B.M.O" was (b)
> which was opened by developers or nightly testers.
> But after release of Fx/Tb 1.0, majority of "bug at B.M.O" is (a), and
> (a) is also used for support or help like request by general users. I
> believe flood of (a) interfered bug fixing work by developers.
> If we who are working for QA can change (a) to (b) when QA work is
> successful, I think number of bugs which developer has to watch will
> be significantly reduced.

I was not aware of this history, so thank you for the perspective.

The current policy as I understand it is UNCONFIRMED->NEW plus cc is one
method of communication, and flags->blocking is the other. We should
keep doing the former, but it is not enough. As to flags->blocking, we
are overloading that to mean both "this is an important issue we need to
address" with "we will not ship until this is fixed." Near release the
blockers all get reset to the latter meaning and removed, which kills
their effectiveness as a tool for QA to communicate with developers. It
is meant to communicate to and from release triagers, and for that it is
effective.

As for the refinement, really a simple step is to agree on what bz
fields that QA will really attempt to maintain, so that developers can
reasonably rely on those fields as being accurate after QA as done their
work.

Perhaps I am just cluelessly stating what is current policy, but it
would be good if we could agree on the standard uses of the Severity
field as a mechanism for QC to communicate with developers. Severity as
it is defined at
https://bugzilla.mozilla.org/page.cgi?id=fields.html#bug_severity is not
really what I need to know. Rare crashers are not that important, while
a significant typo in the English user interface should block a release.

I started to propose a revised definition of the Severity field, but I
know I have proposed that before, and did not get any traction with it.
Is there any sense of agreement that a differently and well-defined
Severity field would be maintainable and useful?

What I would like to be able to do is to search on a component that I
care about, with (NEW || ASSIGNED || REOPENED) && (severity >= MAJOR)
and get a result that, at least in theory, QA has done their best to
assure are truly important issues that deserve my attention.

Do you think we are there today?

rkent
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

Ludovic Hirlimann-3
On 23/01/10 22:02, Kent James wrote:
> On 1/23/2010 1:35 AM, WADA wrote:
>> On Jan 23, 3:45 am, Kent James<[hidden email]>  wrote:

Little jet lag so take that with caution

>> But, main objectives in my QA works at B.M.O is those three, in order
>> to relief developers from such useless works for patch creation to
>> resolve bug.
>
> This comment, plus Ludo's similar "The first side is to make sure that
> you don't loose too much coding time maintaining bugzilla", gives your
> main mission as "saving time" to the developers. I think that you
> undervalue the contribution that you could make, though maybe these are
> just issues of wording in English. I would think that the goal is, or at
> least should be, to ensure that the organization focuses its precious
> resources on addressing the most important issues, so that we don't
> waste time working on less important bugs while we ignore more important
> bugs.

That's a good point - but sometime it's difficult to asses (ain't sure
if the spelling is correct here.) which bugs are important or not. To do
that wee need two metrics. The first one is how badly it affects the
users and how many users are affected - for some bugs we can easily
figure it out, for some others it's a bit more difficult.

The other is what are we trying to achieve with a product (all my rant
about road-mapping)

> Neither you nor Ludo seem to give the same importance to setting the
> proper component that I thought was important. I watch at least Mailnews
> Core/Filters, so setting the component to that is much more useful to me
> than adding my name as a "cc". I can see that from your point of view

So I don't see much value but I still try to do it most of the time
because as I said in an earlier message I know some components are being
watch. But I see more value in getting more details and clear steps than
moving component - That's what I was trying to say I think.

> you don't know who is watching what, so it is not clear that the
> component is important.  Is there some way in bz to see who is watching
> each component implicitly through the qa email contact?

no, unless you know the contact's bugzilla password. We have and IT bugs
requesting those numbers to make coverage better.

> I see that you are using the severity field, which I pretty much ignore.
> If we could agree that QA is managing that field, I could pay more
> attention to it - though we would need to quit setting each and every
> crasher to critical as is current policy. Also "enhancements" are
> currently lower than "trivial" in the pecking order, and the same
> triaging issues exists for enhancements as flaws. So the two extremes of
> the importance status are currently meaningless, which does not help its
> effectiveness IMHO.

Can you try to explain why you are ignoring it ?

>>
>> I think refinement of bugzilla.mozilla.org is required.
>>     Distinguish at least (a) "Problem Report" and (b) "real Bug Report"
>
> Isn't that the purpose of the UNCONFIRMED->NEW transition?
>
>> Until release of Fx 1.0 and Tb 1.0, majority of "bug at B.M.O" was (b)
>> which was opened by developers or nightly testers.
>> But after release of Fx/Tb 1.0, majority of "bug at B.M.O" is (a), and
>> (a) is also used for support or help like request by general users. I
>> believe flood of (a) interfered bug fixing work by developers.
>> If we who are working for QA can change (a) to (b) when QA work is
>> successful, I think number of bugs which developer has to watch will
>> be significantly reduced.
>
> I was not aware of this history, so thank you for the perspective.

Yes it used to be less noisy. If get satisfaction wasn't there I think
we would have more noise in bmo. I feel that less bugs requesting
support are open these days.

> The current policy as I understand it is UNCONFIRMED->NEW plus cc is one
> method of communication, and flags->blocking is the other. We should
> keep doing the former, but it is not enough. As to flags->blocking, we
> are overloading that to mean both "this is an important issue we need to
> address" with "we will not ship until this is fixed." Near release the
> blockers all get reset to the latter meaning and removed, which kills
> their effectiveness as a tool for QA to communicate with developers. It
> is meant to communicate to and from release triagers, and for that it is
> effective.
>
> As for the refinement, really a simple step is to agree on what bz
> fields that QA will really attempt to maintain, so that developers can
> reasonably rely on those fields as being accurate after QA as done their
> work.

That's a good idea. Can you give us your point of view as a developer on
which one we should maintain ?  Which one you watch, which one you query
 on ?

> Perhaps I am just cluelessly stating what is current policy, but it
> would be good if we could agree on the standard uses of the Severity
> field as a mechanism for QC to communicate with developers. Severity as
> it is defined at
> https://bugzilla.mozilla.org/page.cgi?id=fields.html#bug_severity is not
> really what I need to know. Rare crashers are not that important, while
> a significant typo in the English user interface should block a release.

I agree.

> I started to propose a revised definition of the Severity field, but I
> know I have proposed that before, and did not get any traction with it.
> Is there any sense of agreement that a differently and well-defined
> Severity field would be maintainable and useful?
>
> What I would like to be able to do is to search on a component that I
> care about, with (NEW || ASSIGNED || REOPENED) && (severity >= MAJOR)
> and get a result that, at least in theory, QA has done their best to
> assure are truly important issues that deserve my attention.
>
> Do you think we are there today?

No , but we could get there -once we agree on what you need (as see above).

--
Ludovic Hirlimann MozillaMessaging QA lead
http://www.spreadthunderbird.com/aff/79/2
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

Philip Chee
In reply to this post by Ludovic Hirlimann-3
On Sat, 23 Jan 2010 08:03:55 +0100, Ludovic Hirlimann wrote:

> On 23/01/10 02:38, Tony Mechelynck wrote:
>> - One flaw of the above system is that it is easy to become flooded by a
>> lot of bugmail, to the point of not paying attention to all of them. So
>> what should we do? I don't know. Maybe timeless, who AFAICT gets at
>> least one (and sometimes several) bugmail message(s) for *every* bug
>> filed or changed at b.m.o., would have something better to contribute
>> than I can, about how to cope with all that bugmail.
>
> I asked timeless how he managed to almost alwys comment on crashers, the
> answer was, querying his emails. So He does get everything that's
> touched in bugzilla, he doesn't read everything and does some queries on
> things he thinks are important to him or his work.

On the other hand the gavinbot says he manages to read all his bugmail.
And as far as I can tell, he is cc'ed on every bug I've ever looked at.

Phil

--
Philip Chee <[hidden email]>, <[hidden email]>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]A friend: someone who likes you even after they know you.
* TagZilla 0.066.6

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

Philip Chee
In reply to this post by Ludovic Hirlimann-3
On Sun, 24 Jan 2010 05:12:02 +0100, Ludovic Hirlimann wrote:

>> As for the refinement, really a simple step is to agree on what bz
>> fields that QA will really attempt to maintain, so that developers can
>> reasonably rely on those fields as being accurate after QA as done their
>> work.
>
> That's a good idea. Can you give us your point of view as a developer on
> which one we should maintain ?  Which one you watch, which one you query
>  on ?

I mostly watch certain components so QA moving bugs into the right
component is certainly useful to me.
<rant>
For example I watch the Error Console component. It's amazing how many
people use it to report javascript (or CSS) errors caused by badly coded
websites, when the component is about problems *of* the error console
itself.
</rant>

Phil

--
Philip Chee <[hidden email]>, <[hidden email]>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

Gervase Markham
In reply to this post by WADA
On 23/01/10 09:35, WADA wrote:
> I think refinement of bugzilla.mozilla.org is required.
>    Distinguish at least (a) "Problem Report" and (b) "real Bug Report"

This is sort of what UNCONFIRMED vs. NEW is, but there have been
proposals in the past to add a new state, READY, which means "please
come and fix me now". Restarting this discussion and reaching a
resolution is something I want to do in 2010.

Gerv
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

Ron K.
Gervase Markham on 1/25/2010 9:05 AM, keyboarded a reply:

> On 23/01/10 09:35, WADA wrote:
>> I think refinement of bugzilla.mozilla.org is required.
>>    Distinguish at least (a) "Problem Report" and (b) "real Bug Report"
>
> This is sort of what UNCONFIRMED vs. NEW is, but there have been
> proposals in the past to add a new state, READY, which means "please
> come and fix me now". Restarting this discussion and reaching a
> resolution is something I want to do in 2010.
>
> Gerv

Personally I like the 'Ready' state idea. It has the value of saying that
QA has looked at the bug and has evaluated the STR and the bug exists.
While 'New' can be argued as doing the same, it's not quite the same. To me
'New' would apply to a bug that has merit, yet is incomplete and the OP is
working with QA to get the bug to 'Ready' state.

Here again, the existing 'Incomplete' conflicts. However the 'Incomplete'
status is more of a historical record keeping status. From time to time
'Incomplete' bugs never progress because QA was unable to contact the OP to
assist with filling in the info gaps. I have run into this case where the
OP moved to a new address and never updated there bug report.

--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported Major Error used BSOD to msg the enemy!
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

Wayne Mery
In reply to this post by Ludovic Hirlimann-3
On 1/23/2010 11:12 PM, Ludovic Hirlimann wrote:

> On 23/01/10 22:02, Kent James wrote:
>> On 1/23/2010 1:35 AM, WADA wrote:
>>> On Jan 23, 3:45 am, Kent James<[hidden email]>   wrote:
>
> Little jet lag so take that with caution
>
>>> But, main objectives in my QA works at B.M.O is those three, in order
>>> to relief developers from such useless works for patch creation to
>>> resolve bug.
>>
>> This comment, plus Ludo's similar "The first side is to make sure that
>> you don't loose too much coding time maintaining bugzilla", gives your
>> main mission as "saving time" to the developers. I think that you
>> undervalue the contribution that you could make, though maybe these are
>> just issues of wording in English. I would think that the goal is, or at
>> least should be, to ensure that the organization focuses its precious
>> resources on addressing the most important issues, so that we don't
>> waste time working on less important bugs while we ignore more important
>> bugs.
>
> That's a good point - but sometime it's difficult to asses (ain't sure
> if the spelling is correct here.) which bugs are important or not. To do
> that wee need two metrics. The first one is how badly it affects the
> users and how many users are affected - for some bugs we can easily
> figure it out, for some others it's a bit more difficult.
>
> The other is what are we trying to achieve with a product (all my rant
> about road-mapping)
>
>> Neither you nor Ludo seem to give the same importance to setting the
>> proper component that I thought was important. I watch at least Mailnews
>> Core/Filters, so setting the component to that is much more useful to me
>> than adding my name as a "cc". I can see that from your point of view
>
> So I don't see much value but I still try to do it most of the time
> because as I said in an earlier message I know some components are being
> watch. But I see more value in getting more details and clear steps than
> moving component - That's what I was trying to say I think.
>
>> you don't know who is watching what, so it is not clear that the
>> component is important.  Is there some way in bz to see who is watching
>> each component implicitly through the qa email contact?
>
> no, unless you know the contact's bugzilla password. We have and IT bugs
> requesting those numbers to make coverage better.
>
>> I see that you are using the severity field, which I pretty much ignore.
>> If we could agree that QA is managing that field, I could pay more
>> attention to it - though we would need to quit setting each and every
>> crasher to critical as is current policy. Also "enhancements" are
>> currently lower than "trivial" in the pecking order, and the same
>> triaging issues exists for enhancements as flaws. So the two extremes of
>> the importance status are currently meaningless, which does not help its
>> effectiveness IMHO.
>
> Can you try to explain why you are ignoring it ?
>
>>>
>>> I think refinement of bugzilla.mozilla.org is required.
>>>      Distinguish at least (a) "Problem Report" and (b) "real Bug Report"
>>
>> Isn't that the purpose of the UNCONFIRMED->NEW transition?
>>
>>> Until release of Fx 1.0 and Tb 1.0, majority of "bug at B.M.O" was (b)
>>> which was opened by developers or nightly testers.
>>> But after release of Fx/Tb 1.0, majority of "bug at B.M.O" is (a), and
>>> (a) is also used for support or help like request by general users. I
>>> believe flood of (a) interfered bug fixing work by developers.
>>> If we who are working for QA can change (a) to (b) when QA work is
>>> successful, I think number of bugs which developer has to watch will
>>> be significantly reduced.
>>
>> I was not aware of this history, so thank you for the perspective.
>
> Yes it used to be less noisy. If get satisfaction wasn't there I think
> we would have more noise in bmo. I feel that less bugs requesting
> support are open these days.
>
>> The current policy as I understand it is UNCONFIRMED->NEW plus cc is one
>> method of communication, and flags->blocking is the other. We should
>> keep doing the former, but it is not enough. As to flags->blocking, we
>> are overloading that to mean both "this is an important issue we need to
>> address" with "we will not ship until this is fixed." Near release the
>> blockers all get reset to the latter meaning and removed, which kills
>> their effectiveness as a tool for QA to communicate with developers. It
>> is meant to communicate to and from release triagers, and for that it is
>> effective.
>>
>> As for the refinement, really a simple step is to agree on what bz
>> fields that QA will really attempt to maintain, so that developers can
>> reasonably rely on those fields as being accurate after QA as done their
>> work.
>
> That's a good idea. Can you give us your point of view as a developer on
> which one we should maintain ?  Which one you watch, which one you query
>   on ?
>
>> Perhaps I am just cluelessly stating what is current policy, but it
>> would be good if we could agree on the standard uses of the Severity
>> field as a mechanism for QC to communicate with developers. Severity as
>> it is defined at
>> https://bugzilla.mozilla.org/page.cgi?id=fields.html#bug_severity is not
>> really what I need to know. Rare crashers are not that important, while
>> a significant typo in the English user interface should block a release.
>
> I agree.
>
>> I started to propose a revised definition of the Severity field, but I
>> know I have proposed that before, and did not get any traction with it.
>> Is there any sense of agreement that a differently and well-defined
>> Severity field would be maintainable and useful?
>>
>> What I would like to be able to do is to search on a component that I
>> care about, with (NEW || ASSIGNED || REOPENED)&&  (severity>= MAJOR)
>> and get a result that, at least in theory, QA has done their best to
>> assure are truly important issues that deserve my attention.
>>
>> Do you think we are there today?
>
> No , but we could get there -once we agree on what you need (as see above).
>

I am shocked you suggest an overloaded use/definition of severity, given
the problems we've identified in the overloading of certain mail fields.
Yes, severity doesn't indicate priority or total impact. It's defined as
impact on an individual, and we shouldn't  overlay it and alter the
definition and use of the states to fit other needs.

We have plenty of other tools at our disposal:
- Status - we can be more consistent about setting NEW; too often a bug
not ready for fixing doesn't stay at UNCO, or don't change a bug back to
UNCO when it got to NEW because someone's standards were "I see this
bug" instead of we can reproduce, and we have good steps (triagers and
devs with privs are probably prime offenders, myself included), etc
- priority ("the importance and order in which a bug should be fixed")
- status whiteboard
- CC
- keyword: like qawanted, qablocker, testcase
- blocking flags

Whiteboard is especially powerful - triagers are using whiteboard to
indicate "sub-status" of UNCO bugs, for example [needs protocol log].
Another example is [ccbr], for crash bug in NEW status which has more
than just "stack".

But the bigger issue, as others have mentioned, is it's difficult to
assess importance, which comprises many things:
- what % of users may be affected
- is it a regression
- to what extent does severity affect
- is workflow significantly impacted (even if bug is severity=minor)
- am I personally impacted
- where might this bug fit in the release cycle, and are we going to
miss one

So the following questions might help:
- What are your top concerns/goals for the filter component?
- Is there a sense of what to target for 3.1, 3.<next>, etc
- What do you consider to be important factors in assigning priority to
bugs? Can you give a few example bug#s?
- Are there current important bugs that need additional more QA before
fixing?






--
http://wiki.mozilla.org/Thunderbird:Testing
http://www.spreadthunderbird.com/aff/165/
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

Wayne Mery
In reply to this post by Ludovic Hirlimann-3
On 1/22/2010 3:27 PM, Ludovic Hirlimann wrote:

> On 22/01/10 19:45, Kent James wrote:
>
>> The issue here is that I see lots of good work going on by people who
>> are mostly involved in QA, such as wsmwk, WADA, and Ludo, but I as a
>> developer don't really know how to make the best use of that work.
>>
>> I assume there is supposed to be a waterfall here, from (bug
>> reporter)->(QA)->(developer)->(code reviewer)->(bug landing). I
>> understand all of the steps of the process except this (QA)->(developer)
>> handoff. I would be curious to hear from people involved in QA about
>> what they view the main outcome of their work is supposed to be, as
>> viewed by a developer.
>>
>> Here's what my understanding is of the current process. After bugs are
>> submitted, QA has three main responsibilities: 1) get the bug in the
>> correct component, 2) move the status to NEW or one of the inactive
>> states (DUPE, INVALID, etc.) 3) clarify the bug information to get clear
>> steps to reproduce.
>>
>> Is this accurate?
>
> I don't think putting the bug in the correct component adds much value.

(this is more to ludo's comment than rkent's question)

I don't understand this opinion given:

a) it's not possible for most people to handle significant bugmail
volume or effectively parse large bug queries, but putting bugs in
smaller buckets potentially reduces query size and bugmail for people
who don't care about some bug subjects, so less time hitting delete, etc
b) getting more expertise on a bug is totally a good thing, and good
component assignment helps devs and triagers who watch certain types of
bug (components) either because of skill or interest
c) accurate components makes it easier to later triage and analyze bugs
of like type
d) components are generally, by definition, "the location of the code
being fixed"
e) it's not just triagers and devs that follow component qa addresses -
there are people that just care about certain types of bugs
f) not all triagers and bug filers knows which devs are good to CC on a
particular bug - but component definitions are fairly easy to understand
g) (in a follow up post if I remember - anyone else have ideas?)

And so I disagree that correct component is of less value than any other
aspect of bug "correctness". Is it absolutely required to get a bug
fixed? No, certainly not. But it helps there, and in other areas and so
it is not of less value IMO.

Indeed I'd go even further to say the *sooner* a bug gets in a good
component the better (even before the bug is confirmed as NEW). Changing
component on first touching a bug means less  bugmail, less time
triaging, and bugs potentially get fixed quicker. (and it really doesn't
matter if the first component change isn't accurate, there's nothing
wrong with changing component a second or third time)


> We do it for two reasons, some people are following some components and
> not others , and that might help the triage process (but frankly tot do
> that I usually cc people).

Is the above meant to be 2 reasons?

>> Let's look to see how that is working by looking at my recent work. In
>> the last three months, I fixed eight bugs (that's a little off my
>> desired pace, but we were frozen a lot of that time). What brought those
>> bugs to my attention?
>>
>> (3) bugs I reported myself, either due to issues I observed or as a
>> result of following support forums.
>>
>> (3) bugs are fixes of crashes that wsmwk reported from crash stats
>>
>> (2) bugs were filed earlier by others. If I recall correctly, both of
>> those bugs were items that I noticed first in support forums, then
>> located the bug in Bugzilla and fixed it.
>>
>> In no cases did the standard QA waterfall process play a significant
>> role in bringing a bug to my attention. And that concerns me, because I
>> see some very competent and dedicated people working hard on QA, but I
>> don't seem to be making effective use of that work.
>
> I agree the issue we have is the following - How do we know the bug will
> be interesting for you to fix ? How long is it going to take you to fix
> it ? Why if you fix that bug, while in the same time you could fix 4
> others. I think I have a problem here, in determining what will pop your
> interest , and you now the component and code better than we do.
>
>> Am I somehow not following the process that I am supposed to be
>> following, or is that process flawed? In theory I am probably in a
>> better position than most people here, because I primarily track items
>> that appear in the mailnews core/filters component.

A "best" bugzilla workflow that fits everyone is difficult to achieve
consensus on.  Have a look in mozilla.dev.planning at the following
large threads ...  [gerv just posted about these]

Triage workflow proposal.
Bugzilla workflow proposal: "getting bugs done"
bugzilla.mozilla.org improvements
Complete workflow reorganization

Take just one aspect like NEW, there is significant variability in how
people define and use it. From a time perspective, ideally devs would
only have to touch bugs that are totally ready for fixing, which is what
NEW is defined as iirc. But:
* not everyone uses that definition in practice
* not all bugs in NEW are or off good quality
* lots of devs choose to get bugmail for unconfirmed bugs

But bug workflow is an entire universe unto itself.  The more tractable
area is how can we do better in the Filters component. And maybe expand
from there.  So ...

> I'm open to suggestion as I think the last part of the process is
> somewhat not defined.

see follow up to ludo's followup to rkent's posting on 1/23
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

R Kent James
In reply to this post by Gervase Markham
On 1/25/2010 6:05 AM, Gervase Markham wrote:
> This is sort of what UNCONFIRMED vs. NEW is, but there have been
> proposals in the past to add a new state, READY, which means "please
> come and fix me now".

I think that would be an excellent idea.

I can see that there are two main issues of QA->Developer communication:

1) How does QA communicate that they have finished triaging the bug, and
believe it to be real and worthy of developer attention? READY fills
that need. NEW, as currently used, does not.

2) How does QA communicate their sense of bug importance? We need
something for that as well.

rkent
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

R Kent James
In reply to this post by Ludovic Hirlimann-3
On 1/23/2010 8:12 PM, Ludovic Hirlimann wrote:
> On 23/01/10 22:02, Kent James wrote:

>> >  I see that you are using the severity field, which I pretty much ignore.

> Can you try to explain why you are ignoring it ?

I ignore it primarily because I don't see much activity in changing it
on bugs that I watch, so I assume that it is not being maintained. And
as I stated earlier, the "Critical" usage for crashers makes no sense to me.

>> >  As for the refinement, really a simple step is to agree on what bz
>> >  fields that QA will really attempt to maintain, so that developers can
>> >  reasonably rely on those fields as being accurate after QA as done their
>> >  work.

> That's a good idea. Can you give us your point of view as a developer on
> which one we should maintain ?  Which one you watch, which one you query
> on ?

There is a chicken and egg problem here. I will watch whatever QA agrees
they will reliably maintain to communicate triage status and importance.
Hopefully in this thread we are trying to establish what those are. I
proposed a redefined "Severity", Wayne didn't like that and has some
other proposals.

rkent
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

Wayne Mery
On 1/25/2010 11:15 AM, Kent James wrote:

> On 1/23/2010 8:12 PM, Ludovic Hirlimann wrote:
>> On 23/01/10 22:02, Kent James wrote:
>
>>> > I see that you are using the severity field, which I pretty much
>>> ignore.
>
>> Can you try to explain why you are ignoring it ?
>
> I ignore it primarily because I don't see much activity in changing it
> on bugs that I watch, so I assume that it is not being maintained. And
> as I stated earlier, the "Critical" usage for crashers makes no sense to
> me.

This depends on the triager and the bug submitter. I tend to change
severity because it improves the total story of the bug and, when
researching bugs for example, sometimes I don't want to see bugs of a
certain type - like those that have workarounds (sev=minor).

Conversely, you have people who set sev=major on bugs that really
"bother them", when in fact they should be sev=minor because
* they have easy workaround
* don't greatly affect workflow
* ...

>>> > As for the refinement, really a simple step is to agree on what bz
>>> > fields that QA will really attempt to maintain, so that developers can
>>> > reasonably rely on those fields as being accurate after QA as done
>>> their
>>> > work.
>
>> That's a good idea. Can you give us your point of view as a developer on
>> which one we should maintain ? Which one you watch, which one you query
>> on ?
>
> There is a chicken and egg problem here. I will watch whatever QA agrees
> they will reliably maintain to communicate triage status and importance.
> Hopefully in this thread we are trying to establish what those are. I
> proposed a redefined "Severity", Wayne didn't like that and has some
> other proposals.
>
> rkent

Right. Severity alone does not give a full picture, or even a good one,
  in conveying bug importance.  In fact there is nothing that gives a
full picture - for example you cant see from looking at bugzilla's
fields whether a bug has steps to reproduce and if it always happens.

Here's a thought, and what is part of the problem, we probably could use
more flags. If we had more flags for what's in the bug, you could have
bugzilla *calculate* a numerical importance which could then be used to
rank bugs against each other. This would free the triager from assigning
a rank to a bug (like P1) which is static and therefore of less
usefulness over time (as releases and "ideas" about field importance
change), and that has a good chance of not agreeing with some dev's
definition of what weightings and factors make a bug "important".

More flags would also mean that new triagers (and bug reporters) would
see these flags in bugzilla and instantly know what makes a good bug,
rather than have to read a document about what's a good bug, having to
know what whiteboard tags might be used for what situations, etc.

On a different track, note there is zero guarantee of continuity and
uniformity in bugzilla
* even if we change some definitions or add some protocol it won't be
uniformly applied, just as now NEW doesn't guarantee it's ready for
fixing, that not everyone touches severity even for crashes, regression
keyword is not always used, blah, blah...
* there is no "cradle to grave" concept of bug ownership - so just
because I am a first responder doesn't mean I'm going to follow up and
finish the bug out even if the reporter replies, or that a bug reporter
sticks with a bug (we currently place no formal responsibilities on bug
reporters)

I do hope we come up with something better. But in the end
* some bugs will linger in states that aren't "developer ready", even if
a bug has everything a dev needs to fix it
* even if a bug gets tagged "ready for dev", the developer probably
still has to do some vetting, and digging to determine importance


--
http://wiki.mozilla.org/Thunderbird:Testing
http://www.spreadthunderbird.com/aff/165/
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: QA -> Developers communication

Magnus Melin
In reply to this post by R Kent James
On 25.01.2010 18:06, Kent James wrote:

> On 1/25/2010 6:05 AM, Gervase Markham wrote:
>> This is sort of what UNCONFIRMED vs. NEW is, but there have been
>> proposals in the past to add a new state, READY, which means "please
>> come and fix me now".
>
> I think that would be an excellent idea.
>
> I can see that there are two main issues of QA->Developer communication:
>
> 1) How does QA communicate that they have finished triaging the bug, and believe
> it to be real and worthy of developer attention? READY fills that need. NEW, as
> currently used, does not.

While it might not always, i don't think adding another state would really help.
I was under the impression a resolution was indeed reached in the
do-we-need-a-ready-state discussion, and that resolution was no we don't.

  -Magnus
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
12