[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
