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.prat...@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.prat...@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" <nsla...@apache.org> wrote: > > > >>Got it. Thanks! :) > >> > >> > >>On 9 April 2013 19:29, Rohit Yadav <bhais...@apache.org> wrote: > >> > >>> On Tue, Apr 9, 2013 at 11:51 PM, Noah Slater <nsla...@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 <bhais...@apache.org> wrote: > >>> > > >>> > > On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam > >>><t...@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 > > > >
