cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Animesh Chaturvedi <animesh.chaturv...@citrix.com>
Subject RE: [DISCUSS] Don't assign tickets to people when triaging
Date Mon, 08 Apr 2013 20:32:58 GMT


> -----Original Message-----
> From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> Sent: Tuesday, April 02, 2013 3:46 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Don't assign tickets to people when triaging
> 
> 
> 
> > -----Original Message-----
> > From: Will Chan [mailto:will.chan@citrix.com]
> > Sent: Tuesday, April 02, 2013 2:22 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [DISCUSS] Don't assign tickets to people when triaging
> >
> > I think the purpose of this discussion is that there are people
> > currently today that are auto-assigning bugs to individual developers
> > of the community.  Most of these bugs were assigned for two main reasons.
> >
> > 1. It was blatantly obvious the bugs stemmed from the feature developer.
> >
> > - OR -
> >
> > 2. The bugs were deemed a blocker either by the community, release
> > manager, or someone that knows about the issue.
> >
> > Both of these cases were done partly because of their $dayjobs leaking
> > into community.  It simply looks like there are hidden agendas when
> > these triaging were happening.  I think there are obviously ways we
> > can get around but to me, it's a burdensome process especially when
> > JIRA is a tool that helps our community in organizing our work and
> > priorities rather than using the dev@ list.
> >
> > The second point is that by assigning these bugs, we are effectively
> > pushing out anyone that wants to contribute.  But as Sebastian has
> > already done some legwork, the majority of the bugs are in Unassigned
> > state.  If someone wants to contribute, there are hundreds of bugs to
> participate in.  Just go grab one.
> >
> > Everyone has probably something they are doing besides reading the ML
> > every day or doing a search on JIRA.  By assigning a bug on JIRA, that
> > person gets notified.  He can always decline to fix it but at least a
> > notification has been sent.  I think for the most serious of bugs or
> > blocker bugs, anyone in the community should be able to help with the
> > triage process.  If not for the very least, it helps in notifying the
> > developer and effectively pinging the person if they can help assist with the
> bug or not.
> >
> > All I am proposing is a more efficient way of dealing with serious
> > blocker issues.  We can end up losing days of work if we have to wait
> > sometimes.  I think there are plenty of developers that want to help
> > in some way, otherwise, why bother to be on the dev list.  However, I
> > do know that I cannot search JIRA everyday nor can I read every thread
> > that happens here.  Someone pinging me via JIRA notifications seems
> > like a decent way to be notified.  I can always decline to fix the bug.
> >
> > What do you guys think?  Am I the only that wants to make things more
> > efficient here?
> >
> > Will
> >

> I take some blame for assigning the defects but intent was to get issues (mostly
> blockers and critical) resolved  faster and not to exclude anyone.  The issues
> were assigned based on our list of component maintainers at [1]. Noah thanks
> for clarifying that the triaging may exclude new contributors.
> 
> Can I propose that whoever wants to contribute in fixing defects for a specific
> module add their name as maintainer of  that module in component
> maintainer list [1]? And we update how to contribute wiki on this process .
> 
> During 4.1  there are a large number of major issues that as community we
> ended up not addressing and given that number of unassigned issues is high %
> should we consider auto-assign based on the maintainers list? This is still not
> optimal since auto-assign will go to primary maintainer and secondary
> maintainers still need to pull in defects  but is better than one person triaging
> defects.
> 
> I also wanted to find out how do other projects get through resolving blocker
> bugs sooner?
> 
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Current+Maintainer
> s+Per+Component
> 
[Animesh>] Folks I wanted to get your opinion on auto-assignment based on the component
maintainers list. We can also create shared issues filters based on components. Folks can
subscribe to the filters of interest and receive daily email notification.
> 
> > > -----Original Message-----
> > > From: Sebastien Goasguen [mailto:runseb@gmail.com]
> > > Sent: Tuesday, April 02, 2013 1:56 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: [DISCUSS] Don't assign tickets to people when triaging
> > >
> > >
> > > On Apr 2, 2013, at 3:21 PM, Noah Slater <nslater@apache.org> wrote:
> > >
> > > > Dear community,
> > > >
> > > > Right now, we have people who are regularly going through JIRA and
> > > > triaging tickets. This is totally fantastic, and a very valuable
> > > > activity for the project. (So thank you!) But I also notice that
> > > > specific individuals are being assigned to the tickets in the process.
> > > >
> > > > This is a form of "cookie licking". The analogy is that if you
> > > > fancy a cookie, but you're too hungry right now, you take a lick
> > > > of it so nobody else can touch it. This is an anti-pattern and we
> > > > should try to
> > > avoid it.
> > > >
> > > > In general, I would say we should only be assigning a ticket to
> > > > ourselves, and we should only be doing that when we actually
> > > > intend to sit down and work on it.
> > > >
> > > > If we have people going through and saying "well, this is clearly
> > > > Joe's area" or "this is clearly Fred's area" then that is a great
> > > > way to make sure that those areas remain "Joe's area" or "Fred's
> > > > area" or
> > > whatever.
> > > > Which is unhealthy for the project.
> > > >
> > > > So what I would suggest is that we consider changing the way we
> > > > work
> > > here.
> > > >
> > > > Ticket triage might change so that tickets are put on to component
> > > > backlogs. And engineers can switch from grabbing tickets of their
> > > > "assigned to me" report, and start looking at the "Foo feature
> > > > backlog" report instead. Selecting a ticket and assigning it *to
> > > > themselves* when they are *starting work on it*.
> > > >
> > > > (This would then take the ticket off the component backlog. So the
> > > > backlog report would only display tickets that were unassigned and
> > > > available to
> > > > grab.)
> > > >
> > > > This would mean that all this valuable ticket triage work we're
> > > > doing is something that can benefit everyone in the project (not
> > > > just people who are already known for their contributions) and
> > > > will hopefully open the development workflow to people who are
> > > > just starting out with the project, or want to get their toes wet.
> > > >
> > > > In fact, when someone comes to us and asks "how can I contribute"
> > > > we can point them at these backlogs and say "well, just grab a
> > > > ticket off one of these queues, assign it to yourself, and start working
on
> it!"
> > > > We could make use of a "difficulty" field too, so you could sort
> > > > by difficulty, and grab one of the "easy", "medium", or "hard" tickets.
> > > >
> > > > Thoughts?
> > > >
> > > > --
> > > > NS
> > >
> > > Hi Noah, I know where you are coming from here, I would just like to
> > > point out that a quick JIRA search for Unassgined ticket returns 392
> > > tickets up for grabs (out of 641 open tickets). That's 61% of our
> > > total tickets that are Unassigned.
> > >
> > > In some ways and to keep things simple, anyone should feel free to
> > > grab any ticket they think they can work on and hopefully close. No
> > > need for buckets, priorities or difficulty rating. Just grab it.
> > >
> > >
> > > -Sebastien
> > >


Mime
View raw message