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.
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. Benedikt 2013/10/14 Henri Yandell <flame...@gmail.com> > On Mon, Oct 14, 2013 at 1:19 AM, Emmanuel Bourg <ebo...@apache.org> wrote: > > > Le 14/10/2013 08:06, Henri Yandell a écrit : > > > > > What do others think? > > > > I quite like triaging the feature requests with a 'n.x' version and a > > '(n+1).0' version. The former indicates that the request can be > > implemented in a compatible manner, and the latter indicates this can't > > be done without a major release. > > > > > The pain I'm finding with that is that quickly it turns into a big bucket > of n.x. I liked it at first, but it's become a backlog bucket (I'd argue > 2.x, 3.x and 4.x are all one backlog bucket as the true test of their > version will only be when the code is complete). The issues come in, end up > in a bucket, and stay there. A smart user opens their issue against the > next version and has a 50/50 chance of it getting in. > > Better I think to treat it like a pipeline. New issue, accepted, code > needed, review needed, committed (against version 3.2 etc). I could imagine > others - test needed is a common one for us and might be worth its own > section. Perhaps 'research needed' for the nearly complete code that has > some weird item or the bug that needs figuring out. > > Hen > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
