Re: Proposal: Change JIRA to have bugs as "unassigned" by default
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 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 >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 > > 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 > > > 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 , 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. > > > > > > > > > > > > > >
Re: Proposal: Change JIRA to have bugs as "unassigned" by default
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 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 , 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. > >
Re: Proposal: Change JIRA to have bugs as "unassigned" by default
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 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 > 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 > > 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 , 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. > > > > > > > > >
Re: Proposal: Change JIRA to have bugs as "unassigned" by default
"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 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 >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 > >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 > > > 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 > > > > 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 , 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. > > > > > > > > > > > > > > > > > > > >
Re: Proposal: Change JIRA to have bugs as "unassigned" by default
On second thought, I don't know if I like this proposal. Right now, everything Android gets assigned to me. Most people don't think I'm a real person when this stuff gets assigned, or they instantly hate me because I spend my time triaging the bugs as they come in. We do need someone to go through, read these issues, close the poorly written ones that have duplicates (i.e. Everything to do with WebSQL that's not written by Peter, ironically). This chews up a lot of my time. What WOULD be good is if people would be more aggressive with the JIRA issues. Even if you don't have time to fix the issue, just pinging people and letting them know that we haven't forgot about them goes a long way. I think that leaving everything unassigned is going to make it look like we're abandoning Cordova, which isn't the case. That being said, we should rotate who handles the firehose. On Thu, Sep 19, 2013 at 8:36 AM, purplecabbage wrote: > 12 hours? > I think we have to wait longer before moving on a proposal. > > Sent from my iPhone > >> On Sep 19, 2013, at 7:29 AM, Andrew Grieve wrote: >> >> Okay, I've made the change. Let's try it out :) >> >> I think start/stop is good if you've actually started working on something, >> but it's different from "this new bug has been looked at by someone". >> >> >> >> >>> On Thu, Sep 19, 2013 at 2:51 AM, Anis KADRI wrote: >>> >>> What about the start/stop progress? >>> >>> On Wed, Sep 18, 2013 at 9:03 PM, Ian Clelland >>> wrote: +1 Also, if you are a component "owner", it's pretty simple in JIRA to add a dashboard widget that shows you all unassigned bugs in your component. Ian > On Wed, Sep 18, 2013 at 11:49 PM, Joe Bowser wrote: > > +1 >>>
Re: Proposal: Change JIRA to have bugs as "unassigned" by default
Leave it the way it was. Sent from my iPhone > On Sep 19, 2013, at 8:49 AM, Joe Bowser wrote: > > On second thought, I don't know if I like this proposal. > > Right now, everything Android gets assigned to me. Most people don't > think I'm a real person when this stuff gets assigned, or they > instantly hate me because I spend my time triaging the bugs as they > come in. We do need someone to go through, read these issues, close > the poorly written ones that have duplicates (i.e. Everything to do > with WebSQL that's not written by Peter, ironically). This chews up a > lot of my time. > > What WOULD be good is if people would be more aggressive with the JIRA > issues. Even if you don't have time to fix the issue, just pinging > people and letting them know that we haven't forgot about them goes a > long way. I think that leaving everything unassigned is going to make > it look like we're abandoning Cordova, which isn't the case. > > That being said, we should rotate who handles the firehose. > >> On Thu, Sep 19, 2013 at 8:36 AM, purplecabbage >> wrote: >> 12 hours? >> I think we have to wait longer before moving on a proposal. >> >> Sent from my iPhone >> >>> On Sep 19, 2013, at 7:29 AM, Andrew Grieve wrote: >>> >>> Okay, I've made the change. Let's try it out :) >>> >>> I think start/stop is good if you've actually started working on something, >>> but it's different from "this new bug has been looked at by someone". >>> >>> >>> >>> On Thu, Sep 19, 2013 at 2:51 AM, Anis KADRI wrote: What about the start/stop progress? On Wed, Sep 18, 2013 at 9:03 PM, Ian Clelland wrote: > +1 > > Also, if you are a component "owner", it's pretty simple in JIRA to add a > dashboard widget that shows you all unassigned bugs in your component. > > Ian > > >> On Wed, Sep 18, 2013 at 11:49 PM, Joe Bowser wrote: >> >> +1
Re: Proposal: Change JIRA to have bugs as "unassigned" by default
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 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 > 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 , 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. > > > > >
Re: Proposal: Change JIRA to have bugs as "unassigned" by default
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 , 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.
Re: Proposal: Change JIRA to have bugs as "unassigned" by default
12 hours? I think we have to wait longer before moving on a proposal. Sent from my iPhone > On Sep 19, 2013, at 7:29 AM, Andrew Grieve wrote: > > Okay, I've made the change. Let's try it out :) > > I think start/stop is good if you've actually started working on something, > but it's different from "this new bug has been looked at by someone". > > > > >> On Thu, Sep 19, 2013 at 2:51 AM, Anis KADRI wrote: >> >> What about the start/stop progress? >> >> On Wed, Sep 18, 2013 at 9:03 PM, Ian Clelland >> wrote: >>> +1 >>> >>> Also, if you are a component "owner", it's pretty simple in JIRA to add a >>> dashboard widget that shows you all unassigned bugs in your component. >>> >>> Ian >>> >>> On Wed, Sep 18, 2013 at 11:49 PM, Joe Bowser wrote: +1 >>
Re: Proposal: Change JIRA to have bugs as "unassigned" by default
Does JIRA have the "New" state for a bug? That might be another way to signal whether the bug has ever been looked at, if they begin as New and then we change them to Accepted or whatever it's called. Braden On Thu, Sep 19, 2013 at 10:29 AM, Andrew Grieve wrote: > Okay, I've made the change. Let's try it out :) > > I think start/stop is good if you've actually started working on something, > but it's different from "this new bug has been looked at by someone". > > > > > On Thu, Sep 19, 2013 at 2:51 AM, Anis KADRI wrote: > > > What about the start/stop progress? > > > > On Wed, Sep 18, 2013 at 9:03 PM, Ian Clelland > > wrote: > > > +1 > > > > > > Also, if you are a component "owner", it's pretty simple in JIRA to > add a > > > dashboard widget that shows you all unassigned bugs in your component. > > > > > > Ian > > > > > > > > > On Wed, Sep 18, 2013 at 11:49 PM, Joe Bowser > wrote: > > > > > >> +1 > > >> > > >
Re: Proposal: Change JIRA to have bugs as "unassigned" by default
Okay, I've made the change. Let's try it out :) I think start/stop is good if you've actually started working on something, but it's different from "this new bug has been looked at by someone". On Thu, Sep 19, 2013 at 2:51 AM, Anis KADRI wrote: > What about the start/stop progress? > > On Wed, Sep 18, 2013 at 9:03 PM, Ian Clelland > wrote: > > +1 > > > > Also, if you are a component "owner", it's pretty simple in JIRA to add a > > dashboard widget that shows you all unassigned bugs in your component. > > > > Ian > > > > > > On Wed, Sep 18, 2013 at 11:49 PM, Joe Bowser wrote: > > > >> +1 > >> >
Re: Proposal: Change JIRA to have bugs as "unassigned" by default
What about the start/stop progress? On Wed, Sep 18, 2013 at 9:03 PM, Ian Clelland wrote: > +1 > > Also, if you are a component "owner", it's pretty simple in JIRA to add a > dashboard widget that shows you all unassigned bugs in your component. > > Ian > > > On Wed, Sep 18, 2013 at 11:49 PM, Joe Bowser wrote: > >> +1 >>
Re: Proposal: Change JIRA to have bugs as "unassigned" by default
+1 Also, if you are a component "owner", it's pretty simple in JIRA to add a dashboard widget that shows you all unassigned bugs in your component. Ian On Wed, Sep 18, 2013 at 11:49 PM, Joe Bowser wrote: > +1 >
Re: Proposal: Change JIRA to have bugs as "unassigned" by default
+1
Re: Proposal: Change JIRA to have bugs as "unassigned" by default
+1 Simon Mac Donald http://hi.im/simonmacdonald On Wed, 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 , 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.
