cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <bhais...@apache.org>
Subject Re: [DISCUSS] Don't assign tickets to people when triaging
Date Wed, 10 Apr 2013 07:11:21 GMT
On Wed, Apr 10, 2013 at 12:40 PM, Rohit Yadav <bhaisaab@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" <Abhinandan.Prateek@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" <nslater@apache.org> wrote:
>> >
>> >>Got it. Thanks! :)
>> >>
>> >>
>> >>On 9 April 2013 19:29, Rohit Yadav <bhaisaab@apache.org> wrote:
>> >>
>> >>> On Tue, Apr 9, 2013 at 11:51 PM, Noah Slater <nslater@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 <bhaisaab@apache.org>
wrote:
>> >>> >
>> >>> > > On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam
>> >>><tsp@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
>> >
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message