Hi Bryant,

> There is one potential downside with this workflow.  When a bug is
> assigned to someone, it will discourage anyone else from looking at it.
> You may end up with a lot of bugs assigned that are not actively being
> worked on.
>
Can't agree more

>
> An alternative approach would be to just subscribe developers you think
> may be willing and interested to take a look.  That way they'll get a
> notification email about it, but it won't discourage anyone else from
> working on it that may want to in the meantime.

Good Way!

Damon

2014-11-10 9:47 GMT+08:00 Russell Bryant <rbry...@redhat.com>:

>
>
> ----- Original Message -----
> > Hi folks,
> >
> > I have been supervising bug list for neutron during the last release
> cycle,
> > trying
> > to do some "housekeeping", prioritizing issues and fixing some of them.
> >
> > As you might see, amount of bugs (even staying in "New" state) doesn't go
> > down.
> > Bugs appear at quite fast pace, and some of them hang for quite a long
> time,
> > especially if someone has assigned the bug on himself and then abandoned
> > working on it.
> > One of the other reasons for that is that we lack volunteers willing to
> fix
> > those bugs.
> >
> > So,
> >
> > If you're willing to help, have some knowledge of neutron and its
> codebase or
> > you have a lab where you can reproduce (and hence, confirm) the bug and
> > provide more additional debugging info, that would be great!
> > My plan is to get your contact, knowing what "part" of neutron project
> you
> > familiar with, and then assign bugs directly to you if I feel that the
> issue
> > matches your experience.
> >
> > I just want to make bug triaging/fixing process a bit more iterative and
> > efficient, with a help of community.
> > So please reach directly to me and let me know what you are
> > interested/experienced with.
>
> There is one potential downside with this workflow.  When a bug is
> assigned to someone, it will discourage anyone else from looking at it.
> You may end up with a lot of bugs assigned that are not actively being
> worked on.
>
> An alternative approach would be to just subscribe developers you think
> may be willing and interested to take a look.  That way they'll get a
> notification email about it, but it won't discourage anyone else from
> working on it that may want to in the meantime.
>
> --
> Russell Bryant
>
> _______________________________________________
> 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

Reply via email to