commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [LANG] JIRA management
Date Mon, 14 Oct 2013 15:56:54 GMT
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 <flamefew@gmail.com>

> On Mon, Oct 14, 2013 at 1:19 AM, Emmanuel Bourg <ebourg@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message