"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 <[email protected]> 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 <[email protected] > >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 <[email protected] > > >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 <[email protected]> > > > 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 <[email protected]> > > > > 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 <[email protected]> > > > > 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. > > > > > > > > > > > > > > > > > > > >
