[DISCUSS] Don't assign tickets to people when triaging

[Noah Slater <ns...@apache.org>]

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

Re: [DISCUSS] Don't assign tickets to people when triaging

[Noah Slater <ns...@apache.org>]

You might want to speak to Infra about it first.


On 9 April 2013 00:34, Animesh Chaturvedi <an...@citrix.com>wrote:

>
>
> > -----Original Message-----
> > From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> > Sent: Monday, April 08, 2013 2:05 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] Don't assign tickets to people when triaging
> >
> >
> >
> > On 4/8/13 1:32 PM, "Animesh Chaturvedi" <an...@citrix.com>
> > wrote:
> >
> > >
> > >>
> > >> 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+Maintai
> > >>ner
> > >> 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.
> >
> > Although the wiki and Jira are useful repositories of information, the
> ML is
> > where things are supposed to get decided. How about a daily report
> posted to
> > the ML (could be auto posted from Jira?) that lists
> >  - defects that have aged > 1 week without an owner
> >  - defects newly assigned to somebody
> >  - new defects without any owners
> >  - defects assigned but no progress > 1 week
> >
> > Yes, anybody could run the same report on Jira, but this brings it out
> in the
> > open?
> [Animesh>] That is certainly doable. As per Jira documentation it supports
> subscription emails to  be sent to groups and supports scheduling, but
> looks like I don't have sufficient privilege to check on this feature in
> Apache CloudStack JIRA. Chip/David can you confirm whether this can be done
> in Apache JIRA
>
>


-- 
NS

RE: [DISCUSS] Don't assign tickets to people when triaging

[Animesh Chaturvedi <an...@citrix.com>]

> -----Original Message-----
> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> Sent: Monday, April 08, 2013 2:05 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Don't assign tickets to people when triaging
> 
> 
> 
> On 4/8/13 1:32 PM, "Animesh Chaturvedi" <an...@citrix.com>
> wrote:
> 
> >
> >>
> >> 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+Maintai
> >>ner
> >> 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.
> 
> Although the wiki and Jira are useful repositories of information, the ML is
> where things are supposed to get decided. How about a daily report posted to
> the ML (could be auto posted from Jira?) that lists
>  - defects that have aged > 1 week without an owner
>  - defects newly assigned to somebody
>  - new defects without any owners
>  - defects assigned but no progress > 1 week
> 
> Yes, anybody could run the same report on Jira, but this brings it out in the
> open?
[Animesh>] That is certainly doable. As per Jira documentation it supports subscription emails to  be sent to groups and supports scheduling, but looks like I don't have sufficient privilege to check on this feature in Apache CloudStack JIRA. Chip/David can you confirm whether this can be done in Apache JIRA

Re: [DISCUSS] Don't assign tickets to people when triaging

[Rohit Yadav <bh...@apache.org>]

On Wed, Apr 10, 2013 at 12:40 PM, Rohit Yadav <bh...@apache.org> wrote:

> Hi Abhi,
>
> First of all I totally agree with you on having at least our release
> manager the triaging blockers.
>
> Secondly, we need to understand the issue Noah is trying to raise. The
> issue assignment way now is surely an anti-pattern. Let's not deviate from
> the real issue Noah started with this thread.
>
> From what I understand and wanted to convey is that in an opensource
> project the development should be done by contributors and forced upon
> them.
>

Err, typo:
not forced upon them :)


> When someone assigns an issue to me without my consent, I personally see
> it as an offence. To say it again, I want to promote culture where everyone
> (esp. committers) develops a habit to go through reviewboard, mailing lists
> and jira and take their own decisions.
>
> Prasanna man you're awesome already you don't need to explain your
> awesomeness and willingness to be assigned bugs and fix 'em.
> People/companies who have their interests in fixing some issue on time is
> not an issue here. The problem is couple of anti-patterns, just want to
> tell what they are IMO;
>
> 1. Issue assignment without consent, by few individuals who have taken the
> implicit role of managers. Solution: Politely ask them to avoid doing that.
> 2. Issue assignment not being taken up by contributors but forced many
> times. Solution: Fix habits, inculcate a weekly routine at least.
> 3. Push from individuals who allegedly are working for a company and
> pursing company's interest on ACS at cost of ruining the Apache culture. If
> you're a ACS committer, your decisions should be your own not your
> companys'.  For example, I would not like to see emails about 4.2 blockers
> or push about the same. ACS has yet to release 4.1.
> Solution: Pl. don't do it, do whatever you want in your private fork,
> leave ACS the opensoure Apache way.
>
> Maybe I'm missing the some part of the picture here, maybe I'm wrong
> "hippie". I embrace change and would like learn and fix my thinkings,
> advise?
>
> Cheers.
>
>
> On Wed, Apr 10, 2013 at 12:07 PM, Abhinandan Prateek <
> Abhinandan.Prateek@citrix.com> wrote:
>
>> I see that the term "cookie-licking" is being used frequently in the email
>> thread.
>>
>> We are talking about roughly 200 cookies. 55 of which nobody is willing to
>> touch.
>> 150 of them are already assigned that means that these are either being
>> licked or being eaten.
>>
>>
>> As per the above definition if a release manager assigns a bug to a
>> community member who goes and fixes it, it does not count as cookie
>> licking.
>>
>> Cookie licking is when someone sits on a bug and does not act on it, and
>> in that prevents another member to pick it up.
>>
>> *I will say guys instead of worrying about cookie licking pick the cookies
>> there are so many around !*
>>
>> -abhi
>>
>>
>>
>>
>>
>>
>> On 10/04/13 9:43 AM, "Abhinandan Prateek" <Ab...@citrix.com>
>> wrote:
>>
>> >We have to leave some of this flexibility in the hands of the release
>> >manager.
>> >I agree the community should have a first go at the unassigned tickets,
>> >while some tickets are picked up quickly others are around for a while.
>> >As a release manager it is the responsibility bestowed in that person
>> that
>> >the release is made on time and with quality.
>> >So I think it is perfectly fine for the people responsible for a release
>> >to triage a blocker in case it is blocking the work of some of the
>> >community member and there is an urgency to get it fixed. Same goes for
>> >the blockers and criticals that remain on Jira for some time.
>> >
>> >I will not though differentiate between community members as all of the
>> >members who contribute are passionate about it and have time to
>> >contribute.
>> >
>> >-abhi
>> >
>> >
>> >On 10/04/13 12:05 AM, "Noah Slater" <ns...@apache.org> wrote:
>> >
>> >>Got it. Thanks! :)
>> >>
>> >>
>> >>On 9 April 2013 19:29, Rohit Yadav <bh...@apache.org> wrote:
>> >>
>> >>> On Tue, Apr 9, 2013 at 11:51 PM, Noah Slater <ns...@apache.org>
>> >>>wrote:
>> >>>
>> >>> > When you say it's understandable that people being paid to work on
>> >>> > CloudStack full time engage in cookie licking, do you mean to say
>> you
>> >>> think
>> >>> > it is acceptable?
>> >>>
>> >>>
>> >>> Hell NO, understandable == I understand how people work in the
>> >>>companies
>> >>> who pay them to work on ACS.
>> >>> But understandable != acceptable.
>> >>>
>> >>>
>> >>> > Or do you believe we should be working to prevent it?
>> >>> >
>> >>>
>> >>> Yes! That's what I'm saying: we should be working to prevent it. A way
>> >>>I
>> >>> suggested is to inculcate the habit among ourselves (all contributors)
>> >>>and
>> >>> promote the culture within ACS community to take initiatives and to
>> >>>assign
>> >>> the tickets themselves.
>> >>>
>> >>> No one should assign tickets to others unless a person has jira ACL
>> >>>issues
>> >>> and has explicitly asked for same on public ML to someone/anyone.
>> >>>
>> >>> Cheers.
>> >>>
>> >>>
>> >>> >
>> >>> >
>> >>> > On 9 April 2013 19:14, Rohit Yadav <bh...@apache.org> wrote:
>> >>> >
>> >>> > > On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam
>> >>><ts...@apache.org>
>> >>> > > wrote:
>> >>> > >
>> >>> > > > On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi
>> >>>wrote:
>> >>> > > > > [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.
>> >>> > > >
>> >>> > > > I have no opinion and am okay whichever way -
>> >>>auto-assign/unassigned.
>> >>> > > > But these workflows should be _*clearly*_ mentioned to
>> >>>contributors
>> >>> > > > and where they will go looking for them - wiki, website etc.
>> >>> > > >
>> >>> > > >
>> >>> > > A non-sponsored new/old (casual/hippie) contributor would try to
>> >>>search
>> >>> > > among unassigned issues, while managers/developers/committers
>> whose
>> >>> > $dayjob
>> >>> > > allows them to work on ACS fulltime will tend to do 'cookie
>> lickin'
>> >>> which
>> >>> > > is understandable and will assure that someone gets the privilege
>> >>>to
>> >>> work
>> >>> > > on it and their employers will make sure the task would be done :)
>> >>> > >
>> >>> > > I would prefer an environment where every contributor (sponsored
>> or
>> >>> > > otherwise) would assign the tickets themselves, and unassign if
>> >>>they
>> >>> > cannot
>> >>> > > do it or don't have time/resources for it.
>> >>> > >
>> >>> > > We've already seen several occasions where someone assigns an
>> issue
>> >>>to
>> >>> > > someone and we see cycle of assignments because the "assigner" had
>> >>>no
>> >>> > clue
>> >>> > > about the issue or did not really know who would could really
>> >>>resolve
>> >>> the
>> >>> > > issue. Just saying.
>> >>> > >
>> >>> > > Cheers.
>> >>> > >
>> >>> > > Triaging and assigning issues at the time of release to
>> >>> > > > contributors/committers by the Release Manager shouldn't be a
>> >>>problem
>> >>> > > > at all as long as it's communicated (as Chip did for the RC
>> bugs)
>> >>> > > >
>> >>> > > > Thanks,
>> >>> > > >
>> >>> > > > --
>> >>> > > > Prasanna.,
>> >>> > > >
>> >>> > >
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > NS
>> >>> >
>> >>>
>> >>
>> >>
>> >>
>> >>--
>> >>NS
>> >
>>
>>
>

RE: [DISCUSS] Don't assign tickets to people when triaging

[Koushik Das <ko...@citrix.com>]

+1 to Abhi's suggestion.

> -----Original Message-----
> From: Abhinandan Prateek [mailto:Abhinandan.Prateek@citrix.com]
> Sent: Thursday, April 11, 2013 8:40 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Don't assign tickets to people when triaging
> 
> 
> 
> On 10/04/13 8:57 PM, "Joe Brockmeier" <jz...@zonker.net> wrote:
> 
> >On Wed, Apr 10, 2013, at 02:35 AM, Abhinandan Prateek wrote:
> >> I think if you were wrongly assigned bug that you did not want to
> >>work on  just spit it in the mailing list and you will not be guilty
> >>of cookie  licking.
> >>
> >> Given the huge number bugs lets focus on how to reduce that pile
> >> instead of raking up non issues.
> >
> >It's not a non-issue. When people see bugs assigned to a person,
> >they're less likely to go ahead and take it.
> 
> 
> I will start with an example: A critical bug (CLOUDSTACK-1941) that is blocking
> a release (4.1) is not picked up by any community member for 5 days !
> The reason being that it is a UI issue but not that clear from the desc, the
> nature of the bug is known after someone spends time on it.
> 
> Now is it wrong to ask the community members who have expertise on UI to
> fix it, in a bid to help Chip get the release out ?
> 
> A set of guidelines are necessary so that this whole confusion about bugs
> getting assigned is cleared up. I will start by proposing some simple
> rules:
> 
> 1. Never assign bugs that are not critical or blocker unless they meet any of
> the below condition.
> 
> 2. Assign a bug that is open for more than 3 days and none of the community
> member has shown interest in picking it up. This period can vary depending
> on how close a branch where bug is noted is close to a release.
> 
> 3. Assign or request to community for picking up a bug if it is blocking the
> work that a community member may be working on.
> 
> Do add or amend so that we clear up process around this issue.
> 
> 
> >
> >
> >I think we need to find a middle path where:
> >
> >* Everyone is pro-active in reviewing bugs that are in their area, and
> >not depending on a having bugs assigned before they work on them.
> >
> >* We don't have a ridiculous number of bugs assigned to people where
> >they may not get to those bugs for weeks - when someone else might
> >conceivably work on them, but be put off because they think "Oh, Random
> >J. Programmer already has that."
> >
> >* We can assign bugs when it does make sense, without there being an
> >absolute rule against assigning bugs to people when common sense
> >dictates otherwise.
> 
> I just tried to extract this part of the email as a set of rules above.
> 
> >

Re: [DISCUSS] Don't assign tickets to people when triaging

[Noah Slater <ns...@apache.org>]

On 11 April 2013 04:08, Abhinandan Prateek <Ab...@citrix.com>wrote:

>
> Now is it wrong to ask the community members who have expertise on UI to
> fix it, in a bid to help Chip get the release out ?
>

It is certainly not wrong to co-ordinate with people in an effort to ship a
release. (I would point out, however, that it is not Chip getting the
release out. It is the community. But maybe I am misinterpreting your
remark here...)

2. Assign a bug that is open for more than 3 days and none of the
> community member has shown interest in picking it up. This period can vary
> depending on how close a branch where bug is noted is close to a release.
>

Three days?

That is a very short period of time, when you consider the size of our JIRA
queue, and the average timespan of a ticket.

I really don't see why bugs that are not on the critical path of a release
should be assigned at all. As has already been pointed out several times in
this thread, this is an exclusionary practice which is likely to put off
new contributions to the project. It will calcify the existing structure
and roles, and will hamper CloudStack's ability to grow as a project.

I don't understand why non-critical bugs cannot be categorised into
components. And then engineers can pick up items of the component backlogs
as they become free or want to work on CloudStack. This sort of approach is
inclusionary. Anybody can go to JIRA and click on one of the component
reports, and just take a ticket, and start working on it. (Without having
to contact the person it is "assigned" to to ask if they may start on it.
Which, in reality, nobody is going to to do.)

I also reject the idea that engineers need tickets assigned to them as
either a) some sort of communication method, or b) some way to spur them
into action. Firstly, we have the mailing list as a communication method.
If you want a particular set of bugs to be worked on, or whatever, then
post a message to the list, and ask for participation. Secondly, we should
not be spurring anybody into action. This is a volunteer project, and
people contribute as and when they can. They should not be managed like an
employee would be managed. Which is why it's so important that we build
structures that are open to chaotic volunteer efforts.

If $company is employing people to work on CloudStack, and wants to spur
its employees into action around a certain feature or component, then that
is fine. But this activity must be kept away from the lists. Perhaps have
$company internal email threads where you ask people to focus on things.
Any time that activity leaks on to the list, it sends the wrong message
about how to participate in the project, and sends the wrong message about
$company's relationship to the project.


> 3. Assign or request to community for picking up a bug if it is blocking
> the work that a community member may be working on.
>

Again, this is presumptuous. There is no minimum level of participation. So
saying "Bob, this is your bug, so fix it, because it is blocking me" is the
wrong attitude to take. Instead, we should be using every opportunity we
have, every construct we build, as a way to invite further participation
from the community. A better approach would be to mark the bug as blocking
some other work, and then post a note to the list saying "this bug is
blocking me, can I have some help with it please?" In an email like that,
feel free to CC the engineers you expect might want to / be able to help
out, or mention them by name. But don't make a habit of saying "Bob, this
bug is blocking me, can you fix it" when you could say "this bug is
blocking me, can someone fix it? /cc Bob"


-- 
NS

Re: [DISCUSS] Don't assign tickets to people when triaging

[Abhinandan Prateek <Ab...@citrix.com>]

On 11/04/13 4:23 PM, "prasanna" <ts...@apache.org> wrote:

>On 11 April 2013 15:52, Abhinandan Prateek
><Ab...@citrix.com> wrote:
>>
>>>>
>>>>I will start with an example: A critical bug (CLOUDSTACK-1941) that is
>>>>blocking a release (4.1) is not picked up by any community member for 5
>>>>days !
>>>>The reason being that it is a UI issue but not that clear from the
>>>>desc,
>>>>the nature of the bug is known after someone spends time on it.
>>>>
>>>>Now is it wrong to ask the community members who have expertise on UI
>>>>to
>>>>fix it, in a bid to help Chip get the release out ?
>>>>
>>>>A set of guidelines are necessary so that this whole confusion about
>>>>bugs
>>>>getting assigned is cleared up. I will start by proposing some simple
>>>>rules:
>>>>
>>>>1. Never assign bugs that are not critical or blocker unless they meet
>>>>any
>>>>of the below condition.
>>>
>>>Never would be too lenient. Maybe assign it after 7-8 days since they
>>>don't need immediate attention.
>>
>> 7-8 days is a huge time lost. I was suggesting that this to be 3 days.
>>Let
>> other community members chime in too.
>>
>
>Just to note: contributors will enter anytime. They don't necessarily
>know of our release roadmap when they come in looking to contribute.
>And typically they'd be looking at low hanging fruit - ie not blocker,
>criticals. If you're saying 'x days are lost' then that doesn't make
>much sense to an external contributor, x days based on what? If a bug
>is blocking someone else's progress then the person who is blocked
>should make noise on this list so the appropriate person can fix it.
>I think the issue this thread is trying to address is assignment of
>bugs in the background without community participation and/or
>knowledge.

There are two issues here a bug blocking someone and that he has the
option of using mailing list to reach out, I am in absolute agreement here.

The other is a bug is left with no taker, probably even after someone has
shouted on the mailing list that someone take it up. This is where
intelligent triaging say from the release manager will help.

I guess the work as well as the end result are equally important if not
one more. There are people who are out there waiting for a release,
definitely we do not want to disappoint them.

Also pleeezee do not distinguish between community members by trying to
come up with a notion of external or internal contributor. All of us
external members are equally passionate as internal members. All apache
releases happen as per schedule I expect any new contributor joining the
team to have access to the schedule.

>
>Also I don't think bugs are getting fixed immediately after assignment
>as you indicate. Bugs go between Triager 1 to Triager 2 to Developer 3
>and then Developer 3 assigns it to the Developer 4 who fixes the bug.
>Instead - Developer 4 should have got to it first or explained the
>nature of the fix if he hasn't the time to fix it. Which doesn't
>happen either. As Alex proposed, when someone takes up a bug they
>should mark it in progress so that we know work is on going. Instead
>if Triagers are just assigning bugs based on some kind of weird
>LRU-cache in their head of who's (usually $dayjob stakeholder) the
>rightful owner I find it exclusionary to community participation.

We can limit the people who can triage the bugs to say release manager(s).
When a bug goes from 1 person to another as in the example I quoted above
it just shows that it is getting closer to resolution and not just lying
there unclaimed. Again if we have a list of contributors and there area of
interests we can come up with a heuristic to assign unclaimed bugs. Again
I am saying we limit this ability to triage to release manager or his
designated team.

Please clarify what a $dayjob stakeholder is ?

>
>There is no contest on the bugs being assigned by the RM that are
>essential to be fixed for a release. So I agree with you on that.

Yes, I do agree, check above and that too governed by certain rules.

>

Re: [DISCUSS] Don't assign tickets to people when triaging

[prasanna <ts...@apache.org>]

On 11 April 2013 15:52, Abhinandan Prateek
<Ab...@citrix.com> wrote:
>
>>>
>>>I will start with an example: A critical bug (CLOUDSTACK-1941) that is
>>>blocking a release (4.1) is not picked up by any community member for 5
>>>days !
>>>The reason being that it is a UI issue but not that clear from the desc,
>>>the nature of the bug is known after someone spends time on it.
>>>
>>>Now is it wrong to ask the community members who have expertise on UI to
>>>fix it, in a bid to help Chip get the release out ?
>>>
>>>A set of guidelines are necessary so that this whole confusion about bugs
>>>getting assigned is cleared up. I will start by proposing some simple
>>>rules:
>>>
>>>1. Never assign bugs that are not critical or blocker unless they meet
>>>any
>>>of the below condition.
>>
>>Never would be too lenient. Maybe assign it after 7-8 days since they
>>don't need immediate attention.
>
> 7-8 days is a huge time lost. I was suggesting that this to be 3 days. Let
> other community members chime in too.
>

Just to note: contributors will enter anytime. They don't necessarily
know of our release roadmap when they come in looking to contribute.
And typically they'd be looking at low hanging fruit - ie not blocker,
criticals. If you're saying 'x days are lost' then that doesn't make
much sense to an external contributor, x days based on what? If a bug
is blocking someone else's progress then the person who is blocked
should make noise on this list so the appropriate person can fix it.
I think the issue this thread is trying to address is assignment of
bugs in the background without community participation and/or
knowledge.

Also I don't think bugs are getting fixed immediately after assignment
as you indicate. Bugs go between Triager 1 to Triager 2 to Developer 3
and then Developer 3 assigns it to the Developer 4 who fixes the bug.
Instead - Developer 4 should have got to it first or explained the
nature of the fix if he hasn't the time to fix it. Which doesn't
happen either. As Alex proposed, when someone takes up a bug they
should mark it in progress so that we know work is on going. Instead
if Triagers are just assigning bugs based on some kind of weird
LRU-cache in their head of who's (usually $dayjob stakeholder) the
rightful owner I find it exclusionary to community participation.

There is no contest on the bugs being assigned by the RM that are
essential to be fixed for a release. So I agree with you on that.

RE: [DISCUSS] Don't assign tickets to people when triaging

[Animesh Chaturvedi <an...@citrix.com>]

> -----Original Message-----
> From: Joe Brockmeier [mailto:jzb@zonker.net]
> Sent: Thursday, April 11, 2013 7:34 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Don't assign tickets to people when triaging
> 
> On Thu, Apr 11, 2013, at 09:28 AM, Noah Slater wrote:
> > To me, it seems like what you're describing are components. You assign
> > or sort the ticket into a component. Then I guess, people who are
> > interested can watch that component for new issues. I am not sure if
> > there's a way to "watch" a component in JIRA so that you get email
> > notifications for it. I took a look, but couldn't find anything.
> > Perhaps Infra would install a plugin for us. (I noticed that at least
> > one such plugin exists.) At the very least, you could save a report as
> > a favourite...
> 
> Triaging tickets into components, and making sure that new tickets are
> appropriately categorized, should be fine.
> 
> I don't know if there's specifically a "watch" feature for a component, but it's
> easy enough to bookmark a search for a specific component and look
> through the tickets.
> 
> Best,
> 
> jzb
[Animesh>] We can create shared filters based on components. Folks can subscribe to the filters to be notified by email as per their schedule [1]. By default one can only create Personal Subscriptions but folks with 'Manage Group Filter Subscriptions'  privilege can set up the subscription be sent to  a group as well. I have requested INFRA to grant me the privilege, I will try it once I get the privilege and update the community on findings.


[1[]https://confluence.atlassian.com/display/JIRA/Receiving+Search+Results+via+Email

Re: [DISCUSS] Don't assign tickets to people when triaging

[Joe Brockmeier <jz...@zonker.net>]

On Thu, Apr 11, 2013, at 09:28 AM, Noah Slater wrote:
> To me, it seems like what you're describing are components. You assign or
> sort the ticket into a component. Then I guess, people who are interested
> can watch that component for new issues. I am not sure if there's a way
> to
> "watch" a component in JIRA so that you get email notifications for it. I
> took a look, but couldn't find anything. Perhaps Infra would install a
> plugin for us. (I noticed that at least one such plugin exists.) At the
> very least, you could save a report as a favourite...

Triaging tickets into components, and making sure that new tickets are
appropriately categorized, should be fine. 

I don't know if there's specifically a "watch" feature for a component,
but it's easy enough to bookmark a search for a specific component and
look through the tickets. 

Best,

jzb
-- 
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [DISCUSS] Don't assign tickets to people when triaging

[Noah Slater <ns...@apache.org>]

To me, it seems like what you're describing are components. You assign or
sort the ticket into a component. Then I guess, people who are interested
can watch that component for new issues. I am not sure if there's a way to
"watch" a component in JIRA so that you get email notifications for it. I
took a look, but couldn't find anything. Perhaps Infra would install a
plugin for us. (I noticed that at least one such plugin exists.) At the
very least, you could save a report as a favourite...


On 11 April 2013 15:20, Abhinandan Prateek <Ab...@citrix.com>wrote:

>
>
> On the Jira notification my suggestion will be to have a goto list of
> people for various domains of expertise. Anyone can register for these
> domains. When a bug is filed, the filer selects one of the domains he
> thinks that is right for getting the bug to be resolved. This alerts the
> people who have volunteered for that domain. We may take this one step
> future in that for each domain we can have a designated contact person who
> may once in a while take a look at the list of open issues in that domain
> and may further take action for quicker resolution.
>
> I think I had enough inputs for the day :-), Moreover the day is ending in
> my timezone.
> I guess that did bring some issues to the notice of community, I will
> expect other community members to think of solutions.
> With so many passionate members in this community I think we will arrive
> at a good solution that works.
>
>
> Kudos to the community !
>
>
> On 11/04/13 7:17 PM, "Noah Slater" <ns...@apache.org> wrote:
>
> >I believe it is possible to "mention" someone in a JIRA ticket in such a
> >way that they get notified. Might this be an effective way of CCing
> >someone
> >into the conversation, without prescribing who should fix it? Might there
> >be some room for exploration here?
> >
> >
> >On Thursday, 11 April 2013, Abhinandan Prateek wrote:
> >
> >> Yes, I think we need to space our releases further apart.
> >> I had big trouble when master was unstable for a while and specially on
> >> VMware it was difficult to deploy and test features. Yes for each issue
> >>I
> >> could have shouted on mail list I saw people doing that but the fact is
> >> that instability was around for a while. Doesn't it make sense that in
> >>such
> >> scenarios we could do things in a more pro active manner. Again I donot
> >>see
> >> much difference in asking someone on Jira to pick a issue vs sending a
> >> email, but will agree to whatever the community decides here.
> >>
> >> Also community members should volunteer to own some part so that in
> >>above
> >> circumstances a person looking for some fix can approach that member,
> >>once
> >> again a suggestion.
> >>
> >>
> >>
> >> On 11-Apr-2013, at 5:17 PM, "Noah Slater"
> >><nslater@apache.org<javascript:;>>
> >> wrote:
> >>
> >> > Of course releases are important.
> >> >
> >> > But if our current cadence is putting too much pressure on the
> >>community,
> >> > one option might be to do our releases further apart from each other.
> >>Or,
> >> > we get strict about the principal of time based releases: i.e. if your
> >> > feature is not ready for the freeze, then it doesn't make it in. No
> >>big
> >> > deal. If it's ready for the next freeze, then we'll ship it then.
> >> >
> >> > Also, I may be reading your message wrong, but there's no need for
> >>this
> >> to
> >> > be a divisive argument. There are no "sides" to this. As a community,
> >>it
> >> is
> >> > up to us all to identify our problems, and figure out solutions.
> >> >
> >> > So what problems do you think we'll run in to if we stop assigning the
> >> > majority of bugs, and how do you think we can mitigate those
> >>problems? Or
> >> > do you have another idea in mind altogether?
> >> >
> >> >
> >> >
> >> >
> >> > On 11 April 2013 12:40, Abhinandan Prateek <
> >> Abhinandan.Prateek@citrix.com <javascript:;>>wrote:
> >> >
> >> >> I think it will be good if we also find out a process so that the
> >> release
> >> >> cycle is not affected by unclaimed bugs sitting out there. Here I am
> >> >> assuming the releases are important.
> >> >>
> >> >> I guess the discussion has turned into keeping things free without
> >> >> offering solutions to problems that that system will create.
> >> >>
> >> >>
> >> >> On 11/04/13 5:04 PM, "John Burwell" <jburwell@basho.com
> >><javascript:;>>
> >> wrote:
> >> >>
> >> >>> +1
> >> >>>
> >> >>> On Apr 11, 2013, at 7:22 AM, Noah Slater
> >><nslater@apache.org<javascript:;>>
> >> wrote:
> >> >>>
> >> >>>> On 11 April 2013 11:22, Abhinandan Prateek
> >> >>>> <Abhinandan.Prateek@citrix.com <javascript:;>>wrote:
> >> >>>>
> >> >>>>>
> >> >>>>> 7-8 days is a huge time lost. I was suggesting that this to be 3
> >> days.
> >> >>>>> Let
> >> >>>>> other community members chime in too.
> >> >>>>
> >> >>>>
> >> >>>> I should have replied to this in my previous missive. But I want to
> >> >>>> reenforce how unhealthy I believe this practice is. 7-8 days, or
> >>even
> >> 3
> >> >>>> days "being a huge time loss" makes absolutely no sense to me at
> >>all.
> >> >>>> Assigning a bug should not mean it gets fixed any faster. If it
> >>does,
> >> >>>> then
> >> >>>> we need to change the way we are working. (And if this means
> >>changing
> >> >>>> the
> >> >>>> JIRA ticket workflow, then so be it. If something isn't working for
> >> us,
> >> >>>> we
> >> >>>> change it.)
> >> >>>>
> >> >>>> In fact, I would go so far as to say that we should think of
> >>assigning
> >> >>>> bugs
> >> >>>> as an exclusionary practice. Every time you assign a bug, you're
> >> >>>> shutting
> >> >>>> out the community. That's how we should think about it. Assign the
> >> bug,
> >> >>>> shut out the community. And so, I would say we should try to avoid
> >> doing
> >> >>>> it, unless it is absolutely necessary. (Such as when you're
> >> >>>> co-ordinating
> >> >>>> some release critical work, or when you, yourself, are about to
> >>start
> >> >>>> work
> >> >>>> on something. Of course, it's perfectly fine to shut out the
> >> community,
> >> >>>> if
> >> >>>> you're doing that at the same time as starting work on something!)
> >> >>>>
> >> >>>>
> >> >>>> --
> >> >>>> NS
> >> >
> >> >
> >> > --
> >> > NS
> >>
> >
> >
> >--
> >NS
>
>


-- 
NS

Re: [DISCUSS] Don't assign tickets to people when triaging

[Abhinandan Prateek <Ab...@citrix.com>]

+1 To what Chip had to say on this thread. My use of ownership was wrong
and I actually meant "interest". I have also started on the
producingoss.com as suggested by Rohit, looks like a good way to
understand the working of a voluntary community.

So now that I am positive on the community feedback, I realise some of
these may not work in the $dayjob but a good understanding can benefit
both worlds.


On 11/04/13 9:35 PM, "prasanna" <ts...@apache.org> wrote:

>Abhi - not to gang up on you and I'm glad to see you share your
>opinions, concerns about release management and such.
>
>I see the problem you might be facing though. I think it would be
>better to have your internal JIRA mirror the ASF JIRA. That way you
>can triage as you please corporate style ;) in your internal JIRA and
>not let that spill over into the Apache JIRA which should be left to
>work community style. If a bug is assigned to someone on your internal
>JIRA, then that person will come and assign the bug to themselves in
>the community ASF JIRA when they have time to fix it. That, I think,
>works well for both the community and corporates invested in the
>project.
>
>HTH,
>
>On 11 April 2013 19:17, Noah Slater <ns...@apache.org> wrote:
>> I believe it is possible to "mention" someone in a JIRA ticket in such a
>> way that they get notified. Might this be an effective way of CCing
>>someone
>> into the conversation, without prescribing who should fix it? Might
>>there
>> be some room for exploration here?
>>
>>
>> On Thursday, 11 April 2013, Abhinandan Prateek wrote:
>>
>>> Yes, I think we need to space our releases further apart.
>>> I had big trouble when master was unstable for a while and specially on
>>> VMware it was difficult to deploy and test features. Yes for each
>>>issue I
>>> could have shouted on mail list I saw people doing that but the fact is
>>> that instability was around for a while. Doesn't it make sense that in
>>>such
>>> scenarios we could do things in a more pro active manner. Again I
>>>donot see
>>> much difference in asking someone on Jira to pick a issue vs sending a
>>> email, but will agree to whatever the community decides here.
>>>
>>> Also community members should volunteer to own some part so that in
>>>above
>>> circumstances a person looking for some fix can approach that member,
>>>once
>>> again a suggestion.
>>>
>>>
>>>
>>> On 11-Apr-2013, at 5:17 PM, "Noah Slater"
>>><nslater@apache.org<javascript:;>>
>>> wrote:
>>>
>>> > Of course releases are important.
>>> >
>>> > But if our current cadence is putting too much pressure on the
>>>community,
>>> > one option might be to do our releases further apart from each
>>>other. Or,
>>> > we get strict about the principal of time based releases: i.e. if
>>>your
>>> > feature is not ready for the freeze, then it doesn't make it in. No
>>>big
>>> > deal. If it's ready for the next freeze, then we'll ship it then.
>>> >
>>> > Also, I may be reading your message wrong, but there's no need for
>>>this
>>> to
>>> > be a divisive argument. There are no "sides" to this. As a
>>>community, it
>>> is
>>> > up to us all to identify our problems, and figure out solutions.
>>> >
>>> > So what problems do you think we'll run in to if we stop assigning
>>>the
>>> > majority of bugs, and how do you think we can mitigate those
>>>problems? Or
>>> > do you have another idea in mind altogether?
>>> >
>>> >
>>> >
>>> >
>>> > On 11 April 2013 12:40, Abhinandan Prateek <
>>> Abhinandan.Prateek@citrix.com <javascript:;>>wrote:
>>> >
>>> >> I think it will be good if we also find out a process so that the
>>> release
>>> >> cycle is not affected by unclaimed bugs sitting out there. Here I am
>>> >> assuming the releases are important.
>>> >>
>>> >> I guess the discussion has turned into keeping things free without
>>> >> offering solutions to problems that that system will create.
>>> >>
>>> >>
>>> >> On 11/04/13 5:04 PM, "John Burwell" <jburwell@basho.com
>>><javascript:;>>
>>> wrote:
>>> >>
>>> >>> +1
>>> >>>
>>> >>> On Apr 11, 2013, at 7:22 AM, Noah Slater
>>><nslater@apache.org<javascript:;>>
>>> wrote:
>>> >>>
>>> >>>> On 11 April 2013 11:22, Abhinandan Prateek
>>> >>>> <Abhinandan.Prateek@citrix.com <javascript:;>>wrote:
>>> >>>>
>>> >>>>>
>>> >>>>> 7-8 days is a huge time lost. I was suggesting that this to be 3
>>> days.
>>> >>>>> Let
>>> >>>>> other community members chime in too.
>>> >>>>
>>> >>>>
>>> >>>> I should have replied to this in my previous missive. But I want
>>>to
>>> >>>> reenforce how unhealthy I believe this practice is. 7-8 days, or
>>>even
>>> 3
>>> >>>> days "being a huge time loss" makes absolutely no sense to me at
>>>all.
>>> >>>> Assigning a bug should not mean it gets fixed any faster. If it
>>>does,
>>> >>>> then
>>> >>>> we need to change the way we are working. (And if this means
>>>changing
>>> >>>> the
>>> >>>> JIRA ticket workflow, then so be it. If something isn't working
>>>for
>>> us,
>>> >>>> we
>>> >>>> change it.)
>>> >>>>
>>> >>>> In fact, I would go so far as to say that we should think of
>>>assigning
>>> >>>> bugs
>>> >>>> as an exclusionary practice. Every time you assign a bug, you're
>>> >>>> shutting
>>> >>>> out the community. That's how we should think about it. Assign the
>>> bug,
>>> >>>> shut out the community. And so, I would say we should try to avoid
>>> doing
>>> >>>> it, unless it is absolutely necessary. (Such as when you're
>>> >>>> co-ordinating
>>> >>>> some release critical work, or when you, yourself, are about to
>>>start
>>> >>>> work
>>> >>>> on something. Of course, it's perfectly fine to shut out the
>>> community,
>>> >>>> if
>>> >>>> you're doing that at the same time as starting work on something!)
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> NS
>>> >
>>> >
>>> > --
>>> > NS
>>>
>>
>>
>> --
>> NS

Re: [DISCUSS] Don't assign tickets to people when triaging

[prasanna <ts...@apache.org>]

Abhi - not to gang up on you and I'm glad to see you share your
opinions, concerns about release management and such.

I see the problem you might be facing though. I think it would be
better to have your internal JIRA mirror the ASF JIRA. That way you
can triage as you please corporate style ;) in your internal JIRA and
not let that spill over into the Apache JIRA which should be left to
work community style. If a bug is assigned to someone on your internal
JIRA, then that person will come and assign the bug to themselves in
the community ASF JIRA when they have time to fix it. That, I think,
works well for both the community and corporates invested in the
project.

HTH,

On 11 April 2013 19:17, Noah Slater <ns...@apache.org> wrote:
> I believe it is possible to "mention" someone in a JIRA ticket in such a
> way that they get notified. Might this be an effective way of CCing someone
> into the conversation, without prescribing who should fix it? Might there
> be some room for exploration here?
>
>
> On Thursday, 11 April 2013, Abhinandan Prateek wrote:
>
>> Yes, I think we need to space our releases further apart.
>> I had big trouble when master was unstable for a while and specially on
>> VMware it was difficult to deploy and test features. Yes for each issue I
>> could have shouted on mail list I saw people doing that but the fact is
>> that instability was around for a while. Doesn't it make sense that in such
>> scenarios we could do things in a more pro active manner. Again I donot see
>> much difference in asking someone on Jira to pick a issue vs sending a
>> email, but will agree to whatever the community decides here.
>>
>> Also community members should volunteer to own some part so that in above
>> circumstances a person looking for some fix can approach that member, once
>> again a suggestion.
>>
>>
>>
>> On 11-Apr-2013, at 5:17 PM, "Noah Slater" <nslater@apache.org<javascript:;>>
>> wrote:
>>
>> > Of course releases are important.
>> >
>> > But if our current cadence is putting too much pressure on the community,
>> > one option might be to do our releases further apart from each other. Or,
>> > we get strict about the principal of time based releases: i.e. if your
>> > feature is not ready for the freeze, then it doesn't make it in. No big
>> > deal. If it's ready for the next freeze, then we'll ship it then.
>> >
>> > Also, I may be reading your message wrong, but there's no need for this
>> to
>> > be a divisive argument. There are no "sides" to this. As a community, it
>> is
>> > up to us all to identify our problems, and figure out solutions.
>> >
>> > So what problems do you think we'll run in to if we stop assigning the
>> > majority of bugs, and how do you think we can mitigate those problems? Or
>> > do you have another idea in mind altogether?
>> >
>> >
>> >
>> >
>> > On 11 April 2013 12:40, Abhinandan Prateek <
>> Abhinandan.Prateek@citrix.com <javascript:;>>wrote:
>> >
>> >> I think it will be good if we also find out a process so that the
>> release
>> >> cycle is not affected by unclaimed bugs sitting out there. Here I am
>> >> assuming the releases are important.
>> >>
>> >> I guess the discussion has turned into keeping things free without
>> >> offering solutions to problems that that system will create.
>> >>
>> >>
>> >> On 11/04/13 5:04 PM, "John Burwell" <jburwell@basho.com <javascript:;>>
>> wrote:
>> >>
>> >>> +1
>> >>>
>> >>> On Apr 11, 2013, at 7:22 AM, Noah Slater <nslater@apache.org<javascript:;>>
>> wrote:
>> >>>
>> >>>> On 11 April 2013 11:22, Abhinandan Prateek
>> >>>> <Abhinandan.Prateek@citrix.com <javascript:;>>wrote:
>> >>>>
>> >>>>>
>> >>>>> 7-8 days is a huge time lost. I was suggesting that this to be 3
>> days.
>> >>>>> Let
>> >>>>> other community members chime in too.
>> >>>>
>> >>>>
>> >>>> I should have replied to this in my previous missive. But I want to
>> >>>> reenforce how unhealthy I believe this practice is. 7-8 days, or even
>> 3
>> >>>> days "being a huge time loss" makes absolutely no sense to me at all.
>> >>>> Assigning a bug should not mean it gets fixed any faster. If it does,
>> >>>> then
>> >>>> we need to change the way we are working. (And if this means changing
>> >>>> the
>> >>>> JIRA ticket workflow, then so be it. If something isn't working for
>> us,
>> >>>> we
>> >>>> change it.)
>> >>>>
>> >>>> In fact, I would go so far as to say that we should think of assigning
>> >>>> bugs
>> >>>> as an exclusionary practice. Every time you assign a bug, you're
>> >>>> shutting
>> >>>> out the community. That's how we should think about it. Assign the
>> bug,
>> >>>> shut out the community. And so, I would say we should try to avoid
>> doing
>> >>>> it, unless it is absolutely necessary. (Such as when you're
>> >>>> co-ordinating
>> >>>> some release critical work, or when you, yourself, are about to start
>> >>>> work
>> >>>> on something. Of course, it's perfectly fine to shut out the
>> community,
>> >>>> if
>> >>>> you're doing that at the same time as starting work on something!)
>> >>>>
>> >>>>
>> >>>> --
>> >>>> NS
>> >
>> >
>> > --
>> > NS
>>
>
>
> --
> NS

Re: [DISCUSS] Don't assign tickets to people when triaging

[Abhinandan Prateek <Ab...@citrix.com>]

On the Jira notification my suggestion will be to have a goto list of
people for various domains of expertise. Anyone can register for these
domains. When a bug is filed, the filer selects one of the domains he
thinks that is right for getting the bug to be resolved. This alerts the
people who have volunteered for that domain. We may take this one step
future in that for each domain we can have a designated contact person who
may once in a while take a look at the list of open issues in that domain
and may further take action for quicker resolution.

I think I had enough inputs for the day :-), Moreover the day is ending in
my timezone.
I guess that did bring some issues to the notice of community, I will
expect other community members to think of solutions.
With so many passionate members in this community I think we will arrive
at a good solution that works.


Kudos to the community !


On 11/04/13 7:17 PM, "Noah Slater" <ns...@apache.org> wrote:

>I believe it is possible to "mention" someone in a JIRA ticket in such a
>way that they get notified. Might this be an effective way of CCing
>someone
>into the conversation, without prescribing who should fix it? Might there
>be some room for exploration here?
>
>
>On Thursday, 11 April 2013, Abhinandan Prateek wrote:
>
>> Yes, I think we need to space our releases further apart.
>> I had big trouble when master was unstable for a while and specially on
>> VMware it was difficult to deploy and test features. Yes for each issue
>>I
>> could have shouted on mail list I saw people doing that but the fact is
>> that instability was around for a while. Doesn't it make sense that in
>>such
>> scenarios we could do things in a more pro active manner. Again I donot
>>see
>> much difference in asking someone on Jira to pick a issue vs sending a
>> email, but will agree to whatever the community decides here.
>>
>> Also community members should volunteer to own some part so that in
>>above
>> circumstances a person looking for some fix can approach that member,
>>once
>> again a suggestion.
>>
>>
>>
>> On 11-Apr-2013, at 5:17 PM, "Noah Slater"
>><nslater@apache.org<javascript:;>>
>> wrote:
>>
>> > Of course releases are important.
>> >
>> > But if our current cadence is putting too much pressure on the
>>community,
>> > one option might be to do our releases further apart from each other.
>>Or,
>> > we get strict about the principal of time based releases: i.e. if your
>> > feature is not ready for the freeze, then it doesn't make it in. No
>>big
>> > deal. If it's ready for the next freeze, then we'll ship it then.
>> >
>> > Also, I may be reading your message wrong, but there's no need for
>>this
>> to
>> > be a divisive argument. There are no "sides" to this. As a community,
>>it
>> is
>> > up to us all to identify our problems, and figure out solutions.
>> >
>> > So what problems do you think we'll run in to if we stop assigning the
>> > majority of bugs, and how do you think we can mitigate those
>>problems? Or
>> > do you have another idea in mind altogether?
>> >
>> >
>> >
>> >
>> > On 11 April 2013 12:40, Abhinandan Prateek <
>> Abhinandan.Prateek@citrix.com <javascript:;>>wrote:
>> >
>> >> I think it will be good if we also find out a process so that the
>> release
>> >> cycle is not affected by unclaimed bugs sitting out there. Here I am
>> >> assuming the releases are important.
>> >>
>> >> I guess the discussion has turned into keeping things free without
>> >> offering solutions to problems that that system will create.
>> >>
>> >>
>> >> On 11/04/13 5:04 PM, "John Burwell" <jburwell@basho.com
>><javascript:;>>
>> wrote:
>> >>
>> >>> +1
>> >>>
>> >>> On Apr 11, 2013, at 7:22 AM, Noah Slater
>><nslater@apache.org<javascript:;>>
>> wrote:
>> >>>
>> >>>> On 11 April 2013 11:22, Abhinandan Prateek
>> >>>> <Abhinandan.Prateek@citrix.com <javascript:;>>wrote:
>> >>>>
>> >>>>>
>> >>>>> 7-8 days is a huge time lost. I was suggesting that this to be 3
>> days.
>> >>>>> Let
>> >>>>> other community members chime in too.
>> >>>>
>> >>>>
>> >>>> I should have replied to this in my previous missive. But I want to
>> >>>> reenforce how unhealthy I believe this practice is. 7-8 days, or
>>even
>> 3
>> >>>> days "being a huge time loss" makes absolutely no sense to me at
>>all.
>> >>>> Assigning a bug should not mean it gets fixed any faster. If it
>>does,
>> >>>> then
>> >>>> we need to change the way we are working. (And if this means
>>changing
>> >>>> the
>> >>>> JIRA ticket workflow, then so be it. If something isn't working for
>> us,
>> >>>> we
>> >>>> change it.)
>> >>>>
>> >>>> In fact, I would go so far as to say that we should think of
>>assigning
>> >>>> bugs
>> >>>> as an exclusionary practice. Every time you assign a bug, you're
>> >>>> shutting
>> >>>> out the community. That's how we should think about it. Assign the
>> bug,
>> >>>> shut out the community. And so, I would say we should try to avoid
>> doing
>> >>>> it, unless it is absolutely necessary. (Such as when you're
>> >>>> co-ordinating
>> >>>> some release critical work, or when you, yourself, are about to
>>start
>> >>>> work
>> >>>> on something. Of course, it's perfectly fine to shut out the
>> community,
>> >>>> if
>> >>>> you're doing that at the same time as starting work on something!)
>> >>>>
>> >>>>
>> >>>> --
>> >>>> NS
>> >
>> >
>> > --
>> > NS
>>
>
>
>-- 
>NS

Re: [DISCUSS] Don't assign tickets to people when triaging

[Noah Slater <ns...@apache.org>]

I believe it is possible to "mention" someone in a JIRA ticket in such a
way that they get notified. Might this be an effective way of CCing someone
into the conversation, without prescribing who should fix it? Might there
be some room for exploration here?


On Thursday, 11 April 2013, Abhinandan Prateek wrote:

> Yes, I think we need to space our releases further apart.
> I had big trouble when master was unstable for a while and specially on
> VMware it was difficult to deploy and test features. Yes for each issue I
> could have shouted on mail list I saw people doing that but the fact is
> that instability was around for a while. Doesn't it make sense that in such
> scenarios we could do things in a more pro active manner. Again I donot see
> much difference in asking someone on Jira to pick a issue vs sending a
> email, but will agree to whatever the community decides here.
>
> Also community members should volunteer to own some part so that in above
> circumstances a person looking for some fix can approach that member, once
> again a suggestion.
>
>
>
> On 11-Apr-2013, at 5:17 PM, "Noah Slater" <nslater@apache.org<javascript:;>>
> wrote:
>
> > Of course releases are important.
> >
> > But if our current cadence is putting too much pressure on the community,
> > one option might be to do our releases further apart from each other. Or,
> > we get strict about the principal of time based releases: i.e. if your
> > feature is not ready for the freeze, then it doesn't make it in. No big
> > deal. If it's ready for the next freeze, then we'll ship it then.
> >
> > Also, I may be reading your message wrong, but there's no need for this
> to
> > be a divisive argument. There are no "sides" to this. As a community, it
> is
> > up to us all to identify our problems, and figure out solutions.
> >
> > So what problems do you think we'll run in to if we stop assigning the
> > majority of bugs, and how do you think we can mitigate those problems? Or
> > do you have another idea in mind altogether?
> >
> >
> >
> >
> > On 11 April 2013 12:40, Abhinandan Prateek <
> Abhinandan.Prateek@citrix.com <javascript:;>>wrote:
> >
> >> I think it will be good if we also find out a process so that the
> release
> >> cycle is not affected by unclaimed bugs sitting out there. Here I am
> >> assuming the releases are important.
> >>
> >> I guess the discussion has turned into keeping things free without
> >> offering solutions to problems that that system will create.
> >>
> >>
> >> On 11/04/13 5:04 PM, "John Burwell" <jburwell@basho.com <javascript:;>>
> wrote:
> >>
> >>> +1
> >>>
> >>> On Apr 11, 2013, at 7:22 AM, Noah Slater <nslater@apache.org<javascript:;>>
> wrote:
> >>>
> >>>> On 11 April 2013 11:22, Abhinandan Prateek
> >>>> <Abhinandan.Prateek@citrix.com <javascript:;>>wrote:
> >>>>
> >>>>>
> >>>>> 7-8 days is a huge time lost. I was suggesting that this to be 3
> days.
> >>>>> Let
> >>>>> other community members chime in too.
> >>>>
> >>>>
> >>>> I should have replied to this in my previous missive. But I want to
> >>>> reenforce how unhealthy I believe this practice is. 7-8 days, or even
> 3
> >>>> days "being a huge time loss" makes absolutely no sense to me at all.
> >>>> Assigning a bug should not mean it gets fixed any faster. If it does,
> >>>> then
> >>>> we need to change the way we are working. (And if this means changing
> >>>> the
> >>>> JIRA ticket workflow, then so be it. If something isn't working for
> us,
> >>>> we
> >>>> change it.)
> >>>>
> >>>> In fact, I would go so far as to say that we should think of assigning
> >>>> bugs
> >>>> as an exclusionary practice. Every time you assign a bug, you're
> >>>> shutting
> >>>> out the community. That's how we should think about it. Assign the
> bug,
> >>>> shut out the community. And so, I would say we should try to avoid
> doing
> >>>> it, unless it is absolutely necessary. (Such as when you're
> >>>> co-ordinating
> >>>> some release critical work, or when you, yourself, are about to start
> >>>> work
> >>>> on something. Of course, it's perfectly fine to shut out the
> community,
> >>>> if
> >>>> you're doing that at the same time as starting work on something!)
> >>>>
> >>>>
> >>>> --
> >>>> NS
> >
> >
> > --
> > NS
>


-- 
NS

Re: [DISCUSS] Don't assign tickets to people when triaging

[Rohit Yadav <bh...@apache.org>]

On Thu, Apr 11, 2013 at 8:09 PM, Chip Childers <ch...@sungard.com>wrote:

> On Thu, Apr 11, 2013 at 12:51:34PM +0000, Abhinandan Prateek wrote:
> > Yes, I think we need to space our releases further apart.
>
> That's a different discussion, which you are free to raise if you'd like.
>
> > Also community members should volunteer to own some part so that in
> above circumstances a person looking for some fix can approach that member,
> once again a suggestion.
>
> I've been reading through this thread, and I'll pick the "owner" comment
> above as a starting point for my personal opinions.  This is a reaction
> to the whole thread really, so take a minute to read to the end please.
>
> "Owning some part" is antithetical to a healthy community approach.
> Certainly people will gravitate to certain areas, and by all means
> everyone should feel free to work on areas of the code-base that they
> feel like they want to improve or support.  This may lead to people
> effectively being the primary "do-er" for certain areas (examples: Wido
> has been working on DEB packaging, Rohit has been working on
> CloudMonkey), but we shouldn't ever consider this ownership. I feel
> personally welcome to make a change in CloudMonkey, and would certainly
> consider it important to collaborate with anyone (especially Rohit) that
> may have input and insights.
>

Super duper +1.

I see the *feature owner/maintainer* only as person of interest around that
area and encourage contributions in whatever way and any area.

Instead of labelling things as mine or yours, being in community means we
own the whole CloudStack it as a team. So, for example I preferred to write
author as "The Apache CloudStack Team" [1] but name myself as the current
maintainer for the CLI as I've interest around that area and would like to
participate/help review/checkin any feedback/contributions and everyone is
welcome to administrate the pypi channel [1].

[1] https://pypi.python.org/pypi/cloudmonkey/4.1.0-snapshot

Cheers.
You should listen to Chip, read http://www.producingoss.com and follow his
tweets when he shares such awesome stuff ;)




> The idea of ownership if a part of the software is something I'm strongly
> against.
>
> Even the idea of maintainers seems like it is problematic in
> implementation.  How do we decide who the "official" maintainer is?  How
> do we decide when someone else should do that... And frankly, doesn't a
> "maintainer" model really discourage others from working in named areas?
>
> All of these attempts to structure the community appear to be natural
> responses when you have a background in corporate development (product
> or otherwise), which is my background as well.  It doesn't work here,
> and you have to fight the urge to apply the same solutions (WRT
> structure and process) in this environment.  If you haven't read
> "Producing OSS" [1], go do that.
>
> What we really need is for those individuals that are interested in
> participating in this community to actively participate.  Read the ML,
> take on bugs, focus on the shared community release goals.  If you
> consider yourself interested in this project, then don't wait for
> assignments from someone else.  Watch the lists, notice areas where you
> can help, discuss if you disagree with proposed community goals as they
> are being formed.
>
> Personal responsibility and interest in contributing to the shared
> community goals is what we should all expect of each other. We should
> not expect that others in the community will spoon feed tasks out. If
> that happens within someone's $dayjob, that's not a community concern.
>
> You'll notice that I have rarely "assigned" a bug.  In a couple of
> instances, I've pushed something to someone that I know is *actively*
> working in an area of the code.  I've also assigned a bug as purely an
> administrative step, when I know someone is already working on the issue,
> but may not have had the time to assign the bug to themselves.  Release
> blockers that I don't easily associated with some ongoing and known work
> are highlighted in emails, with a request for someone to grab them.
>
> Releases are the shared goals of the community, but building a strong
> community is more important than any specific release.  That's why this
> conversation started really.
>
> So yes, I want blockers to be addressed.  Yes, I want us to get our
> releases out.  Yes, I'd like us to be close to our proposed schedules.
> No, I'm not willing to have a release take priority over the more
> important goal of building a stronger and stronger community.
>
> -chip
>
> [1] http://www.producingoss.com/
>

RE: [DISCUSS] Don't assign tickets to people when triaging

[Animesh Chaturvedi <an...@citrix.com>]

> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Thursday, April 11, 2013 7:40 AM
> To: <de...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] Don't assign tickets to people when triaging
> 
> On Thu, Apr 11, 2013 at 12:51:34PM +0000, Abhinandan Prateek wrote:
> > Yes, I think we need to space our releases further apart.
> 
> That's a different discussion, which you are free to raise if you'd like.
> 
> > Also community members should volunteer to own some part so that in
> above circumstances a person looking for some fix can approach that
> member, once again a suggestion.
> 
> I've been reading through this thread, and I'll pick the "owner" comment
> above as a starting point for my personal opinions.  This is a reaction to the
> whole thread really, so take a minute to read to the end please.
> 
> "Owning some part" is antithetical to a healthy community approach.
> Certainly people will gravitate to certain areas, and by all means everyone
> should feel free to work on areas of the code-base that they feel like they
> want to improve or support.  This may lead to people effectively being the
> primary "do-er" for certain areas (examples: Wido has been working on DEB
> packaging, Rohit has been working on CloudMonkey), but we shouldn't ever
> consider this ownership. I feel personally welcome to make a change in
> CloudMonkey, and would certainly consider it important to collaborate with
> anyone (especially Rohit) that may have input and insights.
> 
> The idea of ownership if a part of the software is something I'm strongly
> against.
> 
> Even the idea of maintainers seems like it is problematic in implementation.
> How do we decide who the "official" maintainer is?  How do we decide when
> someone else should do that... And frankly, doesn't a "maintainer" model
> really discourage others from working in named areas?
> 
 [Animesh>] +1,  that is the reason Apache projects do not use @author tag. I take back my original argument of auto-assigning based on maintainers list. I did a search but did not find any community using auto-assignment. The community argument  wins.

> All of these attempts to structure the community appear to be natural
> responses when you have a background in corporate development (product
> or otherwise), which is my background as well.  It doesn't work here, and you
> have to fight the urge to apply the same solutions (WRT structure and
> process) in this environment.  If you haven't read "Producing OSS" [1], go do
> that.
> 
> What we really need is for those individuals that are interested in
> participating in this community to actively participate.  Read the ML, take on
> bugs, focus on the shared community release goals.  If you consider yourself
> interested in this project, then don't wait for assignments from someone
> else.  Watch the lists, notice areas where you can help, discuss if you disagree
> with proposed community goals as they are being formed.
> 
> Personal responsibility and interest in contributing to the shared community
> goals is what we should all expect of each other. We should not expect that
> others in the community will spoon feed tasks out. If that happens within
> someone's $dayjob, that's not a community concern.
> 
> You'll notice that I have rarely "assigned" a bug.  In a couple of instances, I've
> pushed something to someone that I know is *actively* working in an area of
> the code.  I've also assigned a bug as purely an administrative step, when I
> know someone is already working on the issue, but may not have had the
> time to assign the bug to themselves.  Release blockers that I don't easily
> associated with some ongoing and known work are highlighted in emails,
> with a request for someone to grab them.
> 
> Releases are the shared goals of the community, but building a strong
> community is more important than any specific release.  That's why this
> conversation started really.
> 
> So yes, I want blockers to be addressed.  Yes, I want us to get our releases
> out.  Yes, I'd like us to be close to our proposed schedules.
> No, I'm not willing to have a release take priority over the more important
> goal of building a stronger and stronger community.
> 
[Animesh>] +1 I have read [1] cover to cover a few times already but looks like it is taking in longer to sink in but I think I will get there.

> -chip
> 
> [1] http://www.producingoss.com/

Re: [DISCUSS] Don't assign tickets to people when triaging

[prasanna <ts...@apache.org>]

On 11 April 2013 20:09, Chip Childers <ch...@sungard.com> wrote:
> On Thu, Apr 11, 2013 at 12:51:34PM +0000, Abhinandan Prateek wrote:
>> Yes, I think we need to space our releases further apart.
>
> That's a different discussion, which you are free to raise if you'd like.
>
>> Also community members should volunteer to own some part so that in above circumstances a person looking for some fix can approach that member, once again a suggestion.
>
> I've been reading through this thread, and I'll pick the "owner" comment
> above as a starting point for my personal opinions.  This is a reaction
> to the whole thread really, so take a minute to read to the end please.
>
> "Owning some part" is antithetical to a healthy community approach.
> Certainly people will gravitate to certain areas, and by all means
> everyone should feel free to work on areas of the code-base that they
> feel like they want to improve or support.  This may lead to people
> effectively being the primary "do-er" for certain areas (examples: Wido
> has been working on DEB packaging, Rohit has been working on
> CloudMonkey), but we shouldn't ever consider this ownership. I feel
> personally welcome to make a change in CloudMonkey, and would certainly
> consider it important to collaborate with anyone (especially Rohit) that
> may have input and insights.
>
> The idea of ownership if a part of the software is something I'm strongly
> against.
>
> Even the idea of maintainers seems like it is problematic in
> implementation.  How do we decide who the "official" maintainer is?  How
> do we decide when someone else should do that... And frankly, doesn't a
> "maintainer" model really discourage others from working in named areas?
>
> All of these attempts to structure the community appear to be natural
> responses when you have a background in corporate development (product
> or otherwise), which is my background as well.  It doesn't work here,
> and you have to fight the urge to apply the same solutions (WRT
> structure and process) in this environment.  If you haven't read
> "Producing OSS" [1], go do that.
>

And if you don't have the patience, here's the appropriate extract:
http://www.producingoss.com/en/managing-volunteers.html#delegation-assignment

Re: [DISCUSS] Don't assign tickets to people when triaging

[Noah Slater <ns...@apache.org>]

+1


On 11 April 2013 15:39, Chip Childers <ch...@sungard.com> wrote:

> On Thu, Apr 11, 2013 at 12:51:34PM +0000, Abhinandan Prateek wrote:
> > Yes, I think we need to space our releases further apart.
>
> That's a different discussion, which you are free to raise if you'd like.
>
> > Also community members should volunteer to own some part so that in
> above circumstances a person looking for some fix can approach that member,
> once again a suggestion.
>
> I've been reading through this thread, and I'll pick the "owner" comment
> above as a starting point for my personal opinions.  This is a reaction
> to the whole thread really, so take a minute to read to the end please.
>
> "Owning some part" is antithetical to a healthy community approach.
> Certainly people will gravitate to certain areas, and by all means
> everyone should feel free to work on areas of the code-base that they
> feel like they want to improve or support.  This may lead to people
> effectively being the primary "do-er" for certain areas (examples: Wido
> has been working on DEB packaging, Rohit has been working on
> CloudMonkey), but we shouldn't ever consider this ownership. I feel
> personally welcome to make a change in CloudMonkey, and would certainly
> consider it important to collaborate with anyone (especially Rohit) that
> may have input and insights.
>
> The idea of ownership if a part of the software is something I'm strongly
> against.
>
> Even the idea of maintainers seems like it is problematic in
> implementation.  How do we decide who the "official" maintainer is?  How
> do we decide when someone else should do that... And frankly, doesn't a
> "maintainer" model really discourage others from working in named areas?
>
> All of these attempts to structure the community appear to be natural
> responses when you have a background in corporate development (product
> or otherwise), which is my background as well.  It doesn't work here,
> and you have to fight the urge to apply the same solutions (WRT
> structure and process) in this environment.  If you haven't read
> "Producing OSS" [1], go do that.
>
> What we really need is for those individuals that are interested in
> participating in this community to actively participate.  Read the ML,
> take on bugs, focus on the shared community release goals.  If you
> consider yourself interested in this project, then don't wait for
> assignments from someone else.  Watch the lists, notice areas where you
> can help, discuss if you disagree with proposed community goals as they
> are being formed.
>
> Personal responsibility and interest in contributing to the shared
> community goals is what we should all expect of each other. We should
> not expect that others in the community will spoon feed tasks out. If
> that happens within someone's $dayjob, that's not a community concern.
>
> You'll notice that I have rarely "assigned" a bug.  In a couple of
> instances, I've pushed something to someone that I know is *actively*
> working in an area of the code.  I've also assigned a bug as purely an
> administrative step, when I know someone is already working on the issue,
> but may not have had the time to assign the bug to themselves.  Release
> blockers that I don't easily associated with some ongoing and known work
> are highlighted in emails, with a request for someone to grab them.
>
> Releases are the shared goals of the community, but building a strong
> community is more important than any specific release.  That's why this
> conversation started really.
>
> So yes, I want blockers to be addressed.  Yes, I want us to get our
> releases out.  Yes, I'd like us to be close to our proposed schedules.
> No, I'm not willing to have a release take priority over the more
> important goal of building a stronger and stronger community.
>
> -chip
>
> [1] http://www.producingoss.com/
>



-- 
NS

Re: [DISCUSS] Don't assign tickets to people when triaging

[Chip Childers <ch...@sungard.com>]

On Thu, Apr 11, 2013 at 12:51:34PM +0000, Abhinandan Prateek wrote:
> Yes, I think we need to space our releases further apart.

That's a different discussion, which you are free to raise if you'd like.

> Also community members should volunteer to own some part so that in above circumstances a person looking for some fix can approach that member, once again a suggestion.

I've been reading through this thread, and I'll pick the "owner" comment
above as a starting point for my personal opinions.  This is a reaction
to the whole thread really, so take a minute to read to the end please.

"Owning some part" is antithetical to a healthy community approach.
Certainly people will gravitate to certain areas, and by all means
everyone should feel free to work on areas of the code-base that they
feel like they want to improve or support.  This may lead to people
effectively being the primary "do-er" for certain areas (examples: Wido
has been working on DEB packaging, Rohit has been working on
CloudMonkey), but we shouldn't ever consider this ownership. I feel
personally welcome to make a change in CloudMonkey, and would certainly
consider it important to collaborate with anyone (especially Rohit) that
may have input and insights.

The idea of ownership if a part of the software is something I'm strongly
against.

Even the idea of maintainers seems like it is problematic in
implementation.  How do we decide who the "official" maintainer is?  How
do we decide when someone else should do that... And frankly, doesn't a
"maintainer" model really discourage others from working in named areas?

All of these attempts to structure the community appear to be natural
responses when you have a background in corporate development (product
or otherwise), which is my background as well.  It doesn't work here,
and you have to fight the urge to apply the same solutions (WRT
structure and process) in this environment.  If you haven't read
"Producing OSS" [1], go do that.

What we really need is for those individuals that are interested in
participating in this community to actively participate.  Read the ML,
take on bugs, focus on the shared community release goals.  If you
consider yourself interested in this project, then don't wait for
assignments from someone else.  Watch the lists, notice areas where you
can help, discuss if you disagree with proposed community goals as they
are being formed.

Personal responsibility and interest in contributing to the shared
community goals is what we should all expect of each other. We should
not expect that others in the community will spoon feed tasks out. If
that happens within someone's $dayjob, that's not a community concern.

You'll notice that I have rarely "assigned" a bug.  In a couple of
instances, I've pushed something to someone that I know is *actively*
working in an area of the code.  I've also assigned a bug as purely an
administrative step, when I know someone is already working on the issue,
but may not have had the time to assign the bug to themselves.  Release
blockers that I don't easily associated with some ongoing and known work
are highlighted in emails, with a request for someone to grab them.

Releases are the shared goals of the community, but building a strong
community is more important than any specific release.  That's why this
conversation started really.

So yes, I want blockers to be addressed.  Yes, I want us to get our
releases out.  Yes, I'd like us to be close to our proposed schedules.
No, I'm not willing to have a release take priority over the more
important goal of building a stronger and stronger community.

-chip

[1] http://www.producingoss.com/

Re: [DISCUSS] Don't assign tickets to people when triaging

[Abhinandan Prateek <Ab...@citrix.com>]

Yes, I think we need to space our releases further apart.
I had big trouble when master was unstable for a while and specially on VMware it was difficult to deploy and test features. Yes for each issue I could have shouted on mail list I saw people doing that but the fact is that instability was around for a while. Doesn't it make sense that in such scenarios we could do things in a more pro active manner. Again I donot see much difference in asking someone on Jira to pick a issue vs sending a email, but will agree to whatever the community decides here.

Also community members should volunteer to own some part so that in above circumstances a person looking for some fix can approach that member, once again a suggestion.



On 11-Apr-2013, at 5:17 PM, "Noah Slater" <ns...@apache.org> wrote:

> Of course releases are important.
> 
> But if our current cadence is putting too much pressure on the community,
> one option might be to do our releases further apart from each other. Or,
> we get strict about the principal of time based releases: i.e. if your
> feature is not ready for the freeze, then it doesn't make it in. No big
> deal. If it's ready for the next freeze, then we'll ship it then.
> 
> Also, I may be reading your message wrong, but there's no need for this to
> be a divisive argument. There are no "sides" to this. As a community, it is
> up to us all to identify our problems, and figure out solutions.
> 
> So what problems do you think we'll run in to if we stop assigning the
> majority of bugs, and how do you think we can mitigate those problems? Or
> do you have another idea in mind altogether?
> 
> 
> 
> 
> On 11 April 2013 12:40, Abhinandan Prateek <Ab...@citrix.com>wrote:
> 
>> I think it will be good if we also find out a process so that the release
>> cycle is not affected by unclaimed bugs sitting out there. Here I am
>> assuming the releases are important.
>> 
>> I guess the discussion has turned into keeping things free without
>> offering solutions to problems that that system will create.
>> 
>> 
>> On 11/04/13 5:04 PM, "John Burwell" <jb...@basho.com> wrote:
>> 
>>> +1
>>> 
>>> On Apr 11, 2013, at 7:22 AM, Noah Slater <ns...@apache.org> wrote:
>>> 
>>>> On 11 April 2013 11:22, Abhinandan Prateek
>>>> <Ab...@citrix.com>wrote:
>>>> 
>>>>> 
>>>>> 7-8 days is a huge time lost. I was suggesting that this to be 3 days.
>>>>> Let
>>>>> other community members chime in too.
>>>> 
>>>> 
>>>> I should have replied to this in my previous missive. But I want to
>>>> reenforce how unhealthy I believe this practice is. 7-8 days, or even 3
>>>> days "being a huge time loss" makes absolutely no sense to me at all.
>>>> Assigning a bug should not mean it gets fixed any faster. If it does,
>>>> then
>>>> we need to change the way we are working. (And if this means changing
>>>> the
>>>> JIRA ticket workflow, then so be it. If something isn't working for us,
>>>> we
>>>> change it.)
>>>> 
>>>> In fact, I would go so far as to say that we should think of assigning
>>>> bugs
>>>> as an exclusionary practice. Every time you assign a bug, you're
>>>> shutting
>>>> out the community. That's how we should think about it. Assign the bug,
>>>> shut out the community. And so, I would say we should try to avoid doing
>>>> it, unless it is absolutely necessary. (Such as when you're
>>>> co-ordinating
>>>> some release critical work, or when you, yourself, are about to start
>>>> work
>>>> on something. Of course, it's perfectly fine to shut out the community,
>>>> if
>>>> you're doing that at the same time as starting work on something!)
>>>> 
>>>> 
>>>> --
>>>> NS
> 
> 
> -- 
> NS

Re: [DISCUSS] Don't assign tickets to people when triaging

[Noah Slater <ns...@apache.org>]

Of course releases are important.

But if our current cadence is putting too much pressure on the community,
one option might be to do our releases further apart from each other. Or,
we get strict about the principal of time based releases: i.e. if your
feature is not ready for the freeze, then it doesn't make it in. No big
deal. If it's ready for the next freeze, then we'll ship it then.

Also, I may be reading your message wrong, but there's no need for this to
be a divisive argument. There are no "sides" to this. As a community, it is
up to us all to identify our problems, and figure out solutions.

So what problems do you think we'll run in to if we stop assigning the
majority of bugs, and how do you think we can mitigate those problems? Or
do you have another idea in mind altogether?




On 11 April 2013 12:40, Abhinandan Prateek <Ab...@citrix.com>wrote:

> I think it will be good if we also find out a process so that the release
> cycle is not affected by unclaimed bugs sitting out there. Here I am
> assuming the releases are important.
>
> I guess the discussion has turned into keeping things free without
> offering solutions to problems that that system will create.
>
>
> On 11/04/13 5:04 PM, "John Burwell" <jb...@basho.com> wrote:
>
> >+1
> >
> >On Apr 11, 2013, at 7:22 AM, Noah Slater <ns...@apache.org> wrote:
> >
> >> On 11 April 2013 11:22, Abhinandan Prateek
> >><Ab...@citrix.com>wrote:
> >>
> >>>
> >>> 7-8 days is a huge time lost. I was suggesting that this to be 3 days.
> >>>Let
> >>> other community members chime in too.
> >>
> >>
> >> I should have replied to this in my previous missive. But I want to
> >> reenforce how unhealthy I believe this practice is. 7-8 days, or even 3
> >> days "being a huge time loss" makes absolutely no sense to me at all.
> >> Assigning a bug should not mean it gets fixed any faster. If it does,
> >>then
> >> we need to change the way we are working. (And if this means changing
> >>the
> >> JIRA ticket workflow, then so be it. If something isn't working for us,
> >>we
> >> change it.)
> >>
> >> In fact, I would go so far as to say that we should think of assigning
> >>bugs
> >> as an exclusionary practice. Every time you assign a bug, you're
> >>shutting
> >> out the community. That's how we should think about it. Assign the bug,
> >> shut out the community. And so, I would say we should try to avoid doing
> >> it, unless it is absolutely necessary. (Such as when you're
> >>co-ordinating
> >> some release critical work, or when you, yourself, are about to start
> >>work
> >> on something. Of course, it's perfectly fine to shut out the community,
> >>if
> >> you're doing that at the same time as starting work on something!)
> >>
> >>
> >> --
> >> NS
> >
>
>


-- 
NS

Re: [DISCUSS] Don't assign tickets to people when triaging

[Abhinandan Prateek <Ab...@citrix.com>]

I think it will be good if we also find out a process so that the release
cycle is not affected by unclaimed bugs sitting out there. Here I am
assuming the releases are important.

I guess the discussion has turned into keeping things free without
offering solutions to problems that that system will create.


On 11/04/13 5:04 PM, "John Burwell" <jb...@basho.com> wrote:

>+1
>
>On Apr 11, 2013, at 7:22 AM, Noah Slater <ns...@apache.org> wrote:
>
>> On 11 April 2013 11:22, Abhinandan Prateek
>><Ab...@citrix.com>wrote:
>> 
>>> 
>>> 7-8 days is a huge time lost. I was suggesting that this to be 3 days.
>>>Let
>>> other community members chime in too.
>> 
>> 
>> I should have replied to this in my previous missive. But I want to
>> reenforce how unhealthy I believe this practice is. 7-8 days, or even 3
>> days "being a huge time loss" makes absolutely no sense to me at all.
>> Assigning a bug should not mean it gets fixed any faster. If it does,
>>then
>> we need to change the way we are working. (And if this means changing
>>the
>> JIRA ticket workflow, then so be it. If something isn't working for us,
>>we
>> change it.)
>> 
>> In fact, I would go so far as to say that we should think of assigning
>>bugs
>> as an exclusionary practice. Every time you assign a bug, you're
>>shutting
>> out the community. That's how we should think about it. Assign the bug,
>> shut out the community. And so, I would say we should try to avoid doing
>> it, unless it is absolutely necessary. (Such as when you're
>>co-ordinating
>> some release critical work, or when you, yourself, are about to start
>>work
>> on something. Of course, it's perfectly fine to shut out the community,
>>if
>> you're doing that at the same time as starting work on something!)
>> 
>> 
>> -- 
>> NS
>

Re: [DISCUSS] Don't assign tickets to people when triaging

[John Burwell <jb...@basho.com>]

+1

On Apr 11, 2013, at 7:22 AM, Noah Slater <ns...@apache.org> wrote:

> On 11 April 2013 11:22, Abhinandan Prateek <Ab...@citrix.com>wrote:
> 
>> 
>> 7-8 days is a huge time lost. I was suggesting that this to be 3 days. Let
>> other community members chime in too.
> 
> 
> I should have replied to this in my previous missive. But I want to
> reenforce how unhealthy I believe this practice is. 7-8 days, or even 3
> days "being a huge time loss" makes absolutely no sense to me at all.
> Assigning a bug should not mean it gets fixed any faster. If it does, then
> we need to change the way we are working. (And if this means changing the
> JIRA ticket workflow, then so be it. If something isn't working for us, we
> change it.)
> 
> In fact, I would go so far as to say that we should think of assigning bugs
> as an exclusionary practice. Every time you assign a bug, you're shutting
> out the community. That's how we should think about it. Assign the bug,
> shut out the community. And so, I would say we should try to avoid doing
> it, unless it is absolutely necessary. (Such as when you're co-ordinating
> some release critical work, or when you, yourself, are about to start work
> on something. Of course, it's perfectly fine to shut out the community, if
> you're doing that at the same time as starting work on something!)
> 
> 
> -- 
> NS

Re: [DISCUSS] Don't assign tickets to people when triaging

[Noah Slater <ns...@apache.org>]

On 11 April 2013 11:22, Abhinandan Prateek <Ab...@citrix.com>wrote:

>
> 7-8 days is a huge time lost. I was suggesting that this to be 3 days. Let
> other community members chime in too.


I should have replied to this in my previous missive. But I want to
reenforce how unhealthy I believe this practice is. 7-8 days, or even 3
days "being a huge time loss" makes absolutely no sense to me at all.
Assigning a bug should not mean it gets fixed any faster. If it does, then
we need to change the way we are working. (And if this means changing the
JIRA ticket workflow, then so be it. If something isn't working for us, we
change it.)

In fact, I would go so far as to say that we should think of assigning bugs
as an exclusionary practice. Every time you assign a bug, you're shutting
out the community. That's how we should think about it. Assign the bug,
shut out the community. And so, I would say we should try to avoid doing
it, unless it is absolutely necessary. (Such as when you're co-ordinating
some release critical work, or when you, yourself, are about to start work
on something. Of course, it's perfectly fine to shut out the community, if
you're doing that at the same time as starting work on something!)


-- 
NS

Re: [DISCUSS] Don't assign tickets to people when triaging

[Noah Slater <ns...@apache.org>]

On 11 April 2013 15:11, Joe Brockmeier <jz...@zonker.net> wrote:

>
> I'm against a policy of never assigning tickets, but it shouldn't be the
> norm for one set of folks to triage tickets and assign them to another
> set of folks.



Me too.

We should establish:

 a) A rule that we avoid ticket assignment by default, and
 b) A clear set of exceptions to that rule...


-- 
NS

Re: [DISCUSS] Don't assign tickets to people when triaging

[Joe Brockmeier <jz...@zonker.net>]

On Thu, Apr 11, 2013, at 05:22 AM, Abhinandan Prateek wrote:
> >Never would be too lenient. Maybe assign it after 7-8 days since they
> >don't need immediate attention.
> 
> 7-8 days is a huge time lost. I was suggesting that this to be 3 days.
> Let other community members chime in too.

Are we assuming that a bug is going to be closed as soon as it's
assigned? 

Why does the bug need to be assigned rather than picked up, if the
person who'd get the issue has the time to take it on?

One of the things we're trying to avoid is having queues of issues
backed up assigned to specific folks, which puts off potential
contributors who might claim the ticket if it was unassigned. 

Another thing we're trying to avoid is the mentality that bugs have to
be assigned rather than picked up by the individual developer. 

I'm against a policy of never assigning tickets, but it shouldn't be the
norm for one set of folks to triage tickets and assign them to another
set of folks. 


> >A community member should always have an interest area within CS and
> >he/she subscribes to it. IF a bug is opened in that area he/she should be
> >notified (yeah we can set rules in our email client).

This is assuming people are dedicated to working on CloudStack as a
$dayjob, really. We shouldn't make that assumption.

Best,

jzb
-- 
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [DISCUSS] Don't assign tickets to people when triaging

[Abhinandan Prateek <Ab...@citrix.com>]

>>
>>I will start with an example: A critical bug (CLOUDSTACK-1941) that is
>>blocking a release (4.1) is not picked up by any community member for 5
>>days !
>>The reason being that it is a UI issue but not that clear from the desc,
>>the nature of the bug is known after someone spends time on it.
>>
>>Now is it wrong to ask the community members who have expertise on UI to
>>fix it, in a bid to help Chip get the release out ?
>>
>>A set of guidelines are necessary so that this whole confusion about bugs
>>getting assigned is cleared up. I will start by proposing some simple
>>rules:
>>
>>1. Never assign bugs that are not critical or blocker unless they meet
>>any
>>of the below condition.
>
>Never would be too lenient. Maybe assign it after 7-8 days since they
>don't need immediate attention.

7-8 days is a huge time lost. I was suggesting that this to be 3 days. Let
other community members chime in too.

>
>>
>>2. Assign a bug that is open for more than 3 days and none of the
>>community member has shown interest in picking it up. This period can
>>vary
>>depending on how close a branch where bug is noted is close to a release.
>
>A community member should always have an interest area within CS and
>he/she subscribes to it. IF a bug is opened in that area he/she should be
>notified (yeah we can set rules in our email client).
>
>>
>>3. Assign or request to community for picking up a bug if it is blocking
>>the work that a community member may be working on.
>>
>>Do add or amend so that we clear up process around this issue.
>>
>>
>>> 
>>>
>>>I think we need to find a middle path where:
>>>
>>>* Everyone is pro-active in reviewing bugs that are in their area, and
>>>not depending on a having bugs assigned before they work on them.
>>>
>>>* We don't have a ridiculous number of bugs assigned to people where
>>>they may not get to those bugs for weeks - when someone else might
>>>conceivably work on them, but be put off because they think "Oh, Random
>>>J. Programmer already has that."
>>>
>>>* We can assign bugs when it does make sense, without there being an
>>>absolute rule against assigning bugs to people when common sense
>>>dictates otherwise.
>>
>>I just tried to extract this part of the email as a set of rules above.
>>
>>>
>>
>

Re: [DISCUSS] Don't assign tickets to people when triaging

[Nitin Mehta <Ni...@citrix.com>]

+1 with slight modifications :)

On 11/04/13 8:39 AM, "Abhinandan Prateek" <Ab...@citrix.com>
wrote:

>
>
>On 10/04/13 8:57 PM, "Joe Brockmeier" <jz...@zonker.net> wrote:
>
>>On Wed, Apr 10, 2013, at 02:35 AM, Abhinandan Prateek wrote:
>>> I think if you were wrongly assigned bug that you did not want to work
>>>on
>>> just spit it in the mailing list and you will not be guilty of cookie
>>> licking.
>>> 
>>> Given the huge number bugs lets focus on how to reduce that pile
>>>instead
>>> of raking up non issues.
>>
>>It's not a non-issue. When people see bugs assigned to a person, they're
>>less likely to go ahead and take it.
>
>
>I will start with an example: A critical bug (CLOUDSTACK-1941) that is
>blocking a release (4.1) is not picked up by any community member for 5
>days !
>The reason being that it is a UI issue but not that clear from the desc,
>the nature of the bug is known after someone spends time on it.
>
>Now is it wrong to ask the community members who have expertise on UI to
>fix it, in a bid to help Chip get the release out ?
>
>A set of guidelines are necessary so that this whole confusion about bugs
>getting assigned is cleared up. I will start by proposing some simple
>rules:
>
>1. Never assign bugs that are not critical or blocker unless they meet any
>of the below condition.

Never would be too lenient. Maybe assign it after 7-8 days since they
don't need immediate attention.

>
>2. Assign a bug that is open for more than 3 days and none of the
>community member has shown interest in picking it up. This period can vary
>depending on how close a branch where bug is noted is close to a release.

A community member should always have an interest area within CS and
he/she subscribes to it. IF a bug is opened in that area he/she should be
notified (yeah we can set rules in our email client).

>
>3. Assign or request to community for picking up a bug if it is blocking
>the work that a community member may be working on.
>
>Do add or amend so that we clear up process around this issue.
>
>
>> 
>>
>>I think we need to find a middle path where:
>>
>>* Everyone is pro-active in reviewing bugs that are in their area, and
>>not depending on a having bugs assigned before they work on them.
>>
>>* We don't have a ridiculous number of bugs assigned to people where
>>they may not get to those bugs for weeks - when someone else might
>>conceivably work on them, but be put off because they think "Oh, Random
>>J. Programmer already has that."
>>
>>* We can assign bugs when it does make sense, without there being an
>>absolute rule against assigning bugs to people when common sense
>>dictates otherwise.
>
>I just tried to extract this part of the email as a set of rules above.
>
>>
>

Re: [DISCUSS] Don't assign tickets to people when triaging

[Abhinandan Prateek <Ab...@citrix.com>]

On 10/04/13 8:57 PM, "Joe Brockmeier" <jz...@zonker.net> wrote:

>On Wed, Apr 10, 2013, at 02:35 AM, Abhinandan Prateek wrote:
>> I think if you were wrongly assigned bug that you did not want to work
>>on
>> just spit it in the mailing list and you will not be guilty of cookie
>> licking.
>> 
>> Given the huge number bugs lets focus on how to reduce that pile instead
>> of raking up non issues.
>
>It's not a non-issue. When people see bugs assigned to a person, they're
>less likely to go ahead and take it.


I will start with an example: A critical bug (CLOUDSTACK-1941) that is
blocking a release (4.1) is not picked up by any community member for 5
days !
The reason being that it is a UI issue but not that clear from the desc,
the nature of the bug is known after someone spends time on it.

Now is it wrong to ask the community members who have expertise on UI to
fix it, in a bid to help Chip get the release out ?

A set of guidelines are necessary so that this whole confusion about bugs
getting assigned is cleared up. I will start by proposing some simple
rules:

1. Never assign bugs that are not critical or blocker unless they meet any
of the below condition.

2. Assign a bug that is open for more than 3 days and none of the
community member has shown interest in picking it up. This period can vary
depending on how close a branch where bug is noted is close to a release.

3. Assign or request to community for picking up a bug if it is blocking
the work that a community member may be working on.

Do add or amend so that we clear up process around this issue.


> 
>
>I think we need to find a middle path where:
>
>* Everyone is pro-active in reviewing bugs that are in their area, and
>not depending on a having bugs assigned before they work on them.
>
>* We don't have a ridiculous number of bugs assigned to people where
>they may not get to those bugs for weeks - when someone else might
>conceivably work on them, but be put off because they think "Oh, Random
>J. Programmer already has that."
>
>* We can assign bugs when it does make sense, without there being an
>absolute rule against assigning bugs to people when common sense
>dictates otherwise.

I just tried to extract this part of the email as a set of rules above.

>

Re: [DISCUSS] Don't assign tickets to people when triaging

[Joe Brockmeier <jz...@zonker.net>]

On Wed, Apr 10, 2013, at 02:35 AM, Abhinandan Prateek wrote:
> I think if you were wrongly assigned bug that you did not want to work on
> just spit it in the mailing list and you will not be guilty of cookie
> licking.
> 
> Given the huge number bugs lets focus on how to reduce that pile instead
> of raking up non issues.

It's not a non-issue. When people see bugs assigned to a person, they're
less likely to go ahead and take it. 

I think we need to find a middle path where:

* Everyone is pro-active in reviewing bugs that are in their area, and
not depending on a having bugs assigned before they work on them.

* We don't have a ridiculous number of bugs assigned to people where
they may not get to those bugs for weeks - when someone else might
conceivably work on them, but be put off because they think "Oh, Random
J. Programmer already has that." 

* We can assign bugs when it does make sense, without there being an
absolute rule against assigning bugs to people when common sense
dictates otherwise. 

* Can we stop talking about cookies unless somebody is going to send me
a few? I like homemade chocolate chip.

Mmmm. Cookies.

Best,

jzb
-- 
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [DISCUSS] Don't assign tickets to people when triaging

[Abhinandan Prateek <Ab...@citrix.com>]

I think if you were wrongly assigned bug that you did not want to work on just spit it in the mailing list and you will not be guilty of cookie licking.

Given the huge number bugs lets focus on how to reduce that pile instead of raking up non issues.



On 10-Apr-2013, at 12:41 PM, "Rohit Yadav" <bh...@apache.org> wrote:

> Hi Abhi,
> 
> First of all I totally agree with you on having at least our release
> manager the triaging blockers.
> 
> Secondly, we need to understand the issue Noah is trying to raise. The
> issue assignment way now is surely an anti-pattern. Let's not deviate from
> the real issue Noah started with this thread.
> 
> From what I understand and wanted to convey is that in an opensource
> project the development should be done by contributors and forced upon
> them. When someone assigns an issue to me without my consent, I personally
> see it as an offence. To say it again, I want to promote culture where
> everyone (esp. committers) develops a habit to go through reviewboard,
> mailing lists and jira and take their own decisions.
> 
> Prasanna man you're awesome already you don't need to explain your
> awesomeness and willingness to be assigned bugs and fix 'em.
> People/companies who have their interests in fixing some issue on time is
> not an issue here. The problem is couple of anti-patterns, just want to
> tell what they are IMO;
> 
> 1. Issue assignment without consent, by few individuals who have taken the
> implicit role of managers. Solution: Politely ask them to avoid doing that.
> 2. Issue assignment not being taken up by contributors but forced many
> times. Solution: Fix habits, inculcate a weekly routine at least.
> 3. Push from individuals who allegedly are working for a company and
> pursing company's interest on ACS at cost of ruining the Apache culture. If
> you're a ACS committer, your decisions should be your own not your
> companys'.  For example, I would not like to see emails about 4.2 blockers
> or push about the same. ACS has yet to release 4.1.
> Solution: Pl. don't do it, do whatever you want in your private fork, leave
> ACS the opensoure Apache way.
> 
> Maybe I'm missing the some part of the picture here, maybe I'm wrong
> "hippie". I embrace change and would like learn and fix my thinkings,
> advise?
> 
> Cheers.
> 
> On Wed, Apr 10, 2013 at 12:07 PM, Abhinandan Prateek <
> Abhinandan.Prateek@citrix.com> wrote:
> 
>> I see that the term "cookie-licking" is being used frequently in the email
>> thread.
>> 
>> We are talking about roughly 200 cookies. 55 of which nobody is willing to
>> touch.
>> 150 of them are already assigned that means that these are either being
>> licked or being eaten.
>> 
>> 
>> As per the above definition if a release manager assigns a bug to a
>> community member who goes and fixes it, it does not count as cookie
>> licking.
>> 
>> Cookie licking is when someone sits on a bug and does not act on it, and
>> in that prevents another member to pick it up.
>> 
>> *I will say guys instead of worrying about cookie licking pick the cookies
>> there are so many around !*
>> 
>> -abhi
>> 
>> 
>> 
>> 
>> 
>> 
>> On 10/04/13 9:43 AM, "Abhinandan Prateek" <Ab...@citrix.com>
>> wrote:
>> 
>>> We have to leave some of this flexibility in the hands of the release
>>> manager.
>>> I agree the community should have a first go at the unassigned tickets,
>>> while some tickets are picked up quickly others are around for a while.
>>> As a release manager it is the responsibility bestowed in that person that
>>> the release is made on time and with quality.
>>> So I think it is perfectly fine for the people responsible for a release
>>> to triage a blocker in case it is blocking the work of some of the
>>> community member and there is an urgency to get it fixed. Same goes for
>>> the blockers and criticals that remain on Jira for some time.
>>> 
>>> I will not though differentiate between community members as all of the
>>> members who contribute are passionate about it and have time to
>>> contribute.
>>> 
>>> -abhi
>>> 
>>> 
>>> On 10/04/13 12:05 AM, "Noah Slater" <ns...@apache.org> wrote:
>>> 
>>>> Got it. Thanks! :)
>>>> 
>>>> 
>>>> On 9 April 2013 19:29, Rohit Yadav <bh...@apache.org> wrote:
>>>> 
>>>>> On Tue, Apr 9, 2013 at 11:51 PM, Noah Slater <ns...@apache.org>
>>>>> wrote:
>>>>> 
>>>>>> When you say it's understandable that people being paid to work on
>>>>>> CloudStack full time engage in cookie licking, do you mean to say you
>>>>> think
>>>>>> it is acceptable?
>>>>> 
>>>>> 
>>>>> Hell NO, understandable == I understand how people work in the
>>>>> companies
>>>>> who pay them to work on ACS.
>>>>> But understandable != acceptable.
>>>>> 
>>>>> 
>>>>>> Or do you believe we should be working to prevent it?
>>>>> 
>>>>> Yes! That's what I'm saying: we should be working to prevent it. A way
>>>>> I
>>>>> suggested is to inculcate the habit among ourselves (all contributors)
>>>>> and
>>>>> promote the culture within ACS community to take initiatives and to
>>>>> assign
>>>>> the tickets themselves.
>>>>> 
>>>>> No one should assign tickets to others unless a person has jira ACL
>>>>> issues
>>>>> and has explicitly asked for same on public ML to someone/anyone.
>>>>> 
>>>>> Cheers.
>>>>> 
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 9 April 2013 19:14, Rohit Yadav <bh...@apache.org> wrote:
>>>>>> 
>>>>>>> On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam
>>>>> <ts...@apache.org>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi
>>>>> wrote:
>>>>>>>>> [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.
>>>>>>>> 
>>>>>>>> I have no opinion and am okay whichever way -
>>>>> auto-assign/unassigned.
>>>>>>>> But these workflows should be _*clearly*_ mentioned to
>>>>> contributors
>>>>>>>> and where they will go looking for them - wiki, website etc.
>>>>>>> A non-sponsored new/old (casual/hippie) contributor would try to
>>>>> search
>>>>>>> among unassigned issues, while managers/developers/committers whose
>>>>>> $dayjob
>>>>>>> allows them to work on ACS fulltime will tend to do 'cookie lickin'
>>>>> which
>>>>>>> is understandable and will assure that someone gets the privilege
>>>>> to
>>>>> work
>>>>>>> on it and their employers will make sure the task would be done :)
>>>>>>> 
>>>>>>> I would prefer an environment where every contributor (sponsored or
>>>>>>> otherwise) would assign the tickets themselves, and unassign if
>>>>> they
>>>>>> cannot
>>>>>>> do it or don't have time/resources for it.
>>>>>>> 
>>>>>>> We've already seen several occasions where someone assigns an issue
>>>>> to
>>>>>>> someone and we see cycle of assignments because the "assigner" had
>>>>> no
>>>>>> clue
>>>>>>> about the issue or did not really know who would could really
>>>>> resolve
>>>>> the
>>>>>>> issue. Just saying.
>>>>>>> 
>>>>>>> Cheers.
>>>>>>> 
>>>>>>> Triaging and assigning issues at the time of release to
>>>>>>>> contributors/committers by the Release Manager shouldn't be a
>>>>> problem
>>>>>>>> at all as long as it's communicated (as Chip did for the RC bugs)
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Prasanna.,
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> NS
>>>> 
>>>> 
>>>> 
>>>> --
>>>> NS
>> 
>> 

Re: [DISCUSS] Don't assign tickets to people when triaging

[Rohit Yadav <bh...@apache.org>]

Hi Abhi,

First of all I totally agree with you on having at least our release
manager the triaging blockers.

Secondly, we need to understand the issue Noah is trying to raise. The
issue assignment way now is surely an anti-pattern. Let's not deviate from
the real issue Noah started with this thread.

>From what I understand and wanted to convey is that in an opensource
project the development should be done by contributors and forced upon
them. When someone assigns an issue to me without my consent, I personally
see it as an offence. To say it again, I want to promote culture where
everyone (esp. committers) develops a habit to go through reviewboard,
mailing lists and jira and take their own decisions.

Prasanna man you're awesome already you don't need to explain your
awesomeness and willingness to be assigned bugs and fix 'em.
People/companies who have their interests in fixing some issue on time is
not an issue here. The problem is couple of anti-patterns, just want to
tell what they are IMO;

1. Issue assignment without consent, by few individuals who have taken the
implicit role of managers. Solution: Politely ask them to avoid doing that.
2. Issue assignment not being taken up by contributors but forced many
times. Solution: Fix habits, inculcate a weekly routine at least.
3. Push from individuals who allegedly are working for a company and
pursing company's interest on ACS at cost of ruining the Apache culture. If
you're a ACS committer, your decisions should be your own not your
companys'.  For example, I would not like to see emails about 4.2 blockers
or push about the same. ACS has yet to release 4.1.
Solution: Pl. don't do it, do whatever you want in your private fork, leave
ACS the opensoure Apache way.

Maybe I'm missing the some part of the picture here, maybe I'm wrong
"hippie". I embrace change and would like learn and fix my thinkings,
advise?

Cheers.

On Wed, Apr 10, 2013 at 12:07 PM, Abhinandan Prateek <
Abhinandan.Prateek@citrix.com> wrote:

> I see that the term "cookie-licking" is being used frequently in the email
> thread.
>
> We are talking about roughly 200 cookies. 55 of which nobody is willing to
> touch.
> 150 of them are already assigned that means that these are either being
> licked or being eaten.
>
>
> As per the above definition if a release manager assigns a bug to a
> community member who goes and fixes it, it does not count as cookie
> licking.
>
> Cookie licking is when someone sits on a bug and does not act on it, and
> in that prevents another member to pick it up.
>
> *I will say guys instead of worrying about cookie licking pick the cookies
> there are so many around !*
>
> -abhi
>
>
>
>
>
>
> On 10/04/13 9:43 AM, "Abhinandan Prateek" <Ab...@citrix.com>
> wrote:
>
> >We have to leave some of this flexibility in the hands of the release
> >manager.
> >I agree the community should have a first go at the unassigned tickets,
> >while some tickets are picked up quickly others are around for a while.
> >As a release manager it is the responsibility bestowed in that person that
> >the release is made on time and with quality.
> >So I think it is perfectly fine for the people responsible for a release
> >to triage a blocker in case it is blocking the work of some of the
> >community member and there is an urgency to get it fixed. Same goes for
> >the blockers and criticals that remain on Jira for some time.
> >
> >I will not though differentiate between community members as all of the
> >members who contribute are passionate about it and have time to
> >contribute.
> >
> >-abhi
> >
> >
> >On 10/04/13 12:05 AM, "Noah Slater" <ns...@apache.org> wrote:
> >
> >>Got it. Thanks! :)
> >>
> >>
> >>On 9 April 2013 19:29, Rohit Yadav <bh...@apache.org> wrote:
> >>
> >>> On Tue, Apr 9, 2013 at 11:51 PM, Noah Slater <ns...@apache.org>
> >>>wrote:
> >>>
> >>> > When you say it's understandable that people being paid to work on
> >>> > CloudStack full time engage in cookie licking, do you mean to say you
> >>> think
> >>> > it is acceptable?
> >>>
> >>>
> >>> Hell NO, understandable == I understand how people work in the
> >>>companies
> >>> who pay them to work on ACS.
> >>> But understandable != acceptable.
> >>>
> >>>
> >>> > Or do you believe we should be working to prevent it?
> >>> >
> >>>
> >>> Yes! That's what I'm saying: we should be working to prevent it. A way
> >>>I
> >>> suggested is to inculcate the habit among ourselves (all contributors)
> >>>and
> >>> promote the culture within ACS community to take initiatives and to
> >>>assign
> >>> the tickets themselves.
> >>>
> >>> No one should assign tickets to others unless a person has jira ACL
> >>>issues
> >>> and has explicitly asked for same on public ML to someone/anyone.
> >>>
> >>> Cheers.
> >>>
> >>>
> >>> >
> >>> >
> >>> > On 9 April 2013 19:14, Rohit Yadav <bh...@apache.org> wrote:
> >>> >
> >>> > > On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam
> >>><ts...@apache.org>
> >>> > > wrote:
> >>> > >
> >>> > > > On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi
> >>>wrote:
> >>> > > > > [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.
> >>> > > >
> >>> > > > I have no opinion and am okay whichever way -
> >>>auto-assign/unassigned.
> >>> > > > But these workflows should be _*clearly*_ mentioned to
> >>>contributors
> >>> > > > and where they will go looking for them - wiki, website etc.
> >>> > > >
> >>> > > >
> >>> > > A non-sponsored new/old (casual/hippie) contributor would try to
> >>>search
> >>> > > among unassigned issues, while managers/developers/committers whose
> >>> > $dayjob
> >>> > > allows them to work on ACS fulltime will tend to do 'cookie lickin'
> >>> which
> >>> > > is understandable and will assure that someone gets the privilege
> >>>to
> >>> work
> >>> > > on it and their employers will make sure the task would be done :)
> >>> > >
> >>> > > I would prefer an environment where every contributor (sponsored or
> >>> > > otherwise) would assign the tickets themselves, and unassign if
> >>>they
> >>> > cannot
> >>> > > do it or don't have time/resources for it.
> >>> > >
> >>> > > We've already seen several occasions where someone assigns an issue
> >>>to
> >>> > > someone and we see cycle of assignments because the "assigner" had
> >>>no
> >>> > clue
> >>> > > about the issue or did not really know who would could really
> >>>resolve
> >>> the
> >>> > > issue. Just saying.
> >>> > >
> >>> > > Cheers.
> >>> > >
> >>> > > Triaging and assigning issues at the time of release to
> >>> > > > contributors/committers by the Release Manager shouldn't be a
> >>>problem
> >>> > > > at all as long as it's communicated (as Chip did for the RC bugs)
> >>> > > >
> >>> > > > Thanks,
> >>> > > >
> >>> > > > --
> >>> > > > Prasanna.,
> >>> > > >
> >>> > >
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > NS
> >>> >
> >>>
> >>
> >>
> >>
> >>--
> >>NS
> >
>
>

Re: [DISCUSS] Don't assign tickets to people when triaging

[Abhinandan Prateek <Ab...@citrix.com>]

I see that the term "cookie-licking" is being used frequently in the email
thread.

We are talking about roughly 200 cookies. 55 of which nobody is willing to
touch.
150 of them are already assigned that means that these are either being
licked or being eaten.


As per the above definition if a release manager assigns a bug to a
community member who goes and fixes it, it does not count as cookie
licking.

Cookie licking is when someone sits on a bug and does not act on it, and
in that prevents another member to pick it up.

*I will say guys instead of worrying about cookie licking pick the cookies
there are so many around !*

-abhi






On 10/04/13 9:43 AM, "Abhinandan Prateek" <Ab...@citrix.com>
wrote:

>We have to leave some of this flexibility in the hands of the release
>manager. 
>I agree the community should have a first go at the unassigned tickets,
>while some tickets are picked up quickly others are around for a while.
>As a release manager it is the responsibility bestowed in that person that
>the release is made on time and with quality.
>So I think it is perfectly fine for the people responsible for a release
>to triage a blocker in case it is blocking the work of some of the
>community member and there is an urgency to get it fixed. Same goes for
>the blockers and criticals that remain on Jira for some time.
>
>I will not though differentiate between community members as all of the
>members who contribute are passionate about it and have time to
>contribute.
>
>-abhi
>
>
>On 10/04/13 12:05 AM, "Noah Slater" <ns...@apache.org> wrote:
>
>>Got it. Thanks! :)
>>
>>
>>On 9 April 2013 19:29, Rohit Yadav <bh...@apache.org> wrote:
>>
>>> On Tue, Apr 9, 2013 at 11:51 PM, Noah Slater <ns...@apache.org>
>>>wrote:
>>>
>>> > When you say it's understandable that people being paid to work on
>>> > CloudStack full time engage in cookie licking, do you mean to say you
>>> think
>>> > it is acceptable?
>>>
>>>
>>> Hell NO, understandable == I understand how people work in the
>>>companies
>>> who pay them to work on ACS.
>>> But understandable != acceptable.
>>>
>>>
>>> > Or do you believe we should be working to prevent it?
>>> >
>>>
>>> Yes! That's what I'm saying: we should be working to prevent it. A way
>>>I
>>> suggested is to inculcate the habit among ourselves (all contributors)
>>>and
>>> promote the culture within ACS community to take initiatives and to
>>>assign
>>> the tickets themselves.
>>>
>>> No one should assign tickets to others unless a person has jira ACL
>>>issues
>>> and has explicitly asked for same on public ML to someone/anyone.
>>>
>>> Cheers.
>>>
>>>
>>> >
>>> >
>>> > On 9 April 2013 19:14, Rohit Yadav <bh...@apache.org> wrote:
>>> >
>>> > > On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam
>>><ts...@apache.org>
>>> > > wrote:
>>> > >
>>> > > > On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi
>>>wrote:
>>> > > > > [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.
>>> > > >
>>> > > > I have no opinion and am okay whichever way -
>>>auto-assign/unassigned.
>>> > > > But these workflows should be _*clearly*_ mentioned to
>>>contributors
>>> > > > and where they will go looking for them - wiki, website etc.
>>> > > >
>>> > > >
>>> > > A non-sponsored new/old (casual/hippie) contributor would try to
>>>search
>>> > > among unassigned issues, while managers/developers/committers whose
>>> > $dayjob
>>> > > allows them to work on ACS fulltime will tend to do 'cookie lickin'
>>> which
>>> > > is understandable and will assure that someone gets the privilege
>>>to
>>> work
>>> > > on it and their employers will make sure the task would be done :)
>>> > >
>>> > > I would prefer an environment where every contributor (sponsored or
>>> > > otherwise) would assign the tickets themselves, and unassign if
>>>they
>>> > cannot
>>> > > do it or don't have time/resources for it.
>>> > >
>>> > > We've already seen several occasions where someone assigns an issue
>>>to
>>> > > someone and we see cycle of assignments because the "assigner" had
>>>no
>>> > clue
>>> > > about the issue or did not really know who would could really
>>>resolve
>>> the
>>> > > issue. Just saying.
>>> > >
>>> > > Cheers.
>>> > >
>>> > > Triaging and assigning issues at the time of release to
>>> > > > contributors/committers by the Release Manager shouldn't be a
>>>problem
>>> > > > at all as long as it's communicated (as Chip did for the RC bugs)
>>> > > >
>>> > > > Thanks,
>>> > > >
>>> > > > --
>>> > > > Prasanna.,
>>> > > >
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > NS
>>> >
>>>
>>
>>
>>
>>-- 
>>NS
>

Re: [DISCUSS] Don't assign tickets to people when triaging

[Abhinandan Prateek <Ab...@citrix.com>]

We have to leave some of this flexibility in the hands of the release
manager. 
I agree the community should have a first go at the unassigned tickets,
while some tickets are picked up quickly others are around for a while.
As a release manager it is the responsibility bestowed in that person that
the release is made on time and with quality.
So I think it is perfectly fine for the people responsible for a release
to triage a blocker in case it is blocking the work of some of the
community member and there is an urgency to get it fixed. Same goes for
the blockers and criticals that remain on Jira for some time.

I will not though differentiate between community members as all of the
members who contribute are passionate about it and have time to contribute.

-abhi


On 10/04/13 12:05 AM, "Noah Slater" <ns...@apache.org> wrote:

>Got it. Thanks! :)
>
>
>On 9 April 2013 19:29, Rohit Yadav <bh...@apache.org> wrote:
>
>> On Tue, Apr 9, 2013 at 11:51 PM, Noah Slater <ns...@apache.org> wrote:
>>
>> > When you say it's understandable that people being paid to work on
>> > CloudStack full time engage in cookie licking, do you mean to say you
>> think
>> > it is acceptable?
>>
>>
>> Hell NO, understandable == I understand how people work in the companies
>> who pay them to work on ACS.
>> But understandable != acceptable.
>>
>>
>> > Or do you believe we should be working to prevent it?
>> >
>>
>> Yes! That's what I'm saying: we should be working to prevent it. A way I
>> suggested is to inculcate the habit among ourselves (all contributors)
>>and
>> promote the culture within ACS community to take initiatives and to
>>assign
>> the tickets themselves.
>>
>> No one should assign tickets to others unless a person has jira ACL
>>issues
>> and has explicitly asked for same on public ML to someone/anyone.
>>
>> Cheers.
>>
>>
>> >
>> >
>> > On 9 April 2013 19:14, Rohit Yadav <bh...@apache.org> wrote:
>> >
>> > > On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam <ts...@apache.org>
>> > > wrote:
>> > >
>> > > > On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi
>>wrote:
>> > > > > [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.
>> > > >
>> > > > I have no opinion and am okay whichever way -
>>auto-assign/unassigned.
>> > > > But these workflows should be _*clearly*_ mentioned to
>>contributors
>> > > > and where they will go looking for them - wiki, website etc.
>> > > >
>> > > >
>> > > A non-sponsored new/old (casual/hippie) contributor would try to
>>search
>> > > among unassigned issues, while managers/developers/committers whose
>> > $dayjob
>> > > allows them to work on ACS fulltime will tend to do 'cookie lickin'
>> which
>> > > is understandable and will assure that someone gets the privilege to
>> work
>> > > on it and their employers will make sure the task would be done :)
>> > >
>> > > I would prefer an environment where every contributor (sponsored or
>> > > otherwise) would assign the tickets themselves, and unassign if they
>> > cannot
>> > > do it or don't have time/resources for it.
>> > >
>> > > We've already seen several occasions where someone assigns an issue
>>to
>> > > someone and we see cycle of assignments because the "assigner" had
>>no
>> > clue
>> > > about the issue or did not really know who would could really
>>resolve
>> the
>> > > issue. Just saying.
>> > >
>> > > Cheers.
>> > >
>> > > Triaging and assigning issues at the time of release to
>> > > > contributors/committers by the Release Manager shouldn't be a
>>problem
>> > > > at all as long as it's communicated (as Chip did for the RC bugs)
>> > > >
>> > > > Thanks,
>> > > >
>> > > > --
>> > > > Prasanna.,
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > NS
>> >
>>
>
>
>
>-- 
>NS

Re: [DISCUSS] Don't assign tickets to people when triaging

[Noah Slater <ns...@apache.org>]

Got it. Thanks! :)


On 9 April 2013 19:29, Rohit Yadav <bh...@apache.org> wrote:

> On Tue, Apr 9, 2013 at 11:51 PM, Noah Slater <ns...@apache.org> wrote:
>
> > When you say it's understandable that people being paid to work on
> > CloudStack full time engage in cookie licking, do you mean to say you
> think
> > it is acceptable?
>
>
> Hell NO, understandable == I understand how people work in the companies
> who pay them to work on ACS.
> But understandable != acceptable.
>
>
> > Or do you believe we should be working to prevent it?
> >
>
> Yes! That's what I'm saying: we should be working to prevent it. A way I
> suggested is to inculcate the habit among ourselves (all contributors) and
> promote the culture within ACS community to take initiatives and to assign
> the tickets themselves.
>
> No one should assign tickets to others unless a person has jira ACL issues
> and has explicitly asked for same on public ML to someone/anyone.
>
> Cheers.
>
>
> >
> >
> > On 9 April 2013 19:14, Rohit Yadav <bh...@apache.org> wrote:
> >
> > > On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam <ts...@apache.org>
> > > wrote:
> > >
> > > > On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi wrote:
> > > > > [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.
> > > >
> > > > I have no opinion and am okay whichever way - auto-assign/unassigned.
> > > > But these workflows should be _*clearly*_ mentioned to contributors
> > > > and where they will go looking for them - wiki, website etc.
> > > >
> > > >
> > > A non-sponsored new/old (casual/hippie) contributor would try to search
> > > among unassigned issues, while managers/developers/committers whose
> > $dayjob
> > > allows them to work on ACS fulltime will tend to do 'cookie lickin'
> which
> > > is understandable and will assure that someone gets the privilege to
> work
> > > on it and their employers will make sure the task would be done :)
> > >
> > > I would prefer an environment where every contributor (sponsored or
> > > otherwise) would assign the tickets themselves, and unassign if they
> > cannot
> > > do it or don't have time/resources for it.
> > >
> > > We've already seen several occasions where someone assigns an issue to
> > > someone and we see cycle of assignments because the "assigner" had no
> > clue
> > > about the issue or did not really know who would could really resolve
> the
> > > issue. Just saying.
> > >
> > > Cheers.
> > >
> > > Triaging and assigning issues at the time of release to
> > > > contributors/committers by the Release Manager shouldn't be a problem
> > > > at all as long as it's communicated (as Chip did for the RC bugs)
> > > >
> > > > Thanks,
> > > >
> > > > --
> > > > Prasanna.,
> > > >
> > >
> >
> >
> >
> > --
> > NS
> >
>



-- 
NS

Re: [DISCUSS] Don't assign tickets to people when triaging

[Rohit Yadav <bh...@apache.org>]

On Tue, Apr 9, 2013 at 11:51 PM, Noah Slater <ns...@apache.org> wrote:

> When you say it's understandable that people being paid to work on
> CloudStack full time engage in cookie licking, do you mean to say you think
> it is acceptable?


Hell NO, understandable == I understand how people work in the companies
who pay them to work on ACS.
But understandable != acceptable.


> Or do you believe we should be working to prevent it?
>

Yes! That's what I'm saying: we should be working to prevent it. A way I
suggested is to inculcate the habit among ourselves (all contributors) and
promote the culture within ACS community to take initiatives and to assign
the tickets themselves.

No one should assign tickets to others unless a person has jira ACL issues
and has explicitly asked for same on public ML to someone/anyone.

Cheers.


>
>
> On 9 April 2013 19:14, Rohit Yadav <bh...@apache.org> wrote:
>
> > On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam <ts...@apache.org>
> > wrote:
> >
> > > On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi wrote:
> > > > [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.
> > >
> > > I have no opinion and am okay whichever way - auto-assign/unassigned.
> > > But these workflows should be _*clearly*_ mentioned to contributors
> > > and where they will go looking for them - wiki, website etc.
> > >
> > >
> > A non-sponsored new/old (casual/hippie) contributor would try to search
> > among unassigned issues, while managers/developers/committers whose
> $dayjob
> > allows them to work on ACS fulltime will tend to do 'cookie lickin' which
> > is understandable and will assure that someone gets the privilege to work
> > on it and their employers will make sure the task would be done :)
> >
> > I would prefer an environment where every contributor (sponsored or
> > otherwise) would assign the tickets themselves, and unassign if they
> cannot
> > do it or don't have time/resources for it.
> >
> > We've already seen several occasions where someone assigns an issue to
> > someone and we see cycle of assignments because the "assigner" had no
> clue
> > about the issue or did not really know who would could really resolve the
> > issue. Just saying.
> >
> > Cheers.
> >
> > Triaging and assigning issues at the time of release to
> > > contributors/committers by the Release Manager shouldn't be a problem
> > > at all as long as it's communicated (as Chip did for the RC bugs)
> > >
> > > Thanks,
> > >
> > > --
> > > Prasanna.,
> > >
> >
>
>
>
> --
> NS
>

Re: [DISCUSS] Don't assign tickets to people when triaging

[Noah Slater <ns...@apache.org>]

When you say it's understandable that people being paid to work on
CloudStack full time engage in cookie licking, do you mean to say you think
it is acceptable? Or do you believe we should be working to prevent it?


On 9 April 2013 19:14, Rohit Yadav <bh...@apache.org> wrote:

> On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam <ts...@apache.org>
> wrote:
>
> > On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi wrote:
> > > [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.
> >
> > I have no opinion and am okay whichever way - auto-assign/unassigned.
> > But these workflows should be _*clearly*_ mentioned to contributors
> > and where they will go looking for them - wiki, website etc.
> >
> >
> A non-sponsored new/old (casual/hippie) contributor would try to search
> among unassigned issues, while managers/developers/committers whose $dayjob
> allows them to work on ACS fulltime will tend to do 'cookie lickin' which
> is understandable and will assure that someone gets the privilege to work
> on it and their employers will make sure the task would be done :)
>
> I would prefer an environment where every contributor (sponsored or
> otherwise) would assign the tickets themselves, and unassign if they cannot
> do it or don't have time/resources for it.
>
> We've already seen several occasions where someone assigns an issue to
> someone and we see cycle of assignments because the "assigner" had no clue
> about the issue or did not really know who would could really resolve the
> issue. Just saying.
>
> Cheers.
>
> Triaging and assigning issues at the time of release to
> > contributors/committers by the Release Manager shouldn't be a problem
> > at all as long as it's communicated (as Chip did for the RC bugs)
> >
> > Thanks,
> >
> > --
> > Prasanna.,
> >
>



-- 
NS

Re: [DISCUSS] Don't assign tickets to people when triaging

[Prasanna Santhanam <ts...@apache.org>]

On Tue, Apr 09, 2013 at 11:44:37PM +0530, Rohit Yadav wrote:
> On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam <ts...@apache.org> wrote:
> 
> > On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi wrote:
> > > [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.
> >
> > I have no opinion and am okay whichever way - auto-assign/unassigned.
> > But these workflows should be _*clearly*_ mentioned to contributors
> > and where they will go looking for them - wiki, website etc.
> >
> >
> A non-sponsored new/old (casual/hippie) contributor would try to search
> among unassigned issues, while managers/developers/committers whose $dayjob
> allows them to work on ACS fulltime will tend to do 'cookie lickin' which
> is understandable and will assure that someone gets the privilege to work
> on it and their employers will make sure the task would be done :)

I don't think of it as a privilege. Several companies are working
on/contributing to/using CloudStack. I'd think a 'hippie' would have
less to lose if a bug isn't fixed in time as compared to someone
actually facing that bug in production. And it's in the interest of
that person to fix/have the bug fixed. If you do see bugs being held
without any progress /update on JIRA then I say snatch that cookie and
eat it. I'm not promoting holding on to bugs at all! :)

> 
> I would prefer an environment where every contributor (sponsored or
> otherwise) would assign the tickets themselves, and unassign if they cannot
> do it or don't have time/resources for it.

I've always wanted this to happen. I think it's wasteful to have
someone dedicated to look at the tickets for you. People are much
smarter than having to look at JIRA filters and tickets that *might*
interest you. And it's perfectly alright for someone to fix the issue
that is assigned to me as well. I'm happy if someone fixes a bug
that's assigned to me :)

> We've already seen several occasions where someone assigns an issue to
> someone and we see cycle of assignments because the "assigner" had no clue
> about the issue or did not really know who would could really resolve the
> issue. Just saying.
> 
This likely is because 'someone' wasn't aware of who was able
to/available for fixing the issue. CloudStack spans a lot of modules
and it's not easy to figure out who broke what. I've only assigned
bugs to folks that I know for sure will be the right person to fix the
issue. And that person was not necessarily a committer. I've assigned
bugs to contributors too to help promote them to committer through
more patch submissions.

-- 
Prasanna.,

Re: [DISCUSS] Don't assign tickets to people when triaging

[Rohit Yadav <bh...@apache.org>]

On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam <ts...@apache.org> wrote:

> On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi wrote:
> > [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.
>
> I have no opinion and am okay whichever way - auto-assign/unassigned.
> But these workflows should be _*clearly*_ mentioned to contributors
> and where they will go looking for them - wiki, website etc.
>
>
A non-sponsored new/old (casual/hippie) contributor would try to search
among unassigned issues, while managers/developers/committers whose $dayjob
allows them to work on ACS fulltime will tend to do 'cookie lickin' which
is understandable and will assure that someone gets the privilege to work
on it and their employers will make sure the task would be done :)

I would prefer an environment where every contributor (sponsored or
otherwise) would assign the tickets themselves, and unassign if they cannot
do it or don't have time/resources for it.

We've already seen several occasions where someone assigns an issue to
someone and we see cycle of assignments because the "assigner" had no clue
about the issue or did not really know who would could really resolve the
issue. Just saying.

Cheers.

Triaging and assigning issues at the time of release to
> contributors/committers by the Release Manager shouldn't be a problem
> at all as long as it's communicated (as Chip did for the RC bugs)
>
> Thanks,
>
> --
> Prasanna.,
>

Re: [DISCUSS] Don't assign tickets to people when triaging

[Nitin Mehta <Ni...@citrix.com>]

On 09/04/13 11:57 AM, "Prasanna Santhanam" <ts...@apache.org> wrote:

>On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi wrote:
>> [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.
>
>I have no opinion and am okay whichever way - auto-assign/unassigned.
>But these workflows should be _*clearly*_ mentioned to contributors
>and where they will go looking for them - wiki, website etc.

+1. I am fine either way as well. Perhaps the new folks can communicate
their interest areas as well.


>
>Triaging and assigning issues at the time of release to
>contributors/committers by the Release Manager shouldn't be a problem
>at all as long as it's communicated (as Chip did for the RC bugs)

I think we would need to triage them very close to release especially the
blockers and critical ones, but can have a little more relaxed norm
for other priority issues.


>
>Thanks,
>
>-- 
>Prasanna.,

Re: [DISCUSS] Don't assign tickets to people when triaging

[Prasanna Santhanam <ts...@apache.org>]

On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi wrote:
> [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.

I have no opinion and am okay whichever way - auto-assign/unassigned.
But these workflows should be _*clearly*_ mentioned to contributors
and where they will go looking for them - wiki, website etc. 

Triaging and assigning issues at the time of release to
contributors/committers by the Release Manager shouldn't be a problem
at all as long as it's communicated (as Chip did for the RC bugs) 

Thanks,

-- 
Prasanna.,

Re: [DISCUSS] Don't assign tickets to people when triaging

[Chiradeep Vittal <Ch...@citrix.com>]

On 4/8/13 1:32 PM, "Animesh Chaturvedi" <an...@citrix.com>
wrote:

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

Although the wiki and Jira are useful repositories of information, the ML
is where things are supposed to get decided. How about a daily report
posted to the ML (could be auto posted from Jira?) that lists
 - defects that have aged > 1 week without an owner
 - defects newly assigned to somebody
 - new defects without any owners
 - defects assigned but no progress > 1 week

Yes, anybody could run the same report on Jira, but this brings it out in
the open?

RE: [DISCUSS] Don't assign tickets to people when triaging

[Animesh Chaturvedi <an...@citrix.com>]

> -----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 <ns...@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
> > >

RE: [DISCUSS] Don't assign tickets to people when triaging

[Animesh Chaturvedi <an...@citrix.com>]

> -----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+Maintainers+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 <ns...@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
> >

RE: [DISCUSS] Don't assign tickets to people when triaging

[Will Chan <wi...@citrix.com>]

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

> -----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 <ns...@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
> 

Re: [DISCUSS] Don't assign tickets to people when triaging

[Sebastien Goasguen <ru...@gmail.com>]

On Apr 2, 2013, at 3:21 PM, Noah Slater <ns...@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

RE: [DISCUSS] Don't assign tickets to people when triaging

[Alex Huang <Al...@citrix.com>]

> I understand the reasoning - but for a newcomer looking to get involved, I
> think 'assigning' a bug - whether by default, or otherwise can be construed as
> excluding newcomers and no room for them to get involved, so I think it
> warrants caution at a minimum.
> 
> Our 'if not 'in progress' anyone can grab it' does not seem to be the norm for
> open source projects.
> 
> I also wonder if it makes a difference. Perhaps it does. In other projects I've
> been involved in, when I care about releases or just the project, I tend to
> watch the categories of bugs that I can fix, particularly the unassigned items.
> Does having a backlog of work assigned to me (as opposed to checking a
> component in Jira for outstanding work) improve things somehow? I don't
> know, perhaps it does and there is something I am missing.
> 

I want to first establish that we should do what's right for this community.  We should use other open source projects as a reference but we shouldn't just do whatever others are doing.

With that said, I think Jira is just a much better project management tool than what's available before.  We should use these workflows as much as possible to communicate what a release needs.  It's almost like git vs svn.  For many years, almost all open source projects use svn and linux is the only one that uses git but now you hardly hear of new projects say they're using svn anymore.  Apache was almost exclusively on bugzilla and jira before.  From what I can see, Cloudstack was one of the first to bring these into Apache and CloudStack can be one of the first to bring better patterns to apache as well.

Cloud is the future and cloudstack should use tools and patterns fit for the future.  Jira has a superior workflow for us to utilize.  We should utilize it when it comes to bug triage and release management.  

--Alex

Re: [DISCUSS] Don't assign tickets to people when triaging

[David Nalley <da...@gnsa.us>]

On Tue, Apr 2, 2013 at 6:53 PM, Alex Huang <Al...@citrix.com> wrote:
> So let me start off with I agree in principle with what Noah is talking about here.  Cookie licking is an anti-pattern that we should reject as a community.  However, I disagree the solution or even what is perceived as cookie licking.
>
> We established a while ago as a community that we follow a Jira workflow in handling bugs.  In that process, a bug is Open until it goes to "In Progress".  We can simply tweak our expectations on this workflow to achieve exactly the desired effects.
>
> - Assign bugs does not mean you own it, even if you assign it to yourself doesn't mean you own it.
> - No one owns a bug until the person assigned changed it to In Progress (not licked til this stage)
> - Before a bug goes into In Progress, anyone can grab it.
>
> By doing this we allow people who can help in prioritizing the bugs to assign bugs without going through another layer of negotiation.  Assigning bugs merely means asking the question "can you work on it".  This would be much more efficient way of doing things.
>
> I also think that we can setup public filters that people can use to find bugs they can work on.  In the filter, it doesn't look at who the bug is assigned to.  Just whether the bug is open or not.
>
> --Alex

I understand the reasoning - but for a newcomer looking to get
involved, I think 'assigning' a bug - whether by default, or otherwise
can be construed as excluding newcomers and no room for them to get
involved, so I think it warrants caution at a minimum.

Our 'if not 'in progress' anyone can grab it' does not seem to be the
norm for open source projects.

I also wonder if it makes a difference. Perhaps it does. In other
projects I've been involved in, when I care about releases or just the
project, I tend to watch the categories of bugs that I can fix,
particularly the unassigned items. Does having a backlog of work
assigned to me (as opposed to checking a component in Jira for
outstanding work) improve things somehow? I don't know, perhaps it
does and there is something I am missing.

I do think triaging is important - there are simply too many bugs to
not have some ongoing triage, make sure the proper component,
severity, etc is set, perhaps even doing some initial prompting for
enough information.

--David

RE: [DISCUSS] Don't assign tickets to people when triaging

[Alex Huang <Al...@citrix.com>]

So let me start off with I agree in principle with what Noah is talking about here.  Cookie licking is an anti-pattern that we should reject as a community.  However, I disagree the solution or even what is perceived as cookie licking.

We established a while ago as a community that we follow a Jira workflow in handling bugs.  In that process, a bug is Open until it goes to "In Progress".  We can simply tweak our expectations on this workflow to achieve exactly the desired effects.

- Assign bugs does not mean you own it, even if you assign it to yourself doesn't mean you own it.
- No one owns a bug until the person assigned changed it to In Progress (not licked til this stage)
- Before a bug goes into In Progress, anyone can grab it.

By doing this we allow people who can help in prioritizing the bugs to assign bugs without going through another layer of negotiation.  Assigning bugs merely means asking the question "can you work on it".  This would be much more efficient way of doing things.

I also think that we can setup public filters that people can use to find bugs they can work on.  In the filter, it doesn't look at who the bug is assigned to.  Just whether the bug is open or not.  

--Alex

> -----Original Message-----
> From: Noah Slater [mailto:nslater@apache.org]
> Sent: Tuesday, April 2, 2013 12:21 PM
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS] Don't assign tickets to people when triaging
> 
> 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