| Summary of TB QA Meeting at Mozcamp |
Mike Conley |
11/09/12 11:47 |
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?
- 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
- Get a list of
people watching each TB component, and make sure we've got
somebody with eyes on each one.
- We're going to
tackle the Papercuts list (10 bugs) to prove that we can deal
with a list.
- rkent(?) is going
to send out a weekly status report on the Papercuts list, and
what needs fixing, on what got fixed.
- 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).
- We need to come up
with some critiera for choosing bugs like the ones on
Papercuts. Then QA / Support will build the list.
|
| Re: Summary of TB QA Meeting at Mozcamp |
Joshua Cranmer |
11/09/12 12:41 |
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
- Get a list of
people watching each TB component, and make sure we've got
somebody with eyes on each one.
- We're going to
tackle the Papercuts list (10 bugs) to prove that we can
deal with a list.
- 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.
- 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).
- 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
|
| Re: Summary of TB QA Meeting at Mozcamp |
Kent James |
11/09/12 13:28 |
On 9/11/2012 12:41 PM, Joshua Cranmer wrote:
On 9/11/2012 1:47 PM, Mike Conley
wrote:
Action items
- Get a list of
people watching each TB component, and make sure we've got
somebody with eyes on each one.
- We're going to
tackle the Papercuts list (10 bugs) to prove that we can
deal with a list.
- 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
|
| Re: Summary of TB QA Meeting at Mozcamp |
Gervase Markham |
12/09/12 08:07 |
|
| Re: Summary of TB QA Meeting at Mozcamp |
acel...@atlas.sk |
12/09/12 08:15 |
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 |
| Re: Summary of TB QA Meeting at Mozcamp |
Gervase Markham |
12/09/12 08:20 |
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.
|
| Re: Summary of TB QA Meeting at Mozcamp |
acel...@atlas.sk |
12/09/12 08:26 |
|
| Re: Summary of TB QA Meeting at Mozcamp |
Ludovic Hirlimann |
12/09/12 12:05 |
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
|
| Re: Summary of TB QA Meeting at Mozcamp |
Wayne Mery (d531) |
16/09/12 07:28 |
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?
|
| Re: Summary of TB QA Meeting at Mozcamp |
Joshua Cranmer |
16/09/12 13:20 |
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
|
| Re: Summary of TB QA Meeting at Mozcamp |
Mark Banner |
18/09/12 06:53 |
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.
|
| Re: Summary of TB QA Meeting at Mozcamp |
Mark Banner |
18/09/12 07:00 |
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.
|
| Re: Summary of TB QA Meeting at Mozcamp |
Mark Banner |
18/09/12 07:48 |
|
| Re: Summary of TB QA Meeting at Mozcamp |
Ludovic Hirlimann |
20/09/12 05:05 |
On 9/11/12 8:47 PM, Mike Conley wrote:
Action items
- 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/
|
| Re: Summary of TB QA Meeting at Mozcamp |
Wayne Mery (d531) |
21/09/12 12:51 |
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.
|
| Re: Summary of TB QA Meeting at Mozcamp |
Kent James |
21/09/12 13:57 |
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
|
| Re: Summary of TB QA Meeting at Mozcamp |
Wayne Mery (d531) |
21/09/12 14:41 |
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.
|
| Re: Summary of TB QA Meeting at Mozcamp |
Wayne Mery (d531) |
21/09/12 14:54 |
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.
|
| Re: Summary of TB QA Meeting at Mozcamp |
wayne |
21/09/12 14:09 |
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.
|