To your point, this would be best as a JIRA workflow. It doesn't look like we get to edit that by default, so I'm thinking of using versions as a cheap method at first, then if it feels good I'll go work with Infra to figure out how to turn it into a workflow that other Commons components can choose. Unless Infra have my similar old habit of not liking such things to be messed with :)
Hen On Tue, Oct 15, 2013 at 10:35 AM, Benedikt Ritter <benerit...@gmail.com>wrote: > I still don't like the idea of abusing versions for this kind of stuff... > but if it's easier to manage with jira, then go for it. we should also add > a comment the the website so that people know where to start. > > > 2013/10/15 Henri Yandell <flame...@gmail.com> > > > 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 > > > > > > > > >
