Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of animesh.chaturvedi@citrix.com
 designates 66.165.176.89 as permitted sender)
From: Animesh Chaturvedi <animesh.chaturvedi@citrix.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Date: Tue, 2 Apr 2013 15:45:47 -0700
Subject: RE: [DISCUSS] Don't assign tickets to people when triaging
Thread-Topic: [DISCUSS] Don't assign tickets to people when triaging
Thread-Index: Ac4v5IaXA3ETkO3lSkKZrivLx/H4aQAAPxcwAAN0QGA=
Message-ID: 
 <7A92FF96DF135843B4B608FB576BFC3E0141EAB92640@SJCPMAILBOX01.citrite.net>
References: 
 <CAPaJBx5-Z8FXcCxYfiYX70LH1-VCXjB0mo=uT8c-FTQX8uXaxQ@mail.gmail.com>
 <062C66BA-11E3-4FB0-9336-9A0C71CCC47D@gmail.com>
 <61AE1E2837A06D4A8E98B796183842D4013D7DB07B4C@SJCPMAILBOX01.citrite.net>
In-Reply-To: 
 <61AE1E2837A06D4A8E98B796183842D4013D7DB07B4C@SJCPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


> -----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
>=20
> 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.
>=20
> 1. It was blatantly obvious the bugs stemmed from the feature developer.
>=20
> - OR -
>=20
> 2. The bugs were deemed a blocker either by the community, release manage=
r,
> or someone that knows about the issue.
>=20
> Both of these cases were done partly because of their $dayjobs leaking in=
to
> community.  It simply looks like there are hidden agendas when these tria=
ging
> were happening.  I think there are obviously ways we can get around but t=
o 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.
>=20
> The second point is that by assigning these bugs, we are effectively push=
ing 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 wa=
nts to
> contribute, there are hundreds of bugs to participate in.  Just go grab o=
ne.
>=20
> Everyone has probably something they are doing besides reading the ML eve=
ry
> day or doing a search on JIRA.  By assigning a bug on JIRA, that person g=
ets
> notified.  He can always decline to fix it but at least a notification ha=
s been
> sent.  I think for the most serious of bugs or blocker bugs, anyone in th=
e
> 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 pe=
rson if
> they can help assist with the bug or not.
>=20
> All I am proposing is a more efficient way of dealing with serious blocke=
r
> 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, other=
wise,
> why bother to be on the dev list.  However, I do know that I cannot searc=
h 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 alw=
ays
> decline to fix the bug.
>=20
> What do you guys think?  Am I the only that wants to make things more
> efficient here?
>=20
> Will
>=20
I take some blame for assigning the defects but intent was to get issues (m=
ostly blockers and critical) resolved  faster and not to exclude anyone.  T=
he 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 spec=
ific module add their name as maintainer of  that module in component maint=
ainer 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 e=
nded up not addressing and given that number of unassigned issues is high %=
 should we consider auto-assign based on the maintainers list? This is stil=
l 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 t=
riaging defects.

I also wanted to find out how do other projects get through resolving block=
er bugs sooner?=20

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Current+Maintain=
ers+Per+Component


> > -----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
> >