Hola, My take on this is fairly simple: - Have a publicly-visible and up-to-date todo list (be it a wiki page or whatever) - Encourage contributions from new people whenever and however possible. If someone seems clueful, encourage them to submit easy patches and commit the patches for them. Get them involved however possible. - Be open, be inviting, be welcoming...
You shouldn't explicitly NOT do something in order to give someone else a chance to do it -- there will always be enough work. If the above are consistently done, the chances of a dynamic community are good, and even if there are no new committers over the next few months, you've established the you understand the Apache Way and have an open community. Yoav On 3/13/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > On 3/14/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > > > : > An approach to this would be for the CNET developers to back off on > > : > the commits (even though they are faster/more experienced at them) and > > : > let others step up. > > > > in general that seems really counter intuative to me, but i think Doug's > > right on the money... > > the reasoning behind that was to let others have a chance of fixing > things.. for example when a bug is mentioned on the list, you guys are > all over it. > anyways.. doug's way is probably a better approach.. my main reason > for posting was to get people thinking about this gate, and ways to > build up the community. The part i was trying to get to was to make it > easier for people to contribute... which you guys stated more clearly. > > > > > : I'd hate to see this. I think the key is to get more folks using it. > > : Contributions come from use. So the focus should be on attracting > > : users, rather than adding features. Missing features are opportunities > > : for new developers. You'll get users with a great out-of-box > > : experience, that does most (but perhaps not quite all) of what they want. > > > > So it seems like CNET folks should focus on making the existing > > functionality easier to use, and make it easier for developers who are > > less familar with the code base to add new featrues -- rather then adding > > new features ourselves. > > I don't know.. It's hard.. by adding more features you'll attract more > people as the product will be of greater use to them, but by adding > more features you'll also be raising the bar on the level of knowledge > required to contribute back to it (if you are not careful) > > So your point on making the code easier to use is spot-on. > maybe even documenting what kind of new features you think would be > great additions to Solr might help.. > > Maybe a wiki page saying all the ideas you guys have thought of but > haven't had time to implement. basically we're after getting a spark > created in a new-to-solr developer's head. > > > > > So things like the improving javadocs and unit testing of the existing > > code base are "good commits" for yonik and i to work on, because they will > > (hopefully) encourage other new developers to contribute. but adding new > > functinality (like a plugin supporting for faceted searching, or > > autoloading of data from a DB) are best left for future (non-CNET) > > commiters. > > > > is that what you had in mind Ian? > > ok.. let me be clear here.. CNET comitters are still very important to > the upkeep of the project, and new functionality from them would > always be great.. I'm not anti-cnet ppl (some of best friends are CNET > developers ;-) just that they need to leave some low hanging fruit so > that others can grab it. > > > > > > > > > > > -Hoss > > > > > > > -- > [EMAIL PROTECTED] -- blog: http://feh.holsman.net/ -- PH: ++61-3-9877-0909 > > If everything seems under control, you're not going fast enough. - > Mario Andretti > -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com
