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" <nsla...@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" >><nsla...@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.prat...@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" <jburw...@basho.com >><javascript:;>> >> wrote: >> >> >> >>> +1 >> >>> >> >>> On Apr 11, 2013, at 7:22 AM, Noah Slater >><nsla...@apache.org<javascript:;>> >> wrote: >> >>> >> >>>> On 11 April 2013 11:22, Abhinandan Prateek >> >>>> <abhinandan.prat...@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
