Summary of TB QA Meeting at Mozcamp

[Mike Conley]

All,

I took minutes during the TB QA meeting at MozCamp.

Minutes can be found here starting on line 18:

https://etherpad.mozilla.org/tb-qa

Here's a summary:

Summary

• The rapid release has really changed the way we do testing. Community involvement has dropped off.

• Ludo has no chance of watching all of Bugzilla, and sometimes somebody comes in with a patch, and we don't see it because they don't set the right flags, and then it gets bitrotted and we lose a potential contributor.

• We need more people to be active on Bugzilla, to take action on bugs, to respond when somebody files a bug to get the information we need to fix it (if you reply within 1 day, you have a higher degree of probability of getting useful information for fixing it).

• The "bubbling up" of bugs from Bugzilla to devs to being fixed is what needs work. People are getting frustrated when they file bugs and *nothing happens*. Letting people know that when they file bugs properly, that things happen...that's important.

• The notion of what NEW means on Bugzilla is different from person to  person. Some people think NEW means, "this bug is reproducable". Others  think it means "this bug is reproducable, and we know where the fix  needs to happen."

• IDing of bugs, of prioritizing them for being fixed - we need to look into new and better ways of doing this.

• There are 4 dimensions for categorizing bugs:

• How many people are likely to be affected

• How serious is the effect when it occurs (workaround? consequences)

• How much effort to fix this bug?

• How reproducible it is

• We need some way of visualizing bugs along these dimensions, and then a way of consolidating that visualization into a prioritized list.

• But generating lists is easy. We've been generating lists for YEARS. The problem is that we create a list, fix a few things on it, and then create a new list, and repeat.

• Fixing old bugs has taken a backseat in favour of feature development over the past few releases

• Ludo is concerned about performance problems in TB - his TB on his beefy machine is just as performant as TB 1.x was on his old crappy machine. That's not a good sign.

• Irving advocates a light-weight, "agile" list that is designed to be easily changed iteration after iteration, based on what is happening at the time. The list should make it easy to visualize the "life-cycle" of a bug, and allow us to measure how long it takes for a bug to go from being identified, to being fixed. That lets us know how many things to put on the list, and we can adjust accordingly.

• We need a way for developers to examine a bug, and deprioritize it if it is way too complicated - ie, the rewards are too slim based on how much work is likely involved. (Spending time thinking about the hard / impossible bugs is less valuable than fixing the bugs that we're likely to tackle and complete)

• We're going to tackle the Papercuts list, and see what happens. If we can show that we can fix the items on a list, and move the ball forward, then we'll worry about creating the list.

• QA people think, "We make lists and you devs ignore them!", devs think, "You QA people make lists, and we can't do anything with them!". We need to resolve this.

• The list should be mutable. We need to be able to change our minds. We don't want to thrash, but we want to be able to make adjustments.

• We need criteria to create the initial list.

Action items

1. Get a list of people watching each TB component, and make sure we've got somebody with eyes on each one.
2. We're going to tackle the Papercuts list (10 bugs) to prove that we can deal with a list.
3. rkent(?) is going to send out a weekly status report on the Papercuts list, and what needs fixing, on what got fixed.
4. When the list is empty, or close to being empty, QA is going to develop a process for creating the list (which includes the facility for devs to indicate that a bug is too difficult).
5. We need to come up with some critiera for choosing bugs like the ones on Papercuts. Then QA / Support will build the list.

[Joshua Cranmer]

On 9/11/2012 1:47 PM, Mike Conley wrote:

All,

I took minutes during the TB QA meeting at MozCamp.

Minutes can be found here starting on line 18:

https://etherpad.mozilla.org/tb-qa

Here's a summary:

Summary

• The rapid release has really changed the way we do testing. Community involvement has dropped off.

• Ludo has no chance of watching all of Bugzilla, and sometimes somebody comes in with a patch, and we don't see it because they don't set the right flags, and then it gets bitrotted and we lose a potential contributor.

One of the more recent bmo changes allowed more people to access whines... if we can construct a query for all new patches without reviewers (given Bugzilla, this might not be possible), it should be simple enough just to have someone get whined for this sort of stuff.

Action items

1. Get a list of people watching each TB component, and make sure we've got somebody with eyes on each one.
2. We're going to tackle the Papercuts list (10 bugs) to prove that we can deal with a list.
3. rkent(?) is going to send out a weekly status report on the Papercuts list, and what needs fixing, on what got fixed.

I was under the impression that the weekly status report on The List was going to be managed by QA / Support. It's also not clear who will be receiving the status report on The List.

4. When the list is empty, or close to being empty, QA is going to develop a process for creating the list (which includes the facility for devs to indicate that a bug is too difficult).
5. We need to come up with some critiera for choosing bugs like the ones on Papercuts. Then QA / Support will build the list.

-- 
Joshua Cranmer
News submodule owner
DXR coauthor

[Kent James]

On 9/11/2012 12:41 PM, Joshua Cranmer wrote:

On 9/11/2012 1:47 PM, Mike Conley wrote:

Action items

1. Get a list of people watching each TB component, and make sure we've got somebody with eyes on each one.
2. We're going to tackle the Papercuts list (10 bugs) to prove that we can deal with a list.
3. rkent(?) is going to send out a weekly status report on the Papercuts list, and what needs fixing, on what got fixed.

I was under the impression that the weekly status report on The List was going to be managed by QA / Support. It's also not clear who will be receiving the status report on The List.

Going forward, there is not going to be enough (paid) QA/support around to maintain The List. Looking backward, I don't think that QA/Support has felt sufficiently empowered to regularly bug developers to work on specific papercut issues.

A "developer lead" need to advocate for getting things on the list fixed. A "QA/support" lead needs to advocate to add things to the list. Since we agreed at the meeting that the issue in the past has been getting things fixed, I have volunteered (post TB-17) to serve  as the "developer lead" in this narrow case to advocate for getting things fixed.

rkent

[Gervase Markham]

On 11/09/12 20:41, Joshua Cranmer wrote:
> One of the more recent bmo changes allowed more people to access
> whines... if we can construct a query for all new patches without
> reviewers (given Bugzilla, this might not be possible), it should be
> simple enough just to have someone get whined for this sort of stuff.

Here are all open Thunderbird review requests:

https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Thunderbird&type=review&requestee=&component=&group=type

You can't specifically restrict it to ones without a requestee, but you
could post-filter it in a simple program. There's an undocumented
feature for computer-readable output - add "&ctype=csv" to get CSV.

Gerv
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning

[acel...@atlas.sk]

Hi, there is something wrong with that query as it misses most of my pending requests.
Maybe it should include "Mailnews Core" too?

Also maybe adding ui-review would be in order too.

You can set "Group by requestee" and then the requests with a value of "none" get on top.

aceman
______________________________________________________________
> Od: "Gervase Markham" <ge...@mozilla.org>
> Komu: "tb-pl...@mozilla.org" <tb-pl...@mozilla.org>
> Dátum: 12.09.2012 17:07
> Predmet: Re: Summary of TB QA Meeting at Mozcamp

[Gervase Markham]

On 12/09/12 16:15, acel...@atlas.sk wrote:
> Hi, there is something wrong with that query as it misses most of my pending requests.
> Maybe it should include "Mailnews Core" too?

Sure. It was a sample URL. Not sure if it accepts multiple "product"
parameters or "type" parameters but, if not, just make and concatenate
multiple requests.

[acel...@atlas.sk]

It seems it does:

https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=MailNews+Core&product=Thunderbird&type=review&requestee=&component=&group=requestee

This also includes the sorting by requestee so the "none" one is on top.

______________________________________________________________
> Od: "Gervase Markham" <ge...@mozilla.org>

> Komu: <acel...@atlas.sk>
> Dátum: 12.09.2012 17:21

> Predmet: Re: Summary of TB QA Meeting at Mozcamp
>

> CC: "tb-pl...@mozilla.org" <tb-pl...@mozilla.org>

[Ludovic Hirlimann]

On 9/12/12 5:07 PM, Gervase Markham wrote:
> On 11/09/12 20:41, Joshua Cranmer wrote:
>> One of the more recent bmo changes allowed more people to access
>> whines... if we can construct a query for all new patches without
>> reviewers (given Bugzilla, this might not be possible), it should be
>> simple enough just to have someone get whined for this sort of stuff.
> Here are all open Thunderbird review requests:
>
> https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Thunderbird&type=review&requestee=&component=&group=type
>
> You can't specifically restrict it to ones without a requestee, but you
> could post-filter it in a simple program. There's an undocumented
> feature for computer-readable output - add "&ctype=csv" to get CSV.
>
>

That won't catch people that don't know how to reveiw request and just
post patches.

--
@lhirlimann on twitter
https://wiki.mozilla.org/Thunderbird:Testing

[Wayne Mery (d531)]

On 9/11/2012 3:41 PM, Joshua Cranmer wrote:
> One of the more recent bmo changes allowed more people to access
> whines...

Joshua, could you elaborate please on increased access to whines?

[Joshua Cranmer]

On 9/16/2012 9:28 AM, Wayne Mery (d531) wrote:
> On 9/11/2012 3:41 PM, Joshua Cranmer wrote:
>> One of the more recent bmo changes allowed more people to access
>> whines...
>
> Joshua, could you elaborate please on increased access to whines?

It seems this changed again recently, but it seemed that, for a while at
least, more people had access to whines.

--
Joshua Cranmer
News submodule owner
DXR coauthor

[Mark Banner]

On 12/09/2012 16:07, Gervase Markham wrote:
> On 11/09/12 20:41, Joshua Cranmer wrote:
>> One of the more recent bmo changes allowed more people to access
>> whines... if we can construct a query for all new patches without
>> reviewers (given Bugzilla, this might not be possible), it should be
>> simple enough just to have someone get whined for this sort of stuff.
> Here are all open Thunderbird review requests:
>
> https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Thunderbird&type=review&requestee=&component=&group=type
>
> You can't specifically restrict it to ones without a requestee, but you
> could post-filter it in a simple program. There's an undocumented
> feature for computer-readable output - add "&ctype=csv" to get CSV.

I think I've done this in a slightly different way and managed to get
the list of patches with no requestee. I've shared the query and it can
be found here:

https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=ReviewsNoRequestee

(Yes, there's one item in the list, which I'll sort out soon)

I've also set up a whine, so that bugzilla will whine at me once a week
if there's bugs that match that query.

Mark.

[Mark Banner]

On 12/09/2012 20:05, Ludovic Hirlimann wrote:
> On 9/12/12 5:07 PM, Gervase Markham wrote:
>> On 11/09/12 20:41, Joshua Cranmer wrote:
>>> One of the more recent bmo changes allowed more people to access
>>> whines... if we can construct a query for all new patches without
>>> reviewers (given Bugzilla, this might not be possible), it should be
>>> simple enough just to have someone get whined for this sort of stuff.
>> Here are all open Thunderbird review requests:
>>
>> https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Thunderbird&type=review&requestee=&component=&group=type
>>
>> You can't specifically restrict it to ones without a requestee, but you
>> could post-filter it in a simple program. There's an undocumented
>> feature for computer-readable output - add "&ctype=csv" to get CSV.
>>
>>
> That won't catch people that don't know how to reveiw request and just
> post patches.
>

The two ideas I've come up with on this so far are:

1) watch all bugs in relevant products and use mail filtering to watch
for new attachments that are then flagged.

2) use the bugzilla API to construct a query of all the attachments, and
flag ones without requests. We'd then need some sort of additional
database/keyword to ignore ones that were there the previous time the
query was run, and probably integrate that with the ability to flag ones
that had already been looked at etc.

Mark.

[Mark Banner]

On 18/09/2012 14:53, Mark Banner wrote:
> On 12/09/2012 16:07, Gervase Markham wrote:
>> On 11/09/12 20:41, Joshua Cranmer wrote:
>>> One of the more recent bmo changes allowed more people to access
>>> whines... if we can construct a query for all new patches without
>>> reviewers (given Bugzilla, this might not be possible), it should be
>>> simple enough just to have someone get whined for this sort of stuff.

...
> https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=ReviewsNoRequestee
>
https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=ReviewsNoRequestee&sharer_id=112088
is the correct link

Mark.

[Ludovic Hirlimann]

On 9/11/12 8:47 PM, Mike Conley wrote:

Action items

1. Get a list of people watching each TB component, and make sure we've got somebody with eyes on each one.

I got a list for Thunderbird and MailNewsCore, the smallest subset of bug followers for a component is 3 (excluding people that watch everything). On this list there are plenty of emails addresses that are not active (eg they follow the component and that's it), and I say that because I don't recall those email addresses making any comments. On the other hand some very active people don't follow *any* components and they do most of the work in bugzilla.

So the question isn't too much about following component like I initially though. It's more about getting traction on bugs, which means :

• Getting the useful information.
• Figuring out how bad the bug is.
• Getting the bug in the right hands.
  

For that we need less people that follow bugzilla but more people that are active in bugzilla and engaging the users that are reporting the bugs. I think the people already active in bugzilla are the people that can spot new active members and engage them into being even more active. I've done that over the years and a small email works, trying to give hints and task to accomplish helps even more.

For the new comers I've written this how-to https://wiki.mozilla.org/Thunderbird:Testing/bugzilla and I need your feedback :

• is it clear ?
• is it complete ?
• can a new comer follow these guidelines ?

Sherriffing bugzilla was also an idea I had. That means create a schedule/calendar and have people being on duties on certain days to answer the new bugs of the day. For this to work we'd need a lot of people and people that sign up doing it. Do you guys think it's a feasible idea ?

Ludo
ps cc Thunderbird testers as they might want to participate to our discussions on the future of testing/quality for Thunderbird.

-- 
@lhirlimann on twitter
https://wiki.mozilla.org/Thunderbird:Testing

my photos http://www.flickr.com/photos/lhirlimann/collections/

[Wayne Mery (d531)]

On 9/11/2012 4:28 PM, Kent James wrote:
> On 9/11/2012 12:41 PM, Joshua Cranmer wrote:
>> On 9/11/2012 1:47 PM, Mike Conley wrote:

>>> *Action items*
>>>
>>> 1. Get a list of people watching each TB component, and make sure

>>> we've got somebody with eyes on each one.

>>> 2. We're going to tackle the Papercuts list (10 bugs) to prove that

>>> we can deal with a list.

>>> 3. rkent(?) is going to send out a weekly status report on the

>>> Papercuts list, and what needs fixing, on what got fixed.
>>>
>> I was under the impression that the weekly status report on The List
>> was going to be managed by QA / Support. It's also not clear who will
>> be receiving the status report on The List.

Which "The List" do you refer too? The papercuts list? Or the "most
important bugs" list, which we discussed at mozcamp and which is
different from papercuts? (I see the two lists as coexisting)

> Going forward, there is not going to be enough (paid) QA/support around
> to maintain The List.
>
> Looking backward, I don't think that QA/Support
> has felt sufficiently empowered to regularly bug developers to work on
> specific papercut issues.

Indeed - it is not been "our place" to make such decisions. Though we
can communicate our thoughts. Just has it has not been the case for users.

> A "developer lead" need to advocate for getting things on the list
> fixed. A "QA/support" lead needs to advocate to add things to the list.
> Since we agreed at the meeting that the issue in the past has been
> getting things fixed, I have volunteered (post TB-17) to serve as the
> "developer lead" in this narrow case to advocate for getting things fixed.
>
> rkent

Yes, I think having someone on the dev end to categorize bugs and watch
the flow is going in the right direction. I think Mark has functioned in
this capacity in some ways.

[Kent James]

On 9/21/2012 12:51 PM, Wayne Mery (d531) wrote:

On 9/11/2012 4:28 PM, Kent James wrote:

On 9/11/2012 12:41 PM, Joshua Cranmer wrote:

On 9/11/2012 1:47 PM, Mike Conley wrote:

*Action items*

 1. Get a list of people watching each TB component, and make sure
    we've got somebody with eyes on each one.
 2. We're going to tackle the Papercuts list (10 bugs) to prove that
    we can deal with a list.
 3. rkent(?) is going to send out a weekly status report on the
    Papercuts list, and what needs fixing, on what got fixed.

I was under the impression that the weekly status report on The List
was going to be managed by QA / Support. It's also not clear who will
be receiving the status report on The List.

Which "The List" do you refer too? The papercuts list?  Or the "most important bugs" list, which we discussed at mozcamp and which is different from papercuts?  (I see the two lists as coexisting)

I thought that what we agreed is that the current goal is to demonstrate that we could take a list, any list, and actually make progress in fixing bugs on it. For that purpose, "The List" that we were going to push initially is the papercuts lists. Eventually it would be good to replace that with the "most important bugs" list.

Of course at the moment we are still at business-as-usual, which means we are not really paying attention to that yet as we work on bugs that are critical for current or near-term problems (crashes and serious regressions).

:rkent

[Wayne Mery (d531)]

On 9/20/2012 8:05 AM, Ludovic Hirlimann wrote:
> On 9/11/12 8:47 PM, Mike Conley wrote:

>> *Action items*
>>
>> 1. Get a list of people watching each TB component, and make sure

>> we've got somebody with eyes on each one.
>>
> I got a list for Thunderbird and MailNewsCore, the smallest subset of
> bug followers for a component is 3 (excluding people that watch
> everything). On this list there are plenty of emails addresses that are
> not active (eg they follow the component and that's it), and I say that
> because I don't recall those email addresses making any comments. On the
> other hand some very active people don't follow *any* components and
> they do most of the work in bugzilla.

Note: silent watchers can still have/add value. We probably have core
devs for example that are interested in thunderbird, watch out for us
and comment rarely, but for time reasons aren't active in bugs.

> So the question isn't too much about following component like I
> initially though. It's more about getting traction on bugs, which means :
>

> * Getting the useful information.
> * Figuring out how bad the bug is.
> * Getting the bug in the right hands.

>
>
> For that we need less people that follow bugzilla but more people that
> are active in bugzilla and engaging the users that are reporting the
> bugs. I think the people already active in bugzilla are the people that
> can spot new active members and engage them into being even more active.

Yes, pointing new triagers to doc/information and helping them learn,
not just spoon feeding them helps in the long run. Dow

> I've done that over the years and a small email works, trying to give
> hints and task to accomplish helps even more.

Going back to your earlier point about watching components - watching
can be important. It's not the numbers of people "watching" but having
enough workers and understanding how they work. I, for example do most
of my work in two ways:
1. watching components I care about
2. whines to find "important" bugs

Strictly speaking - what we need is more people and whether we need more
people watching components depends on how people prefer to work when
they first come on board, versus how they might prefer to work (more
efficiently hopefully) as they get more active:
- do they prefer to seek out bugs, or prefer to be fed bugs?
- do they prefer bugmail, or queries?
- do they prefer tough bugs, or easy bugs?

Note: some people accomplish the same thing by watching other people in
bugzilla and not directly watching thunderbird component addresses - for
example I could be watching irving, so I get whatever bugmail irving gets

Taking a step back, I prefer to look at this as a total system, a three
(or however many) legged stool. We need process and information so we
can be organized, efficient, consistent and thorough, and we need
manpower. We can never have too much manpower and in fact we really
(really) don't have enough. This has been the blocker to creating a
useful list of bugs for developers to tackle (anyone who has spoken with
rkent on this topic knows what I mean) - we don't have time to revisit
lots old bugs, particularly the ones that are already confirmed - UNCO
ones are comparitively easy. This is also a blocker to being able to
more quickly surface critical new bugs to developer when new releases
come out - because we, the people who are watching and working, are
frankly covering too many bugs. The fact that we are doing so well
compared to a year ago may be that we are overworked :)

And finally, newer triagers bring great energy and significant manpower
to the group!

> For the new comers I've written this how-to
> https://wiki.mozilla.org/Thunderbird:Testing/bugzilla and I need your
> feedback :
>

> * is it clear ?
> * is it complete ?
> * can a new comer follow these guidelines ?

>
>
> Sherriffing bugzilla was also an idea I had. That means create a
> schedule/calendar and have people being on duties on certain days to
> answer the new bugs of the day. For this to work we'd need a lot of
> people and people that sign up doing it. Do you guys think it's a
> feasible idea ?

Sherriffing might be great for new people. It might work even better if
we have an "untriaged" component for them to watch.

> Ludo
> ps cc Thunderbird testers as they might want to participate to our
> discussions on the future of testing/quality for Thunderbird.

Note: -tester subscribers aren't able to reply to -testers. And there's
now way to set a followup mailing list.

[Wayne Mery (d531)]

On 9/21/2012 5:41 PM, Wayne Mery (d531) wrote:
> Taking a step back, I prefer to look at this as a total system, a three
> (or however many) legged stool. We need process and information so we
> can be organized, efficient, consistent and thorough, and we need
> manpower. We can never have too much manpower and in fact we really
> (really) don't have enough. This has been the blocker to creating a
> useful list of bugs for developers to tackle (anyone who has spoken with
> rkent on this topic knows what I mean) - we don't have time to revisit
> lots old bugs, particularly the ones that are already confirmed - UNCO
> ones are comparitively easy. This is also a blocker to being able to
> more quickly surface critical new bugs to developer when new releases
> come out - because we, the people who are watching and working, are
> frankly covering too many bugs. The fact that we are doing so well
> compared to a year ago may be that we are overworked :)

I wish to qualify because this is important - "we" are everyone in
bugzilla, not just "QA" (whatever that is). So "we" is developers,
users, triagers, QA, and random whomevers.

[wayne]

On 9/20/2012 8:05 AM, Ludovic Hirlimann wrote:

> On 9/11/12 8:47 PM, Mike Conley wrote:

>> *Action items*
>>
>> 1. Get a list of people watching each TB component, and make sure

>> we've got somebody with eyes on each one.
>>
> I got a list for Thunderbird and MailNewsCore, the smallest subset of
> bug followers for a component is 3 (excluding people that watch
> everything). On this list there are plenty of emails addresses that are
> not active (eg they follow the component and that's it), and I say that
> because I don't recall those email addresses making any comments. On the
> other hand some very active people don't follow *any* components and
> they do most of the work in bugzilla.

Note: silent watchers can still have/add value. We probably have core
devs for example that are interested in thunderbird, watch out for us
and comment rarely, but for time reasons aren't active in bugs.

> So the question isn't too much about following component like I
> initially though. It's more about getting traction on bugs, which means :
>

> * Getting the useful information.

> * Figuring out how bad the bug is.
> * Getting the bug in the right hands.

>
>
> For that we need less people that follow bugzilla but more people that
> are active in bugzilla and engaging the users that are reporting the
> bugs. I think the people already active in bugzilla are the people that
> can spot new active members and engage them into being even more active.

Yes, pointing new triagers to doc/information and helping them learn,
not just spoon feeding them helps in the long run. Dow

> I've done that over the years and a small email works, trying to give
> hints and task to accomplish helps even more.

Going back to your earlier point about watching components - watching
can be important. It's not the numbers of people "watching" but having
enough workers and understanding how they work. I, for example do most
of my work in two ways:
1. watching components I care about
2. whines to find "important" bugs

Strictly speaking - what we need is more people and whether we need more
people watching components depends on how people prefer to work when
they first come on board, versus how they might prefer to work (more
efficiently hopefully) as they get more active:
- do they prefer to seek out bugs, or prefer to be fed bugs?
- do they prefer bugmail, or queries?
- do they prefer tough bugs, or easy bugs?

Note: some people accomplish the same thing by watching other people in
bugzilla and not directly watching thunderbird component addresses - for
example I could be watching irving, so I get whatever bugmail irving gets

Taking a step back, I prefer to look at this as a total system, a three
(or however many) legged stool. We need process and information so we
can be organized, efficient, consistent and thorough, and we need
manpower. We can never have too much manpower and in fact we really
(really) don't have enough. This has been the blocker to creating a
useful list of bugs for developers to tackle (anyone who has spoken with
rkent on this topic knows what I mean) - we don't have time to revisit
lots old bugs, particularly the ones that are already confirmed - UNCO
ones are comparitively easy. This is also a blocker to being able to
more quickly surface critical new bugs to developer when new releases
come out - because we, the people who are watching and working, are
frankly covering too many bugs. The fact that we are doing so well
compared to a year ago may be that we are overworked :)

And finally, newer triagers bring great energy and significant manpower
to the group!

> For the new comers I've written this how-to
> https://wiki.mozilla.org/Thunderbird:Testing/bugzilla and I need your
> feedback :
>

> * is it clear ?
> * is it complete ?

> * can a new comer follow these guidelines ?

>
>
> Sherriffing bugzilla was also an idea I had. That means create a
> schedule/calendar and have people being on duties on certain days to
> answer the new bugs of the day. For this to work we'd need a lot of
> people and people that sign up doing it. Do you guys think it's a
> feasible idea ?

Sherriffing might be great for new people. It might work even better if
we have an "untriaged" component for them to watch.

> Ludo
> ps cc Thunderbird testers as they might want to participate to our
> discussions on the future of testing/quality for Thunderbird.

Note: -tester subscribers aren't able to reply to -testers. And there's
now way to set a followup mailing list.