mahout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Eastman <>
Subject Re: Goals for Mahout 0.7
Date Tue, 14 Feb 2012 20:29:58 GMT

Just to be clear, I'm not advocating replacing the JIRA process with a 
new set of green-field goals. Rather, IMHO, having a small number of 
overarching goals for a release *could* help us focus our efforts 
(triage our feature JIRAs) and *might* suggest some missing JIRAs that 
would give that release more completeness, usability and "sizzle" in 
those few areas. Hopefully more completeness and usability and sizzle 
than we might otherwise obtain using a scattered, bottom-up approach.

It's the sort of release planning and priority setting I've observed 
product managers doing in my many past lives. Of course, fixing defects 
has a higher priority than adding new features, but giving each release 
some focus and coherence is a mark of a mature product program. An 80% 
solution in three areas is not as good as a 100% solution in one. At HP, 
we used to say "Do a few things well". We've been saying "Well, let's do 
a few more things" too long.

On 2/14/12 12:25 PM, Sean Owen wrote:
> When 0.6 was released, there was an all-time record of open JIRAs --
> something like 90-100 (I closed maybe 10 quickly.) It's just math:
> there is a certain level of interest and rate of new requests and
> issues. There is some level of committer time and energy available to
> work on them. The former is just getting larger and the latter is
> shrinking. Neither of these things are the problem per se, and neither
> is something to be fixed; you can't ask people to not have ideas or
> issues, and you can't tell people they should be contributing more
> here.
> But I do think it means that it's more urgent than ever to have some
> strategy to tackle the JIRA, rather than talk about more green-field
> plans. This has been discussed before, and there were ideas like new
> JIRA tags, but I don't think it's been more than some labeling of the
> problem. There haven't been new committers, and JIRA rot is
> discouraging new ones, which makes it worse.
> JIRA is really a symptom; there is just a lot of sprawl and cruft to
> the project that's not being talked about or addressed.
> I can't say don't write down any new plans in JIRA. I can only point
> out what's happened many times: big ideas go half implemented if at
> all. Writing them down isn't really useful work. Meanwhile, I can see
> ten JIRAs from new contributors that have been ignored, and, many new
> bug reports are avoidable, jsut symptoms of scattered un-unified code
> that was never refined. It won't be different if this cycle is
> repeated. It's not going to kill this project but it's not going to
> get out of AAA to the Major Leagues at this rate, and that is
> frustrating.
> Fortunately, I think this remains pretty solvable. More work on
> existing issues sure helps, but nobody can count on that. It's then a
> question of scope: narrowing scope to something maintainable, making
> that scope clear, turning down JIRAs that don't fit, focusing
> attention on actionable JIRAs that do. Yes, you have to be able to
> not-do things in a project as well as do things, even in open source.
> I think that scope is still large at "maintaining what exists already,
> and fixing it up". Since I think this is the only realistic approach
> to a next version, in this conversation I could not support anything
> approach that pretends to do five more things in the next version --
> at least not unless accompanied by some plan to address the
> contributions already in line in JIRA. It's not OK to be implicitly
> rejecting so much from the community by not planning to fix that first
> and foremost.

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message