Re: [LANG] JIRA management
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.comwrote: 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
Re: [LANG] JIRA management
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
Re: [LANG] JIRA management
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] JIRA management
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
Re: [LANG] JIRA management
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
Re: [LANG] JIRA management
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
Re: [LANG] JIRA management
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.orgwrote: 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
