dormant bugs and our perception

[Jon Stanley]

I was triaging old bugs in the FC6 kernel, and got this back form a
reporter.    While I agree that a lack of response can be frustrating
to a reporter, I'm not entirely sure what (if anything) we can do
about it.- I'm sending this to marketing-list since it seems to be a
problem for us rather than QA - though probably both, and I'm sure
alot of us are on both.

---------- Forwarded message ----------
From:  <bugzilla(a)redhat.com&gt;
Date: Dec 31, 2007 5:48 PM
Subject: [Bug 204883] Boot fails in insmod after upgrade from fc5
(x86) to fc6t2 (x86_64)
To: jonstanley(a)gmail.com


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Boot fails in insmod after upgrade from fc5 (x86) to fc6t2 (x86_64)


https://bugzilla.redhat.com/show_bug.cgi?id=204883


grgoffe(a)yahoo.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW
               Flag|needinfo?(grgoffe(a)yahoo.com)|




------- Additional Comments From grgoffe(a)yahoo.com  2007-12-31 18:48 EST -------
Jon,

Thanks for your input.

I've pretty much given up with my efforts to further the Fedora cause. Here are
my reasons:

1) I opened this case OVER a year ago. NO responses til now. Not exactly what I
would call a timely response I'm sure you'll agree.

2) I have joined several of the fedora lists (fedora-dev comes to mind off the
top of my head. I have posted to the list several times but have NOT received
any responses except from Rahul.

I'm NOT a developer but I HAVE a lot of experience working with systems (> 40
years) of all kinds. I will NEVER tell anyone that I know it all because I just
don't. I do expect to be listened to when I request info or make a suggestion.
EVEN if it's just to tell me to go to hell. This is not unreasonable, I do
listen AND reply to other people when they address me. I just expect the same
treatment.

Regards,

George...



--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



-- 
Jon Stanley
Fedora Ambassador
jstanley(a)fedoraproject.org

[William Cattey]

I too have been disheartened to hear nothing for months and often  
more than a year for problems I have reported.

It is impossible to give every submitted a bug detailed and rigorous  
attention.  There are just too many bugs and not enough people.

It seems to me, however, that if those in the know could manage to  
triage each incoming bug within a few days, and answer the submitter  
doing four simple things, the people submitting the bugs would feel  
more strongly motivated to stay involved and to grow into people who  
could help out in future.  What four things:

	1. Acknowledge the submission.
	2. Identify if it is an already known bug, and if so, connect the  
new bug to the known bug.
	3. If it can be done with a few minutes work, provide the submitter  
with something to do to get them moving forward on isolating and  
fixing the bug.
	4. If possible, give a sense of when to expect further help: If the  
bug is difficult to deal with, and in a low importance subsystem, say  
so.  If it is easy to fix, give the submitter help in trying to  
submit a fix.

Leaving people hanging for months and years has consequences.  For  
example:  I got bit in August by Red Hat bugzilla bug 240326.  In  
DECEMBER that bug was flagged as a duplicate of Red Hat bug 222327  
detected by Red Hat internally and opened in January.  The lack of  
timely triage meant that nobody realized this EASY bug to fix was  
actually affecting real customers.  Although this bug is Red Hat, not  
Fedora, the principle is the same.

If you at least respond, and respond quickly, you motivate people to  
do more work and join the ranks of those helping out.  If you allow a  
one-year backlog to come into existence, you look bad, you de- 
motivate potential good new people, and you cheat yourself out of  
useful information and forward progress on the code base.

Bottom line:  Every bug deserves 15 minutes of triage.  The value  
produced is measurable and significant.

-Bill

----

William Cattey
Linux Platform Coordinator
MIT Information Services & Technology

N42-040M, 617-253-0140, wdc(a)mit.edu
http://web.mit.edu/wdc/www/


On Dec 31, 2007, at 7:22 PM, Jon Stanley wrote:

>  I was triaging old bugs in the FC6 kernel, and got this back form a
>  reporter.    While I agree that a lack of response can be frustrating
>  to a reporter, I'm not entirely sure what (if anything) we can do
>  about it.- I'm sending this to marketing-list since it seems to be a
>  problem for us rather than QA - though probably both, and I'm sure
>  alot of us are on both.
>
>  ---------- Forwarded message ----------
>  From:  <bugzilla(a)redhat.com&gt;
>  Date: Dec 31, 2007 5:48 PM
>  Subject: [Bug 204883] Boot fails in insmod after upgrade from fc5
>  (x86) to fc6t2 (x86_64)
>  To: jonstanley(a)gmail.com
>
>
>  Please do not reply directly to this email. All additional
>  comments should be made in the comments box of this bug report.
>
>  Summary: Boot fails in insmod after upgrade from fc5 (x86) to fc6t2  
>  (x86_64)
>
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=204883
>
>
>  grgoffe(a)yahoo.com changed:
>
>             What    |Removed                     |Added
>  ---------------------------------------------------------------------- 
>  ------
>               Status|NEEDINFO                    |NEW
>                 Flag|needinfo?(grgoffe(a)yahoo.com)|
>
>
>
>
>  ------- Additional Comments From grgoffe(a)yahoo.com  2007-12-31  
>  18:48 EST -------
>  Jon,
>
>  Thanks for your input.
>
>  I've pretty much given up with my efforts to further the Fedora  
>  cause. Here are
>  my reasons:
>
>  1) I opened this case OVER a year ago. NO responses til now. Not  
>  exactly what I
>  would call a timely response I'm sure you'll agree.
>
>  2) I have joined several of the fedora lists (fedora-dev comes to  
>  mind off the
>  top of my head. I have posted to the list several times but have  
>  NOT received
>  any responses except from Rahul.
>
>  I'm NOT a developer but I HAVE a lot of experience working with  
>  systems (> 40
>  years) of all kinds. I will NEVER tell anyone that I know it all  
>  because I just
>  don't. I do expect to be listened to when I request info or make a  
>  suggestion.
>  EVEN if it's just to tell me to go to hell. This is not  
>  unreasonable, I do
>  listen AND reply to other people when they address me. I just  
>  expect the same
>  treatment.
>
>  Regards,
>
>  George...
>
>
>
>  --
>  Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
>  ------- You are receiving this mail because: -------
>  You are on the CC list for the bug, or are watching someone who is.
>
>
>
>  -- 
>  Jon Stanley
>  Fedora Ambassador
>  jstanley(a)fedoraproject.org
>
>  -- 
>  Fedora-marketing-list mailing list
>  Fedora-marketing-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-marketing-list

[Marc Wiriadisastra]

On Mon, 2007-12-31 at 19:41 -0500, William Cattey wrote:
>  I too have been disheartened to hear nothing for months and often  
>  more than a year for problems I have reported.
>  
>  It is impossible to give every submitted a bug detailed and rigorous  
>  attention.  There are just too many bugs and not enough people.
>  
>  It seems to me, however, that if those in the know could manage to  
>  triage each incoming bug within a few days, and answer the submitter  
>  doing four simple things, the people submitting the bugs would feel  
>  more strongly motivated to stay involved and to grow into people who  
>  could help out in future.  What four things:
>  
>  	1. Acknowledge the submission.
>  	2. Identify if it is an already known bug, and if so, connect the  
>  new bug to the known bug.
>  	3. If it can be done with a few minutes work, provide the submitter  
>  with something to do to get them moving forward on isolating and  
>  fixing the bug.
>  	4. If possible, give a sense of when to expect further help: If the  
>  bug is difficult to deal with, and in a low importance subsystem, say  
>  so.  If it is easy to fix, give the submitter help in trying to  
>  submit a fix.
>  
>  Leaving people hanging for months and years has consequences.  For  
>  example:  I got bit in August by Red Hat bugzilla bug 240326.  In  
>  DECEMBER that bug was flagged as a duplicate of Red Hat bug 222327  
>  detected by Red Hat internally and opened in January.  The lack of  
>  timely triage meant that nobody realized this EASY bug to fix was  
>  actually affecting real customers.  Although this bug is Red Hat, not  
>  Fedora, the principle is the same.
>  
>  If you at least respond, and respond quickly, you motivate people to  
>  do more work and join the ranks of those helping out.  If you allow a  
>  one-year backlog to come into existence, you look bad, you de- 
>  motivate potential good new people, and you cheat yourself out of  
>  useful information and forward progress on the code base.
>  
>  Bottom line:  Every bug deserves 15 minutes of triage.  The value  
>  produced is measurable and significant.
>  
>  -Bill
>  
>  ----
>  
>  William Cattey
>  Linux Platform Coordinator
>  MIT Information Services & Technology
>  
>  N42-040M, 617-253-0140, wdc(a)mit.edu
>  http://web.mit.edu/wdc/www/
>  
>  
>  On Dec 31, 2007, at 7:22 PM, Jon Stanley wrote:
>  
>  > I was triaging old bugs in the FC6 kernel, and got this back form a
>  > reporter.    While I agree that a lack of response can be frustrating
>  > to a reporter, I'm not entirely sure what (if anything) we can do
>  > about it.- I'm sending this to marketing-list since it seems to be a
>  > problem for us rather than QA - though probably both, and I'm sure
>  > alot of us are on both.
>  >
>  > ---------- Forwarded message ----------
>  > From:  <bugzilla(a)redhat.com&gt;
>  > Date: Dec 31, 2007 5:48 PM
>  > Subject: [Bug 204883] Boot fails in insmod after upgrade from fc5
>  > (x86) to fc6t2 (x86_64)
>  > To: jonstanley(a)gmail.com
>  >
>  >
>  > Please do not reply directly to this email. All additional
>  > comments should be made in the comments box of this bug report.
>  >
>  > Summary: Boot fails in insmod after upgrade from fc5 (x86) to fc6t2  
>  > (x86_64)
>  >
>  >
>  > https://bugzilla.redhat.com/show_bug.cgi?id=204883
>  >
>  >
>  > grgoffe(a)yahoo.com changed:
>  >
>  >            What    |Removed                     |Added
>  > ---------------------------------------------------------------------- 
>  > ------
>  >              Status|NEEDINFO                    |NEW
>  >                Flag|needinfo?(grgoffe(a)yahoo.com)|
>  >
>  >
>  >
>  >
>  > ------- Additional Comments From grgoffe(a)yahoo.com  2007-12-31  
>  > 18:48 EST -------
>  > Jon,
>  >
>  > Thanks for your input.
>  >
>  > I've pretty much given up with my efforts to further the Fedora  
>  > cause. Here are
>  > my reasons:
>  >
>  > 1) I opened this case OVER a year ago. NO responses til now. Not  
>  > exactly what I
>  > would call a timely response I'm sure you'll agree.
>  >
>  > 2) I have joined several of the fedora lists (fedora-dev comes to  
>  > mind off the
>  > top of my head. I have posted to the list several times but have  
>  > NOT received
>  > any responses except from Rahul.
>  >
>  > I'm NOT a developer but I HAVE a lot of experience working with  
>  > systems (> 40
>  > years) of all kinds. I will NEVER tell anyone that I know it all  
>  > because I just
>  > don't. I do expect to be listened to when I request info or make a  
>  > suggestion.
>  > EVEN if it's just to tell me to go to hell. This is not  
>  > unreasonable, I do
>  > listen AND reply to other people when they address me. I just  
>  > expect the same
>  > treatment.
>  >
>  > Regards,
>  >
>  > George...
>  >
>  >
>  >
>  > - 
Yep I've seen that a lot.  Dev's are busy and generally can't respond
I'm not to sure if this does not occur in other projects but I know when
I post a bug to wine I get a response in close to 24-48 hours even if it
is just an acknowledgment of the bug.

Me personally I've always had bugs responded to so I haven't personally
experienced the problem.  

I do know of one situation but that was relating to development of the
bash in F9 where we/fedoraforum posted a bug report to help BASH for the
init process and we haven't heard back as of yet and that was a few
months ago.  While thats not really an issue most of the users in that
were very eager to help bug test yet there hasn't been feedback.

Cheers,


Marc

[Jesse Keating]

On Mon, 31 Dec 2007 19:41:47 -0500
William Cattey <wdc(a)MIT.EDU&gt; wrote:

>  It seems to me, however, that if those in the know could manage to  
>  triage each incoming bug within a few days, and answer the submitter  
>  doing four simple things, the people submitting the bugs would feel  
>  more strongly motivated to stay involved and to grow into people who  
>  could help out in future.  What four things: 
We have people trying to organize bug days and triage events.

-- 
Jesse Keating RHCE      (jkeating.livejournal.com)
Fedora Project          (fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)

[Rahul Sundaram]

William Cattey wrote:
>  
>  Bottom line:  Every bug deserves 15 minutes of triage.  The value 
>  produced is measurable and significant. 
I am pretty sure everybody will agree with that. However we don't really 
have many triagers and any help on this would be most welcome.

Rahul

[Michael Stahnke]

On Jan 1, 2008 7:33 AM, Rahul Sundaram <sundaram(a)fedoraproject.org&gt; wrote:
>  William Cattey wrote:
>  >
>  > Bottom line:  Every bug deserves 15 minutes of triage.  The value
>  > produced is measurable and significant.
>
>  I am pretty sure everybody will agree with that. However we don't really
>  have many triagers and any help on this would be most welcome.
>
>  Rahul
>
>
>  --
>  Fedora-marketing-list mailing list
>  Fedora-marketing-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-marketing-list
>  
To me, a lot of the reason there are not more people tracking down
bugs like this is that any/most packages that were part of core, can't
be fixed by community members.  Some of the bugs are 5 minute fixes
that anyone could do.  Rather than just fix them, we have to fill out
more items about each bug and pray someone from Red Hat deems it
worthy enough to fix.  I have had several bugs opened and then years
later closed when FCx or RHELx was no longer supported and told to
refile them if they still exist.

That leaves a bad taste in my mouth and is really against most of the
the open source models I am aware of.  If I can fix it, or at least
provide a patch to fix it, why should it take year(s) for evaluation?

I normally find that bugs on former extras packages were taken care of
much faster.  Most often now, I will just create my own
package/patches and apply on my systems rather than try to file bug
against any core package.  It gets results.  For example the last bug
I filed (that I recall anyway)
https://bugzilla.redhat.com/show_bug.cgi?id=236697 was put in April.
I haven't heard one single thing back on it.  This is proof to me that
either the team maintaining core packages is too small, or there are
lots of people at RH who don't care about bug reports.

stahnma

[Rahul Sundaram]

Michael Stahnke wrote:
>  To me, a lot of the reason there are not more people tracking down
>  bugs like this is that any/most packages that were part of core, can't
>  be fixed by community members.   
Triaging bugs usually doesn't require any commit access. I have triaged 
hundreds of bugs before and most of them was about asking for more 
information, reassigning bugs so that it reaches the proper maintainers, 
closing duplicates or already fixed bugs and so on but it is possible 
that ACL's are a hindrance and I have been always supportive of removing 
them to the maximum extend possible.

You might be interested in 
http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening.

  This is proof to me that
>  either the team maintaining core packages is too small, or there are
>  lots of people at RH who don't care about bug reports. 
It is mostly a problem of resources and there are few ways you can 
tackle this currently including direct mails, requesting 
co-maintainership of the package in question or initiating the AWOL/MIA 
process.

Rahul

[inode0]

On Jan 1, 2008 7:33 AM, Rahul Sundaram <sundaram(a)fedoraproject.org&gt; wrote:
>  William Cattey wrote:
>  >
>  > Bottom line:  Every bug deserves 15 minutes of triage.  The value
>  > produced is measurable and significant.
>
>  I am pretty sure everybody will agree with that. However we don't really
>  have many triagers and any help on this would be most welcome. 
What is the magnitude of the problem? While I understand one more
triager would be welcome would one more triager make any difference?
Would 10 more make a difference? How many would it take to make a real
difference?

John

[Rahul Sundaram]

inode0 wrote:
>  On Jan 1, 2008 7:33 AM, Rahul Sundaram  wrote:
> > William Cattey wrote:
> >> Bottom line:  Every bug deserves 15 minutes of triage.  The value
> >> produced is measurable and significant.
> > I am pretty sure everybody will agree with that. However we don't really
> > have many triagers and any help on this would be most welcome.
>  
>  What is the magnitude of the problem?  
It is a pretty huge problem. To understand it a bit more, some stats.

There is a total of 13557 bugs (excluding documentation, directory 
server and Fedora EPEL repository)

Against Fedora 7, 8 and rawhide alone, 9708 bugs are open. Quite a 
number of them are package review requests rather than bugs but still 
the number of open bugs that are likely still valid at any given point 
has been hovering around 8000. We have around 5000+ source packages 
(only source packages are listed in bugzilla) and majority of them are 
filed against a few key packages.

While I understand one more
>  triager would be welcome would one more triager make any difference?
Certainly but you probably need to target specific things. The large 
majority of bugs are usually filed against core components like the 
kernel, xorg or default applications like Openoffice.org, Firefox, 
Evolution etc. Typical 80/20 rule.

A new triager could focus on say Xorg bug reports and make a pretty big 
difference and you don't need any programming skills to do it. If you 
can coordinate this with the relevant package maintainers, that would be 
even better. Christopher Brown has been doing it for the kernel with 
pretty good results.

https://www.redhat.com/archives/fedora-kernel-list/2007-December/msg00029...

Red Hat desktop team has a dedicated bug triager, Matej Cepl and you 
might want to contact him before you touch on any of the desktop 
components.

>  Would 10 more make a difference? How many would it take to make a
> real
>  difference? 
I am just making a guess here but a group of about 3 or 4 people working 
together as a team on organizing bug days etc can certainly make a 
immediate difference to the entire bug list. If you are interested, refer

http://fedoraproject.org/wiki/BugZappers

Join #fedora-qa and ping me  (nick:mether) or Will Woods (nick:wwods) 
and we can help you get you started. Otherwise just ask in the channel.

Rahul

[Greg DeKoenigsberg]

On Mon, 31 Dec 2007, Jon Stanley wrote:

>  I was triaging old bugs in the FC6 kernel, and got this back form a
>  reporter.    While I agree that a lack of response can be frustrating
>  to a reporter, I'm not entirely sure what (if anything) we can do
>  about it.- I'm sending this to marketing-list since it seems to be a
>  problem for us rather than QA - though probably both, and I'm sure
>  alot of us are on both. 
Handling this exact kind of problem is why bug triagers are worth their 
weight in gold.

Because here's the thing: people don't expect all of their bugs to be 
magically fixed.  (Well, some do, but it doesn't make good business sense 
or good community sense to cater to unreasonable people.)

What they *do* expect is for someone to say, "gee, thanks for posting this 
bug, we'll set the priority accordingly and maybe poke a developer."  And 
we fail pretty miserably at that.

Cross-posting to the Fedora advisory board list.  Our inability to create 
and nurture a bug triage community continues to be painful, and our 
current QA resources within Red Hat continue to be (necessarily) 
technically focused rather than community focused.  This is a problem we 
need to solve.

--g

-- 
Greg DeKoenigsberg
Community Development Manager
Red Hat, Inc. :: 1-919-754-4255
"To whomsoever much hath been given...
...from him much shall be asked"

[inode0]

On Jan 2, 2008 9:23 AM, Greg DeKoenigsberg <gdk(a)redhat.com&gt; wrote:
>  On Mon, 31 Dec 2007, Jon Stanley wrote:
>
>  > I was triaging old bugs in the FC6 kernel, and got this back form a
>  > reporter.    While I agree that a lack of response can be frustrating
>  > to a reporter, I'm not entirely sure what (if anything) we can do
>  > about it.- I'm sending this to marketing-list since it seems to be a
>  > problem for us rather than QA - though probably both, and I'm sure
>  > alot of us are on both.
>
>  Handling this exact kind of problem is why bug triagers are worth their
>  weight in gold.
>
>  Because here's the thing: people don't expect all of their bugs to be
>  magically fixed.  (Well, some do, but it doesn't make good business sense
>  or good community sense to cater to unreasonable people.)
>
>  What they *do* expect is for someone to say, "gee, thanks for posting this
>  bug, we'll set the priority accordingly and maybe poke a developer."  And
>  we fail pretty miserably at that.
>
>  Cross-posting to the Fedora advisory board list.  Our inability to create
>  and nurture a bug triage community continues to be painful, and our
>  current QA resources within Red Hat continue to be (necessarily)
>  technically focused rather than community focused.  This is a problem we
>  need to solve. 
I know ideas are a dime a dozen but here is one idea anyway ...

We've been discussing how universities can take a more active role in
helping students find suitable open source projects to participate in
and ways they can find a fit between their skills and the needs of
open source projects elsewhere.

I think it would be immensely helpful to those of us at universities
who don't have a lot of direct access to students to have one
marketing tool available to us ... an eye-catching poster that we
could scatter around campus ... perhaps containing a short list of
fedora needs that don't require a lot of technical skill and an empty
spot where we might add some mentor contact information for anyone
interested.

John

[Michael Stahnke]

On Jan 2, 2008 10:00 AM, inode0 <inode0(a)gmail.com&gt; wrote:
>  On Jan 2, 2008 9:23 AM, Greg DeKoenigsberg <gdk(a)redhat.com&gt;
> wrote:
>  > On Mon, 31 Dec 2007, Jon Stanley wrote:
>  >
>  > > I was triaging old bugs in the FC6 kernel, and got this back form a
>  > > reporter.    While I agree that a lack of response can be frustrating
>  > > to a reporter, I'm not entirely sure what (if anything) we can do
>  > > about it.- I'm sending this to marketing-list since it seems to be a
>  > > problem for us rather than QA - though probably both, and I'm sure
>  > > alot of us are on both.
>  >
>  > Handling this exact kind of problem is why bug triagers are worth their
>  > weight in gold.
>  >
>  > Because here's the thing: people don't expect all of their bugs to be
>  > magically fixed.  (Well, some do, but it doesn't make good business sense
>  > or good community sense to cater to unreasonable people.)
>  >
>  > What they *do* expect is for someone to say, "gee, thanks for posting this
>  > bug, we'll set the priority accordingly and maybe poke a developer."  And
>  > we fail pretty miserably at that.
>  >
>  > Cross-posting to the Fedora advisory board list.  Our inability to create
>  > and nurture a bug triage community continues to be painful, and our
>  > current QA resources within Red Hat continue to be (necessarily)
>  > technically focused rather than community focused.  This is a problem we
>  > need to solve.
>
>  I know ideas are a dime a dozen but here is one idea anyway ...
>
>  We've been discussing how universities can take a more active role in
>  helping students find suitable open source projects to participate in
>  and ways they can find a fit between their skills and the needs of
>  open source projects elsewhere.
>
>  I think it would be immensely helpful to those of us at universities
>  who don't have a lot of direct access to students to have one
>  marketing tool available to us ... an eye-catching poster that we
>  could scatter around campus ... perhaps containing a short list of
>  fedora needs that don't require a lot of technical skill and an empty
>  spot where we might add some mentor contact information for anyone
>  interested.
>  
I couldn't agree more.  This is a great spot for anyone to step into
the community and make a difference.
>  John
>
>
>  --
>  Fedora-marketing-list mailing list
>  Fedora-marketing-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-marketing-list
>

[William Cattey]

John,

Great question earlier in the thread to ascertain scope.  3-4 FTEs to  
address a constant 8000 bug backlog seems eminently addressable.

I agree that involving universities in the bug fixing is an excellent  
approach.
In fact, I'd say that if you had the mentor available, you wouldn't  
need posters.
There are students calling in with problems and solutions all the time.

I think the key is to get those 3-4 FTEs in at the triage level so  
that instead of turning away our seed corn, it begins to grow!

-Bill

----

William Cattey
Linux Platform Coordinator
MIT Information Services & Technology

N42-040M, 617-253-0140, wdc(a)mit.edu
http://web.mit.edu/wdc/www/


On Jan 2, 2008, at 11:00 AM, inode0 wrote:

>  On Jan 2, 2008 9:23 AM, Greg DeKoenigsberg <gdk(a)redhat.com&gt;
> wrote:
> > On Mon, 31 Dec 2007, Jon Stanley wrote:
> >
> >> I was triaging old bugs in the FC6 kernel, and got this back form a
> >> reporter.    While I agree that a lack of response can be  
> >> frustrating
> >> to a reporter, I'm not entirely sure what (if anything) we can do
> >> about it.- I'm sending this to marketing-list since it seems to be a
> >> problem for us rather than QA - though probably both, and I'm sure
> >> alot of us are on both.
> >
> > Handling this exact kind of problem is why bug triagers are worth  
> > their
> > weight in gold.
> >
> > Because here's the thing: people don't expect all of their bugs to be
> > magically fixed.  (Well, some do, but it doesn't make good  
> > business sense
> > or good community sense to cater to unreasonable people.)
> >
> > What they *do* expect is for someone to say, "gee, thanks for  
> > posting this
> > bug, we'll set the priority accordingly and maybe poke a  
> > developer."  And
> > we fail pretty miserably at that.
> >
> > Cross-posting to the Fedora advisory board list.  Our inability to  
> > create
> > and nurture a bug triage community continues to be painful, and our
> > current QA resources within Red Hat continue to be (necessarily)
> > technically focused rather than community focused.  This is a  
> > problem we
> > need to solve.
>
>  I know ideas are a dime a dozen but here is one idea anyway ...
>
>  We've been discussing how universities can take a more active role in
>  helping students find suitable open source projects to participate in
>  and ways they can find a fit between their skills and the needs of
>  open source projects elsewhere.
>
>  I think it would be immensely helpful to those of us at universities
>  who don't have a lot of direct access to students to have one
>  marketing tool available to us ... an eye-catching poster that we
>  could scatter around campus ... perhaps containing a short list of
>  fedora needs that don't require a lot of technical skill and an empty
>  spot where we might add some mentor contact information for anyone
>  interested.
>
>  John
>
>  -- 
>  Fedora-marketing-list mailing list
>  Fedora-marketing-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-marketing-list

[Chuck Anderson]

On Wed, Jan 02, 2008 at 10:23:03AM -0500, Greg DeKoenigsberg wrote:
>  Cross-posting to the Fedora advisory board list.  Our inability to
> create 
>  and nurture a bug triage community continues to be painful, and our current 
>  QA resources within Red Hat continue to be (necessarily) technically 
>  focused rather than community focused.  This is a problem we need to solve. 
I think my IRC conversation during a recent Bug Day sums up the 
problems pretty well:

Nov 19 13:39:04 <cra>   how do I officially become part of the QA and bug triage
team?
Nov 19 13:43:01 <cra>   i'd like to get the Release Notes updated to 
mention that Xinerama doesn't work and how to use xrandr to set up dual-head
Nov 19 13:45:24 <f13>   cra: I think you "show up" and you're part of
the team.
Nov 19 13:46:01 <cra>   f13: but in the past i've tried to update bugs, and I
don't have
permission to do things like mark-duplicate, change product/release, etc.
Nov 19 13:46:26 <f13>   cra: you need to be in the fedora-bugs group I think, which
all
contributors were supposed to be added to I thought.
Nov 19 13:57:05 <poelcat>       cra: hopefully nothing official for either, but 
if there are blockers to getting involved let me know... chances are I have some
 extra bugzilla privs I don't know about that should be sorted out for everyone 
else

There seems to be no official process to become a QA contributor or 
Bug Triager.  Formalizing this process and documenting it would go a 
long way to improving things.

Some things I think would be helpful:

1. Allow QA contributors to subscribe to certain products/components 
so they are CC'd on any new bugs in those areas.

2. Allow QA contributors to have the access rights on Bugzilla 
necessary to manage bugs, mark duplicates, etc.

[Jon Stanley]

On Jan 2, 2008 3:24 PM, Chuck Anderson <cra(a)wpi.edu&gt; wrote:

>  1. Allow QA contributors to subscribe to certain products/components
>  so they are CC'd on any new bugs in those areas. 
I suppose you could do this using the 'watch' feature of bugzilla to
watch the maintainer (though that may be more than you want).

>  2. Allow QA contributors to have the access rights on Bugzilla
>  necessary to manage bugs, mark duplicates, etc. 
I'm in the fedorabugs group, didn't have access.  Triaged a few via
comments, and was given 'editbugs' and a few other things.  Pretty
much show up and work and you're in.  I 100% agree that formalizing
the process is required.

[Jef Spaleta]

On Jan 2, 2008 12:24 PM, Chuck Anderson <cra(a)wpi.edu&gt; wrote:
>  There seems to be no official process to become a QA contributor or
>  Bug Triager.  Formalizing this process and documenting it would go a
>  long way to improving things. 
Here again, have a strong leader to drive the process would help immensely.
I can't drive it, history has proven that. But I'd like to help. I'd
love it if we'd be able to set aside a week every release, and just
focus on driving people into the bugsquad and training them to do a
good job at it. And we as a community make a commitment to do that
every release to refill the ranks because getting people doing that
job has high impact across the whole project. I expect a high turn
over rate in triaging, because its not glorious. But its also a great
entry-level way to contribute. I'd really like to see an organized
push to place people interested in helping into the team with a Fedora
community wide guidance at the beginning of their 6 month tour of
duty. And then at the end of the tour, we integrate our experienced
triagers into other areas of the project.  But without someone to take
the lead, I don't have a person whom I can directly support and
bolster with by expert cheerleading abilities.

-jef"now where did i put my megaphone?"spaleta

[Rahul Sundaram]

Chuck Anderson wrote:
>  
>  There seems to be no official process to become a QA contributor or 
>  Bug Triager.  Formalizing this process and documenting it would go a 
>  long way to improving things. 
There is a process outlined in

http://fedoraproject.org/wiki/QA#head-5234f50982dab35b93f474f5ba001b970c1...

Is there something more you wanted?

Rahul