cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Re: Proposal: Change JIRA to have bugs as "unassigned" by default
Date Thu, 19 Sep 2013 16:29:25 GMT
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

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 <> 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 <> 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.

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