cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Proposal: Change JIRA to have bugs as "unassigned" by default
Date Thu, 19 Sep 2013 19:21:03 GMT
"Is it expected that the component owner does all the triage-ing?"
--> That is what I expected, but this may not work with multiple committers
and/or vacation schedules

Personally after a release I triage all issues (starting with component
iOS) regardless of assignment, mainly because some issues have no component
and are miscategorized, and I "unassign" stuff that I don't think I can
work on. This only works for me of course but does not communicate much to
others in the interim. I also try to triage issues that come in when I am
notified by JIRA through email.

Thus, I think the unassigned default is fine, component "owners" should
have a search filter for the "component == [platform] and assigned = '' "
for triage going forward I suppose.


On Thu, Sep 19, 2013 at 11:58 AM, Jesse <purplecabbage@gmail.com> wrote:

> My rationale was/is that this change will inevitably lead to a whiteboard
> state machine diagram where we overly define the lifetime of a
> defect/task/feature in jira. I was still half asleep though ...
>
> I am okay with the way it was, and the way it is now is fine too.
> Unassigned does makes sense for the more volatile repos.
>
> @purplecabbage
> risingj.com
>
>
> On Thu, Sep 19, 2013 at 11:49 AM, Steven Gill <stevengill97@gmail.com
> >wrote:
>
> > I think for plugins it should be unassigned by default seeing how it can
> > affect any/all platforms.
> >
> >
> > On Thu, Sep 19, 2013 at 10:35 AM, Lorin Beer <lorin.beer.dev@gmail.com
> > >wrote:
> >
> > > apology already posted, but I'll reiterate that 12 hours for a process
> > > change that affects all assignees is way to short, especially on a
> > project
> > > with contributors across the globe.
> > >
> > >
> > > On Thu, Sep 19, 2013 at 9:29 AM, Andrew Grieve <agrieve@chromium.org>
> > > wrote:
> > >
> > > > Sorry for jumping the gun - figured this would be an easy thing the
> > > change
> > > > back if people started -1ing. Also don't think we necessarily need
> all
> > > > components to work the same. I'm specifically only interested in the
> > > > components that I do triage on: Android, iOS, Mobile Spec, JS,
> Plugins.
> > > >
> > > > Jesse - What's your rationale for wanting it to stay the way it was
> > > before?
> > > > (I've changed the windows ones back)
> > > >
> > > > Joe - I also spend a lot of time triaging bugs as they come in. I've
> > been
> > > > doing it for many months now. I think it's fine for anyone to triage,
> > > > because often the best person to do so changes depending on the bug.
> I
> > > > actually think having an explicit triage step will make our project
> > seem
> > > > more alive, since people will see action taken on their bugs (adding
> an
> > > > assignee).
> > > >
> > > > Marcel - I like your JIRA states that you've listed out. I think it's
> > > > important for JIRA to contain this amount of state for the components
> > > that
> > > > have several people in different places working on them.
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Sep 19, 2013 at 12:09 PM, Marcel Kinard <cmarcelk@gmail.com>
> > > > wrote:
> > > >
> > > > > This sounds like a solution to workflow issue. But what is our
> > > workflow?
> > > > >
> > > > > So if I understand correctly, the proposal is that a new bug that
> is
> > > > > unassigned means it has not been triaged.
> > > > >
> > > > > What would Jira state be for the following:
> > > > > - triaged and nobody plans to work on it yet (low priority)
> > > > > - triaged and person X plans to work on it, but they haven't
> started
> > > yet
> > > > > (person X's to do list)
> > > > > - triaged and person X plans to work on it, and they have started
> (in
> > > > > progress)
> > > > >
> > > > > And do these states need to be captured in Jira or is that
> overkill?
> > > > >
> > > > > Is it expected that the component owner does all the triage-ing?
> > > > >
> > > > >
> > > > > On Sep 18, 2013, at 11:00 PM, Andrew Grieve <agrieve@chromium.org>
> > > > wrote:
> > > > >
> > > > > > Motivation:
> > > > > > It's impossible to know whether new bugs have been looked at
by
> the
> > > > > default
> > > > > > assignee.
> > > > > >
> > > > > > Rationale:
> > > > > > Setting it to <unassigned>, means new bugs will be obviously
> > > > "untriaged".
> > > > > > Once assigned, it will mean someone intends to work on it.
> > > > > >
> > > > > > This won't eliminate bugs that get assigned and then not fixed
> in a
> > > > > timely
> > > > > > fashion. I think that's okay though. It'll be an improvement
> > anyways.
> > > > >
> > > > >
> > > >
> > >
> >
>

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