cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [DISCUSS] Don't assign tickets to people when triaging
Date Thu, 11 Apr 2013 13:47:45 GMT
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

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