One of our top goals, in my mind, has to be speeding up our tests! I only wish I knew how given basic attempts at parallelism and Maven have failed miserably.
On Feb 14, 2012, at 3:29 PM, Jeff Eastman wrote: > +users@ > > 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. >> >> > -------------------------------------------- Grant Ingersoll http://www.lucidimagination.com
