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 <[email protected]> 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). >
