One reason I like this, apart from the general visualization of the state of our todo group, is that it gives us a very nice way to point new contributors to potential work. We point them at the Code Needed version, with a strong expectation that the patch they provide will go in (as an issue we didn't agree with will have been closed, and ones needing more in depth working out will be in Needs Investigation).
It also gives us a group to go to when we're working out what cna go in 3.2 pre release; we look at the review needed group. Hen On Mon, Oct 14, 2013 at 5:04 PM, Henri Yandell <flame...@gmail.com> wrote: > > > > On Mon, Oct 14, 2013 at 8:56 AM, Benedikt Ritter <brit...@apache.org>wrote: > >> Hi Hen, >> >> anything that makes working through the issues easier is good. But I think >> i don't understand your proposal completely. Do you want to create a new >> version that is called "feature requests"? That would feel like >> duplicating >> information available as ticket type. >> >> > Not exactly. The JIRA Feature Request describes the type of ticket it is. > That ticket then goes through steps. Let me change my steps so they don't > overlap: > > * New issue (ie: Version is Unscheduled, so same as today) > * Code Needed > * Tests Needed (imagining the patch is missing code) > * Review needed > * 3.2 (if for example the code went into 3.2) > > Perhaps also: > > * Needs investigation > > >> As far as I understand you're describing a ticket life cycle. I though >> jira >> was so super flexible that you can model this kind of stuff with it. > > > Yes, but typically you need extra permissions and it's pain in the arse to > maintain when upgrading. I avoid such stuff :) > > Hen > >
