On Oct 24, 2011, at 3:25 AM, Sean Owen wrote: > (Dan on your particular issue -- I actually don't know how to do it > either. I don't know the details of Confluence and/or the wiki. Does > anyone?) > I'll finish off issues 834 and 839 for you as best I can see. > > Grant to your question about what I think we should do -- it's 'shrink > the zoo', clean up, and save broader work for "Mahout2". >
OK, got that so far, but that is pretty broad and is not at all actionable. What's the next layer down? 1. Watchmaker 2. Unify the Naive Bayes packages such that the up front text work is moved out or gone away with. > For 0.6, my asks are: > > - Please help me clean out JIRA by closing a lot of the old issues > that we should admit won't happen. If it's not related to core, > existing algorithms, if it's not a bug fix, polish, it should be > WontFix, because it's not happening before 1.0, which is nearly > forever away, still. > - (A mild request to please fix what you can in JIRA; I've fixed > anything I feel remotely capable of.) > - Once we're down to perhaps less than 10 issues for 0.6, everyone > have a go at filing a couple important clean-up to-dos that you can > commit to complete within a month. > - Anything that isn't fixed by December is WontFix and we release 0.6. > > I realize it's drastic, but it's a coherent position. Not at all drastic and perfectly sane. > > > On Sun, Oct 23, 2011 at 11:29 AM, Dan Brickley <[email protected]> wrote: >> [snip] >> >> Interesting discussion, and maybe a good time for those of us making >> use of all this code to remember to say 'thanks'. So, er yeah, thanks. >> >> One thing I would like to bring up, as you talk this stuff through, is >> that there are a few of us on the periphery of Mahout development, >> e.g. who might have helped track down a bug or few, or suggested a >> patch, but who are more on the user side of the fence than core >> developers or "committer material". >> >> Maybe you can think about ways of making more use of us, or more >> targeted use? I guess the possibilities vary from case to case. For my >> part I've gone chasing into specific issues when they've stood between >> me and getting some job done, and that's hard to target. >> >> I've never quite felt sure how to feel about opening JIRAs here. I >> used it previously in a more corporate environment which set different >> expectations. With Apache/Mahout I always feel a bit guilty opening >> something I'm not likely to try fixing myself. >> >> Would you prefer us to keep some stronger sense of ownership / >> commitment when we raise them? Or maybe it's best to make sure >> everything is recorded in JIRA, even if there's no followup from the >> reporting party. >> >> Lemme see... >> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=danbri >> for examples ... >> Ok, I filed https://issues.apache.org/jira/browse/MAHOUT-804 "Each >> page in Mahout's Confluence Wiki has 2 URLs, with differing page >> styles and search behaviours" and it's just sat there, and I feel a >> bit like it comes over light pointless complaining; probably you all >> knew the wiki was a bit messy, and everyone's busy, so it doesn't >> really need a JIRA. There are a few other more technical JIRAs I've >> either opened or followed and could/should try to be a bit more >> disciplined about getting to closure. >> >> Are there less core pieces of work that can be pushed out to a wider >> group, e.g. around documentation? I know managing a pool of >> contributors itself takes time,but maybe a few more notes in >> https://cwiki.apache.org/MAHOUT/how-to-contribute.html could help >> spread the load? >> >> This query looks useful: >> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=resolution+%3D+Unresolved+AND+reporter+%3D+currentUser%28%29 >> >> (... so I've just taken the liberty of adding it into >> https://cwiki.apache.org/confluence/display/MAHOUT/How+To+Contribute ) >> >> It reminds me I opened these: >> * https://issues.apache.org/jira/browse/MAHOUT-839 "rowid job failing >> (when parsing options)" >> ... I submitted a patch but using the wrong APIs; it needs just a >> one-liner fix to close. On my "been meaning to..." list. >> * https://issues.apache.org/jira/browse/MAHOUT-834 "rowsimilarityjob >> doesn't clean it's temp dir, and fails when seeing it again" >> ... doesn't seem to be agreement on whether this is an issue. I've >> been wondering whether to make a patch. >> * https://issues.apache.org/jira/browse/MAHOUT-804 "Each page in >> Mahout's Confluence Wiki has 2 URLs, with differing page styles and >> search behaviours" ...is me talking to myself. Hard to know how to >> help here. >> >> So I don't want to de-rail discussion into the detail of these >> specific JIRAs; but rather to take them as example of what it's like >> to be a Mahout user and run into some issue, reported via mail or >> JIRA. The way things are framed now sort of sets things up for us to >> report a problem and then just wait for "you guys" to do the hard work >> of fixing it. Maybe there are some tricks for widening the workforce >> without creating a huge coordination and management burden for the >> core committers? >> >> cheers, >> >> Dan >> -------------------------- Grant Ingersoll http://www.lucidimagination.com
