Home | About | Sematext search-lucene.com search-hadoop.com
 Search Lucene and all its subprojects:

Switch to Threaded View
Mahout >> mail # dev >> Incorporating JIRA Suggestions, was Re: Demoralized over JIRA state


Copy link to this message
-
Re: Incorporating JIRA Suggestions, was Re: Demoralized over JIRA state
On 31.10.2011 14:19, Grant Ingersoll wrote:
> OK, I added a "Backlog" version to JIRA.  We should be able to just bulk mark items for that now.
>
> Note, also that JIRA has support for marking items as "Brainstorming", etc. when putting in issues.
>
> I also took the liberty of marking some issues as "MAHOUT_INTRO_CONTRIBUTE" meaning I think they are good introductory items that someone might take on if they wish to start contributing, but are unsure of where to start.  You can see them at: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+MAHOUT_INTRO_CONTRIBUTE.  Perhaps others can do so as well?  I've also added that to the wiki.

Great!

> -Grant
>
> On Oct 26, 2011, at 12:17 PM, Jeff Eastman wrote:
>
>> +1 on the backlog comments. I think a good backlog is an important way to establish direction and to measure velocity. But working on everything in the backlog in parallel is not what I'm advocating. Clearly, defect JIRAs ought to be given highest priority and fixed asap. If we could develop a very few, maybe quarterly, "epic stories" to guide our development efforts and focus on getting a few forward-looking JIRAs completed before beginning new ones, then I think the current sprawl could be contained and directed. In the spirit of continuous integration which we are practicing, it should be possible to have a point release quarterly too. I've used Scrum in a number of day jobs and it works pretty well.
>>
>> I think it has something to offer here too.
>> Jeff
>>
>>
>> -----Original Message-----
>> From: Benson Margulies [mailto:[EMAIL PROTECTED]]
>> Sent: Tuesday, October 25, 2011 4:23 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: Demoralized over JIRA state
>>
>> I've been thinking a bit more about JIRA usage.
>>
>> I would characterize my beef with long-running JIRAs under two
>> headings: project management and practical coding issues.
>>
>> I have a fairly visceral reaction to large numbers of open JIRAs. My
>> first reaction is that a giant list of them is, ipso facto, evidence
>> of a dysfunctional project (ASF or otherwise).
>>
>> In some respects, this is pretty funny, since at my day job we
>> endeavour to use Agile/Scrum, and a giant pile of open JIRAS (a/k/a
>> the backlog) is absolutely par for the course. I did manage to get
>> myself publicly chewed out by a 'certified Agile expert' for my lack
>> of ideological purity.
>>
>> A compromise that appeals to me is to try to be very disciplined at
>> keeping track of the JIRAs that are *defects*, and, if possible, even
>> arrange for the front-page view of the project to highlight the open
>> defects and open issues chosen for the upcoming release rather that
>> the total open JIRAs.
>>
>> As for the practical issues, I've already elaborated them in the
>> discussion of how to have maturing patches be in source control
>> instead of (or in addition to), so I won't repeat (much).
>
> --------------------------------------------
> Grant Ingersoll
> http://www.lucidimagination.com
>
>
>
>