Re: Demoralized over JIRA state

[deneche abdelhakim <ad...@gmail.com>]

If you decide on removing Watchmaker, let me do it please. I think they may
be some dependencies between mahout.ga and mahout.df

On Wed, Oct 26, 2011 at 5:17 PM, Jeff Eastman <je...@narus.com> 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:bimargulies@gmail.com]
> Sent: Tuesday, October 25, 2011 4:23 PM
> To: dev@mahout.apache.org
> 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).
>