On Oct 22, 2011, at 7:34 PM, Benson Margulies wrote: > When the board looks at the health of a community, one of the > questions it asks (or so I am told) is, 'Is the community responsive > to requests for assistance?'
I think we are, but of course we could be better. > > Now, the board's bar here is quite low. I'm not trying to suggest for > a moment that Mahout is in any danger of attracting unfavorable > attention. However, I think that this helps to motivate my zoological > metaphor. > > Every new algo added to Mahout is a potential driver of support > demand. This is true of all open source projects, but it's more true, > if you will permit the solecism, for a 'zoo' -- a library of related > but independent components -- than it is for a more monolithic > project. > > Today's really pretty patch is tomorrow's email thread dangling > without anyone to answer it. Of course, but it is also potentially the future of the project. Glass half full vs. half empty. > > The community, I think, has to strike a balance between accepting > contributions and its capability to support and maintain those > contributions. Github (or Apache Extras), as an alternative target for > 'one more algorithm' is necessarily a badge of shame, but perhaps just > a reflection of reality. Yes, we want to encourage contributors. > However, to abuse another analogy, there's a difference between adding > birds to the flock and getting visited by a cuckoo. > > Now, the more that the community succeeds in creating reusable cores > that get used to build many algorithms, the less expensive it is to > support another algo. At the same time, it validates the role of the > project as, primarily, providing the core, leaving some individual > algorithms to find their own home. > > Grant is a long-term veteran of Lucene, which is (im)famous for things > that hang out in patches forever. From some points of view, this is > perfectly sensible. From others, it's frustrating, confusing, or even > infuriating. There's something to be said, in my opinion, for a > relatively rapid triage into: I think about the only way this works (more active curation), IMO, is when a project has several full time committers. We aren't there yet. > > a) a proposed core change. Either the community likes the idea or not. > b) a completely new capability. Let it live in a 'contrib' region, > or at Extras, or Github, and see what happens to it. > > One way or the other, a patch in JIRA is a very clumsy place for > people to obtain and try out a proposed change. Branches (for core > changes) in svn are better. Branches in git (coming to Apache R?SN) > are better and far easier to maintain. For purely additive code, far > better to be sitting in source control someplace. Except we have the whole provenance question. How do you do this with contributors?
