Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

2014-11-21 Thread Joe Gordon
On Tue, Nov 18, 2014 at 11:48 PM, Flavio Percoco fla...@redhat.com wrote:

 On 18/11/14 14:45 -0800, Joe Gordon wrote:



 On Tue, Nov 18, 2014 at 10:58 AM, Clint Byrum cl...@fewbar.com wrote:

Excerpts from Flavio Percoco's message of 2014-11-17 08:46:19 -0800:
 Greetings,

 Regardless of how big/small bugs backlog is for each project, I
 believe this is a common, annoying and difficult problem. At the oslo
 meeting today, we're talking about how to address our bug triage
 process and I proposed something that I've seen done in other
 communities (rust-language [0]) that I consider useful and a good
 option for OpenStack too.

 The process consist in a bot that sends an email to every *volunteer*
 with 10 bugs to review/triage for the week. Each volunteer follows
 the
 triage standards, applies tags and provides information on whether
 the
 bug is still valid or not. The volunteer doesn't have to fix the bug,
 just triage it.

 In openstack, we could have a job that does this and then have people
 from each team volunteer to help with triage. The benefits I see are:

 * Interested folks don't have to go through the list and filter the
 bugs they want to triage. The bot should be smart enough to pick the
 oldest, most critical, etc.

 * It's a totally opt-in process and volunteers can obviously ignore
 emails if they don't have time that week.

 * It helps scaling out the triage process without poking people
 around
 and without having to do a call for volunteers every
 meeting/cycle/etc

 The above doesn't solve the problme completely but just like reviews,
 it'd be an optional, completely opt-in process that people can sign
 up
 for.


My experience in Ubuntu, where we encouraged non-developers to triage
bugs, was that non-developers often ask the wrong questions and
sometimes even harm the process by putting something in the wrong
priority or state because of a lack of deep understanding.

Triage in a hospital is done by experienced nurses and doctors working
together, not triagers. This is because it may not always be obvious
to somebody just how important a problem is. We have the same set of
problems. The most important thing is that developers see it as an
important task and take part. New volunteers should be getting involved
at every level, not just bug triage.


 ++, nice analogy.

 Another problem I have seen, is we need to constantly re-triage bugs, as
 just
 because a bug was marked as confirmed 6 months ago doesn't mean it is
 still
 valid.


 Ideally, the script will take care of this. Bugs that haven't been
 update for more than N months will fall into the to-triage pool for
 re-triage.


I am willing to sign up and give this a try.



 Flavio





I think the best approach to this, like reviews, is to have a place
where users can go to drive the triage workload to 0. For instance, the
ubuntu server team had this report for triage:

http://reqorts.qa.ubuntu.com/reports/ubuntu-server/triage-report.html

Sadly, it looks like they're overwhelmed or have abandoned the effort
(I hope this doesn't say something about Ubuntu server itself..), but
the basic process was to move bugs off these lists. I'm sure if we ask
nice the author of that code will share it with us and we could adapt
it for OpenStack projects.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



  ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 --
 @flaper87
 Flavio Percoco

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

2014-11-18 Thread Thierry Carrez
Dolph Mathews wrote:
 As someone who has spent quite a bit of time triaging bugs, I'd be
 hugely in favor of this. I'd probably be willing to pitch in on
 additional projects, as well.
 
 Is there already tooling for this built around Launchpad, or do we have
 to roll our own?

You'll have to roll your own, but it shouldn't be very difficult. You
can see [1] for a base example of listing bugs in Launchpad:

[1]
http://git.openstack.org/cgit/openstack-infra/release-tools/tree/process_bugs.py

 With storyboard.openstack.org http://storyboard.openstack.org looming
 on the horizon, should such an effort be put on the back burner for now?

I don't expect integrated projects to be able to switch to storyboard
for bug tracking just yet. Our current goal is to have it ready for
infrastructure dogfooding now (actually, yesterday), ready for feature
tracking (and bugs tracking replacement for willing non-integrated
guinea pigs) in 6 months, and ready for everyone in 12 months.

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

2014-11-18 Thread Kashyap Chamarthy
On Tue, Nov 18, 2014 at 11:42:19AM +0100, Thierry Carrez wrote:
 Dolph Mathews wrote:
  As someone who has spent quite a bit of time triaging bugs, I'd be
  hugely in favor of this. I'd probably be willing to pitch in on
  additional projects, as well.
  
  Is there already tooling for this built around Launchpad, or do we have
  to roll our own?

FWIW, I find the CLI querying in Launchpad a bit lacking compared to
Bugzilla.
A while ago, Thierry pointed me to 'lp-tools'[1] which has a bunch of
CLI scripts to interface with Launchpad

I use it sometimes to check new Nova bugs:

$ python new-nova-lp-bugs.py | tee new-nova-lp-bugs-18NOV2014.txt

Couple of other resources I try to use[2][3] when I triage bugs:

[1] https://launchpad.net/lptools
[2] Notes from Sean Dague from Nova bug triaging --

http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html
[3] https://wiki.openstack.org/wiki/BugFilingRecommendations

 You'll have to roll your own, but it shouldn't be very difficult. You
 can see [1] for a base example of listing bugs in Launchpad:
 
 [1]
 http://git.openstack.org/cgit/openstack-infra/release-tools/tree/process_bugs.py
 
  With storyboard.openstack.org http://storyboard.openstack.org looming
  on the horizon, should such an effort be put on the back burner for now?
 
 I don't expect integrated projects to be able to switch to storyboard
 for bug tracking just yet. Our current goal is to have it ready for
 infrastructure dogfooding now (actually, yesterday), ready for feature
 tracking (and bugs tracking replacement for willing non-integrated
 guinea pigs) in 6 months, and ready for everyone in 12 months.
 
 -- 
 Thierry Carrez (ttx)
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
/kashyap

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

2014-11-18 Thread Flavio Percoco

On 18/11/14 11:42 +0100, Thierry Carrez wrote:

Dolph Mathews wrote:

As someone who has spent quite a bit of time triaging bugs, I'd be
hugely in favor of this. I'd probably be willing to pitch in on
additional projects, as well.

Is there already tooling for this built around Launchpad, or do we have
to roll our own?


You'll have to roll your own, but it shouldn't be very difficult. You
can see [1] for a base example of listing bugs in Launchpad:

[1]
http://git.openstack.org/cgit/openstack-infra/release-tools/tree/process_bugs.py


If Infra agrees that we can have a bot that runs a script weekly, I'm
happy to help with the script itself.




With storyboard.openstack.org http://storyboard.openstack.org looming
on the horizon, should such an effort be put on the back burner for now?


I don't expect integrated projects to be able to switch to storyboard
for bug tracking just yet. Our current goal is to have it ready for
infrastructure dogfooding now (actually, yesterday), ready for feature
tracking (and bugs tracking replacement for willing non-integrated
guinea pigs) in 6 months, and ready for everyone in 12 months.


Is it in a good enough state that would a low smaller projects - zaqar
- to jump in and help testing the storyboard? I'm happy to give it a
try.

Cheers,
Flavio

--
@flaper87
Flavio Percoco


pgpIegOxUfxSz.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

2014-11-18 Thread Thierry Carrez
Flavio Percoco wrote:
 On 18/11/14 11:42 +0100, Thierry Carrez wrote:
 With storyboard.openstack.org http://storyboard.openstack.org looming
 on the horizon, should such an effort be put on the back burner for now?

 I don't expect integrated projects to be able to switch to storyboard
 for bug tracking just yet. Our current goal is to have it ready for
 infrastructure dogfooding now (actually, yesterday), ready for feature
 tracking (and bugs tracking replacement for willing non-integrated
 guinea pigs) in 6 months, and ready for everyone in 12 months.
 
 Is it in a good enough state that would a low smaller projects - zaqar
 - to jump in and help testing the storyboard? I'm happy to give it a
 try.

The trick is that it's missing some features that would make it a pain,
even for an incubated project (think: no private security bugs). Also
we'd like to switch all integrated projects at the same time, so that
release management doesn't have to play with two tools in parallel.

Also, nothing in storyboard actually makes triaging less painful :)

-- 
Thierry Carrez (ttx)



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

2014-11-18 Thread Clint Byrum
Excerpts from Flavio Percoco's message of 2014-11-17 08:46:19 -0800:
 Greetings,
 
 Regardless of how big/small bugs backlog is for each project, I
 believe this is a common, annoying and difficult problem. At the oslo
 meeting today, we're talking about how to address our bug triage
 process and I proposed something that I've seen done in other
 communities (rust-language [0]) that I consider useful and a good
 option for OpenStack too.
 
 The process consist in a bot that sends an email to every *volunteer*
 with 10 bugs to review/triage for the week. Each volunteer follows the
 triage standards, applies tags and provides information on whether the
 bug is still valid or not. The volunteer doesn't have to fix the bug,
 just triage it.
 
 In openstack, we could have a job that does this and then have people
 from each team volunteer to help with triage. The benefits I see are:
 
 * Interested folks don't have to go through the list and filter the
 bugs they want to triage. The bot should be smart enough to pick the
 oldest, most critical, etc.
 
 * It's a totally opt-in process and volunteers can obviously ignore
 emails if they don't have time that week.
 
 * It helps scaling out the triage process without poking people around
 and without having to do a call for volunteers every meeting/cycle/etc
 
 The above doesn't solve the problme completely but just like reviews,
 it'd be an optional, completely opt-in process that people can sign up
 for.
 

My experience in Ubuntu, where we encouraged non-developers to triage
bugs, was that non-developers often ask the wrong questions and
sometimes even harm the process by putting something in the wrong
priority or state because of a lack of deep understanding.

Triage in a hospital is done by experienced nurses and doctors working
together, not triagers. This is because it may not always be obvious
to somebody just how important a problem is. We have the same set of
problems. The most important thing is that developers see it as an
important task and take part. New volunteers should be getting involved
at every level, not just bug triage.

I think the best approach to this, like reviews, is to have a place
where users can go to drive the triage workload to 0. For instance, the
ubuntu server team had this report for triage:

http://reqorts.qa.ubuntu.com/reports/ubuntu-server/triage-report.html

Sadly, it looks like they're overwhelmed or have abandoned the effort
(I hope this doesn't say something about Ubuntu server itself..), but
the basic process was to move bugs off these lists. I'm sure if we ask
nice the author of that code will share it with us and we could adapt
it for OpenStack projects.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

2014-11-18 Thread Joe Gordon
On Tue, Nov 18, 2014 at 10:58 AM, Clint Byrum cl...@fewbar.com wrote:

 Excerpts from Flavio Percoco's message of 2014-11-17 08:46:19 -0800:
  Greetings,
 
  Regardless of how big/small bugs backlog is for each project, I
  believe this is a common, annoying and difficult problem. At the oslo
  meeting today, we're talking about how to address our bug triage
  process and I proposed something that I've seen done in other
  communities (rust-language [0]) that I consider useful and a good
  option for OpenStack too.
 
  The process consist in a bot that sends an email to every *volunteer*
  with 10 bugs to review/triage for the week. Each volunteer follows the
  triage standards, applies tags and provides information on whether the
  bug is still valid or not. The volunteer doesn't have to fix the bug,
  just triage it.
 
  In openstack, we could have a job that does this and then have people
  from each team volunteer to help with triage. The benefits I see are:
 
  * Interested folks don't have to go through the list and filter the
  bugs they want to triage. The bot should be smart enough to pick the
  oldest, most critical, etc.
 
  * It's a totally opt-in process and volunteers can obviously ignore
  emails if they don't have time that week.
 
  * It helps scaling out the triage process without poking people around
  and without having to do a call for volunteers every meeting/cycle/etc
 
  The above doesn't solve the problme completely but just like reviews,
  it'd be an optional, completely opt-in process that people can sign up
  for.
 

 My experience in Ubuntu, where we encouraged non-developers to triage
 bugs, was that non-developers often ask the wrong questions and
 sometimes even harm the process by putting something in the wrong
 priority or state because of a lack of deep understanding.

 Triage in a hospital is done by experienced nurses and doctors working
 together, not triagers. This is because it may not always be obvious
 to somebody just how important a problem is. We have the same set of
 problems. The most important thing is that developers see it as an
 important task and take part. New volunteers should be getting involved
 at every level, not just bug triage.


++, nice analogy.

Another problem I have seen, is we need to constantly re-triage bugs, as
just because a bug was marked as confirmed 6 months ago doesn't mean it is
still valid.



 I think the best approach to this, like reviews, is to have a place
 where users can go to drive the triage workload to 0. For instance, the
 ubuntu server team had this report for triage:

 http://reqorts.qa.ubuntu.com/reports/ubuntu-server/triage-report.html

 Sadly, it looks like they're overwhelmed or have abandoned the effort
 (I hope this doesn't say something about Ubuntu server itself..), but
 the basic process was to move bugs off these lists. I'm sure if we ask
 nice the author of that code will share it with us and we could adapt
 it for OpenStack projects.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

2014-11-18 Thread Flavio Percoco

On 18/11/14 14:45 -0800, Joe Gordon wrote:



On Tue, Nov 18, 2014 at 10:58 AM, Clint Byrum cl...@fewbar.com wrote:

   Excerpts from Flavio Percoco's message of 2014-11-17 08:46:19 -0800:
Greetings,
   
Regardless of how big/small bugs backlog is for each project, I
believe this is a common, annoying and difficult problem. At the oslo
meeting today, we're talking about how to address our bug triage
process and I proposed something that I've seen done in other
communities (rust-language [0]) that I consider useful and a good
option for OpenStack too.
   
The process consist in a bot that sends an email to every *volunteer*
with 10 bugs to review/triage for the week. Each volunteer follows the
triage standards, applies tags and provides information on whether the
bug is still valid or not. The volunteer doesn't have to fix the bug,
just triage it.
   
In openstack, we could have a job that does this and then have people
from each team volunteer to help with triage. The benefits I see are:
   
* Interested folks don't have to go through the list and filter the
bugs they want to triage. The bot should be smart enough to pick the
oldest, most critical, etc.
   
* It's a totally opt-in process and volunteers can obviously ignore
emails if they don't have time that week.
   
* It helps scaling out the triage process without poking people around
and without having to do a call for volunteers every meeting/cycle/etc
   
The above doesn't solve the problme completely but just like reviews,
it'd be an optional, completely opt-in process that people can sign up
for.
   

   My experience in Ubuntu, where we encouraged non-developers to triage
   bugs, was that non-developers often ask the wrong questions and
   sometimes even harm the process by putting something in the wrong
   priority or state because of a lack of deep understanding.

   Triage in a hospital is done by experienced nurses and doctors working
   together, not triagers. This is because it may not always be obvious
   to somebody just how important a problem is. We have the same set of
   problems. The most important thing is that developers see it as an
   important task and take part. New volunteers should be getting involved
   at every level, not just bug triage.


++, nice analogy.

Another problem I have seen, is we need to constantly re-triage bugs, as just
because a bug was marked as confirmed 6 months ago doesn't mean it is still
valid.


Ideally, the script will take care of this. Bugs that haven't been
update for more than N months will fall into the to-triage pool for
re-triage.

Flavio


 


   I think the best approach to this, like reviews, is to have a place
   where users can go to drive the triage workload to 0. For instance, the
   ubuntu server team had this report for triage:

   http://reqorts.qa.ubuntu.com/reports/ubuntu-server/triage-report.html

   Sadly, it looks like they're overwhelmed or have abandoned the effort
   (I hope this doesn't say something about Ubuntu server itself..), but
   the basic process was to move bugs off these lists. I'm sure if we ask
   nice the author of that code will share it with us and we could adapt
   it for OpenStack projects.

   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
@flaper87
Flavio Percoco


pgpZL8Fz3bsjL.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

2014-11-18 Thread Flavio Percoco

On 18/11/14 10:58 -0800, Clint Byrum wrote:

Excerpts from Flavio Percoco's message of 2014-11-17 08:46:19 -0800:

Greetings,

Regardless of how big/small bugs backlog is for each project, I
believe this is a common, annoying and difficult problem. At the oslo
meeting today, we're talking about how to address our bug triage
process and I proposed something that I've seen done in other
communities (rust-language [0]) that I consider useful and a good
option for OpenStack too.

The process consist in a bot that sends an email to every *volunteer*
with 10 bugs to review/triage for the week. Each volunteer follows the
triage standards, applies tags and provides information on whether the
bug is still valid or not. The volunteer doesn't have to fix the bug,
just triage it.

In openstack, we could have a job that does this and then have people
from each team volunteer to help with triage. The benefits I see are:

* Interested folks don't have to go through the list and filter the
bugs they want to triage. The bot should be smart enough to pick the
oldest, most critical, etc.

* It's a totally opt-in process and volunteers can obviously ignore
emails if they don't have time that week.

* It helps scaling out the triage process without poking people around
and without having to do a call for volunteers every meeting/cycle/etc

The above doesn't solve the problme completely but just like reviews,
it'd be an optional, completely opt-in process that people can sign up
for.



My experience in Ubuntu, where we encouraged non-developers to triage
bugs, was that non-developers often ask the wrong questions and
sometimes even harm the process by putting something in the wrong
priority or state because of a lack of deep understanding.

Triage in a hospital is done by experienced nurses and doctors working
together, not triagers. This is because it may not always be obvious
to somebody just how important a problem is. We have the same set of
problems. The most important thing is that developers see it as an
important task and take part. New volunteers should be getting involved
at every level, not just bug triage.


Heh, great analogy.

The idea is not to encourage developers of the project to participate
actively in the triage process. I'd even say that the final goal is to
make the triage process somehow easier for people willing to do so.

FWIW, bug triage - along side with code reviews - is a very good way
to get started in projects. People triaging bugs should go to the team
asking for guidance when they have no clue what to do with a bug (or
they can just skip it).

I know the above is full of hopes and idealisms but I do think people
willing to help will sign up and they will do the best they can to
help in the process. It may end up being just devs of the project but
that's already a good step forward.

Triaging 10 bugs most of the time doesn't take more than 30mins and I
think it's doable in a week.

Flavio



I think the best approach to this, like reviews, is to have a place
where users can go to drive the triage workload to 0. For instance, the
ubuntu server team had this report for triage:

http://reqorts.qa.ubuntu.com/reports/ubuntu-server/triage-report.html

Sadly, it looks like they're overwhelmed or have abandoned the effort
(I hope this doesn't say something about Ubuntu server itself..), but
the basic process was to move bugs off these lists. I'm sure if we ask
nice the author of that code will share it with us and we could adapt
it for OpenStack projects.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
@flaper87
Flavio Percoco


pgp5tTZfl8cnC.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

2014-11-18 Thread Flavio Percoco

On 18/11/14 18:46 +0100, Thierry Carrez wrote:

Flavio Percoco wrote:

On 18/11/14 11:42 +0100, Thierry Carrez wrote:

With storyboard.openstack.org http://storyboard.openstack.org looming
on the horizon, should such an effort be put on the back burner for now?


I don't expect integrated projects to be able to switch to storyboard
for bug tracking just yet. Our current goal is to have it ready for
infrastructure dogfooding now (actually, yesterday), ready for feature
tracking (and bugs tracking replacement for willing non-integrated
guinea pigs) in 6 months, and ready for everyone in 12 months.


Is it in a good enough state that would a low smaller projects - zaqar
- to jump in and help testing the storyboard? I'm happy to give it a
try.


The trick is that it's missing some features that would make it a pain,
even for an incubated project (think: no private security bugs). Also
we'd like to switch all integrated projects at the same time, so that
release management doesn't have to play with two tools in parallel.

Also, nothing in storyboard actually makes triaging less painful :)


/me sadpanda

--
@flaper87
Flavio Percoco


pgpMkkp6OAiUT.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

2014-11-17 Thread Flavio Percoco

Greetings,

Regardless of how big/small bugs backlog is for each project, I
believe this is a common, annoying and difficult problem. At the oslo
meeting today, we're talking about how to address our bug triage
process and I proposed something that I've seen done in other
communities (rust-language [0]) that I consider useful and a good
option for OpenStack too.

The process consist in a bot that sends an email to every *volunteer*
with 10 bugs to review/triage for the week. Each volunteer follows the
triage standards, applies tags and provides information on whether the
bug is still valid or not. The volunteer doesn't have to fix the bug,
just triage it.

In openstack, we could have a job that does this and then have people
from each team volunteer to help with triage. The benefits I see are:

* Interested folks don't have to go through the list and filter the
bugs they want to triage. The bot should be smart enough to pick the
oldest, most critical, etc.

* It's a totally opt-in process and volunteers can obviously ignore
emails if they don't have time that week.

* It helps scaling out the triage process without poking people around
and without having to do a call for volunteers every meeting/cycle/etc

The above doesn't solve the problme completely but just like reviews,
it'd be an optional, completely opt-in process that people can sign up
for.

Thoughts?
Flavio

[0] https://mail.mozilla.org/pipermail/rust-dev/2013-April/003668.html

--
@flaper87
Flavio Percoco


pgpAF92uXuyZ7.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

2014-11-17 Thread Dolph Mathews
As someone who has spent quite a bit of time triaging bugs, I'd be hugely
in favor of this. I'd probably be willing to pitch in on additional
projects, as well.

Is there already tooling for this built around Launchpad, or do we have to
roll our own?

With storyboard.openstack.org looming on the horizon, should such an effort
be put on the back burner for now?

On Mon, Nov 17, 2014 at 10:46 AM, Flavio Percoco fla...@redhat.com wrote:

 Greetings,

 Regardless of how big/small bugs backlog is for each project, I
 believe this is a common, annoying and difficult problem. At the oslo
 meeting today, we're talking about how to address our bug triage
 process and I proposed something that I've seen done in other
 communities (rust-language [0]) that I consider useful and a good
 option for OpenStack too.

 The process consist in a bot that sends an email to every *volunteer*
 with 10 bugs to review/triage for the week. Each volunteer follows the
 triage standards, applies tags and provides information on whether the
 bug is still valid or not. The volunteer doesn't have to fix the bug,
 just triage it.

 In openstack, we could have a job that does this and then have people
 from each team volunteer to help with triage. The benefits I see are:

 * Interested folks don't have to go through the list and filter the
 bugs they want to triage. The bot should be smart enough to pick the
 oldest, most critical, etc.

 * It's a totally opt-in process and volunteers can obviously ignore
 emails if they don't have time that week.

 * It helps scaling out the triage process without poking people around
 and without having to do a call for volunteers every meeting/cycle/etc

 The above doesn't solve the problme completely but just like reviews,
 it'd be an optional, completely opt-in process that people can sign up
 for.

 Thoughts?
 Flavio

 [0] https://mail.mozilla.org/pipermail/rust-dev/2013-April/003668.html

 --
 @flaper87
 Flavio Percoco

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev