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 <abhinandan.prat...@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" <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 > > -- NS
