[LANG] JIRA management

[Henri Yandell <fl...@gmail.com>]

So the current management process in JIRA is a bit rusty, but is intended
to be (as in I used to do it that way but no reason why anyone else should):

New issue comes in (Version Unscheduled)
We assign it to a future version. We use 3.2 for 'yes, soon' and 3.x for
'later'.
It gets done with said future version

I've the urge to change that.

Take this issue:

https://issues.apache.org/jira/browse/LANG-903

It's a feature request. It has no patch or code. It's a great 'someone
please code'.

I still like the triage notion of a new issue coming in and being looked
at. As it is, I'm not interested personally and so I want to put it into a
'anyone wanna code' bucket.

So I'm thinking of a version called:

'Feature Request'

We could also have 'Patch For Review'.

We still have 2.7, 3.2 and 4.0, but we ditch the .x versions.

I think that would make our backlog of issues clearer. Here's the new
stuff. Here's the stuff that needs coding. Here's the stuff that needs
reviewing. Here's Bucket X of other stuff (bugs? chores like fixing the
site?).

What do others think?

Hen

Re: [LANG] JIRA management

[Henri Yandell <fl...@gmail.com>]

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 <be...@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 <fl...@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 <fl...@gmail.com>
> wrote:
> >
> > >
> > >
> > >
> > > On Mon, Oct 14, 2013 at 8:56 AM, Benedikt Ritter <britter@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
> > >
> > >
> >
>

Re: [LANG] JIRA management

[Benedikt Ritter <be...@gmail.com>]

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 <fl...@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 <fl...@gmail.com> wrote:
>
> >
> >
> >
> > On Mon, Oct 14, 2013 at 8:56 AM, Benedikt Ritter <britter@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
> >
> >
>

Re: [LANG] JIRA management

[Henri Yandell <fl...@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 <fl...@gmail.com> wrote:

>
>
>
> On Mon, Oct 14, 2013 at 8:56 AM, Benedikt Ritter <br...@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
>
>

Re: [LANG] JIRA management

[Henri Yandell <fl...@gmail.com>]

On Mon, Oct 14, 2013 at 8:56 AM, Benedikt Ritter <br...@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

Re: [LANG] JIRA management

[Benedikt Ritter <br...@apache.org>]

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 <fl...@gmail.com>

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

Re: [LANG] JIRA management

[Henri Yandell <fl...@gmail.com>]

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

Re: [LANG] JIRA management

[Emmanuel Bourg <eb...@apache.org>]

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.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org