Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
MIME-Version: 1.0
In-Reply-To: <CD8CC1F7.3056B%abhinandan.prateek@citrix.com>
References: 
 <CAPaJBx6qNO9aSZe5bbe9z59_zfK1-zsKv10P9CKjewokXsXLtQ@mail.gmail.com>
	<CD8CC1F7.3056B%abhinandan.prateek@citrix.com>
Date: Thu, 11 Apr 2013 15:28:55 +0100
Message-ID: 
 <CAPaJBx4gSkr6uL918HBmd4po8FLy8CvOUvc_pWEhDYJexCbUBA@mail.gmail.com>
Subject: Re: [DISCUSS] Don't assign tickets to people when triaging
From: Noah Slater <nslater@apache.org>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Content-Type: multipart/alternative; boundary=20cf303ea1d447208f04da169b94

--20cf303ea1d447208f04da169b94
Content-Type: text/plain; charset=ISO-8859-1

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.Prateek@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" <nslater@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

--20cf303ea1d447208f04da169b94--