lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: [DISCUSS] Archive Lucy
Date Tue, 10 Mar 2009 14:06:38 GMT

+1, this seems like the right next step.

A few more observations on building a community... it can sometimes be

For example, the fact that Marvin is so incredibly responsive whenever
issues are raised on the KS lists can prevent community growth.
If he held back a bit, giving others the chance & motivation to answer
other user's questions, this'd help spread things out and grow the

Also: code need not and should not be perfect before entering
SVN.  It's fine to accept some dirt, as long as the code is net/net an
overall step in the right direction -- it's progress not perfection.   
it's in the limelight, people will see the dirt and fix it with time,
which grows the community.  If it comes in nearly perfect there's
nothing to do... and the more perfect the code is, the less people
have to come out and ask for help.

Lucene has all sorts of interesting warts, odd defaults, a wide
plethora of APIs and packages that have changed with time, and are
scattered between core/contrib and are at different levels of
maturity, etc., etc., all of which provides great "fodder" for a

When a new user makes a contribution you should bend over backwards to
help get that in and then keep them involved.  Respond quickly, be
energetic, don't worry about the dirt, just get it in (if it's overall
a step forward)... because that's a chance to grow the community which
is far more valuable than growing the code.

I for one would love the see the current Lucy code checked in, even if
it's not done yet, has some dirt, etc.  Put big comments at the top
with the current status and your known TODOs.  Then make fixes over
time incrementally, publicly.


Grant Ingersoll wrote:

> +1.  I don't see any point in rushing it either, but I don't feel  
> like we are, other than the sense that some decision needs to be  
> made based on this thread.  Like I said before, this conversation  
> isn't news to those who are involved.  I'm totally fine w/ giving  
> the benefit of the doubt, I trust Marvin is working on it, but  
> likely needs a reminder of how Apache projects work.
> I'd _suggest_ a few other things beyond just code commits, however:
> 1. When discussing ideas on java-dev, at least send a message to  
> lucy-dev saying "See thread X on java-dev" (however, please don't  
> cross-post).  Do this religiously.  At some point, after you start  
> seeing Lucy members commenting on java-dev, you will realize you  
> have enough of a group to sustain the conversations on lucy (or,  
> even general; General is likely a good place for cross-fertilization  
> too) at which point you will likely be sending a msg to java-dev  
> saying, "hey check out lucy-dev for a great conversation on X"
> 2. Update the website to show a current status and/or post some news.
> 3. Move beyond the "Eventful and I" are figuring out this stuff and  
> start thinking in terms of how you can build community in Lucy.  As  
> should be clear now, Apache is more than just code.  Code can be  
> stored in a number of places (SF, Google, etc.).  Apache is about  
> building community around code.
> 4. Related to #3: Actively start searching for replacements for Doug  
> and Dave (hint, I think you have two volunteers on this thread  
> already).   Keep in mind the litmus test for an Apache project:  
> Would this project survive a committer leaving?  In the short term,  
> we know the answer is no, but in the long term the answer must be  
> yes.  Try to figure out some specific areas you could get help.   
> Sign up to be a mentor for GSOC and try to get a student to help  
> out.  Blog/Twitter/Whatever about Lucy and what you are up to.  In  
> short, start promoting Lucy as Lucy, not as some offshoot of KS.
> 5. Try to think in terms of how KS can leverage Lucy and less in  
> terms of how Lucy can be extracted from KS at some point in the  
> future (which is very much the sense I get from reading the  
> responses).  In other words, even if you think people aren't capable  
> of doing the low-level grunt work you allude to in prior posts,  
> assume that any and everyone on the Lucy list does grok that stuff  
> and discuss it there.  I often don't understand everything some of  
> the guys on Mahout talk about, but it is a great learning place and  
> eventually it gets through my skull.
> Finally, six months or so does sound like the right time frame.
> HTH,
> Grant
> On Mar 9, 2009, at 6:06 PM, Doug Cutting wrote:
>> Grant Ingersoll wrote:
>>> Therefore, it is with some hesitation that I suggest we mothball  
>>> Lucy.
>> When committers are inactive for a year, we ask them if they'd like  
>> to be made emeritus.  Usually they either don't respond or they say  
>> yes. If they say "no" we give them the benefit of the doubt for a  
>> while longer.  A similar process is followed for Apache members  
>> who've been inactive.  Inactivity should not be punished: we're all  
>> volunteers.
>> If there's a decent chance that Lucy will become active soon then  
>> we don't want to further burden that.  Marvin has argued that  
>> there's a strong chance Lucy will become active soon.  I'm inclined  
>> to give him the benefit of the doubt for another six months or so  
>> before we do anything that would be nontrivial to reverse.
>> So if "mothballing" would be easy to reverse, it might be okay.  We  
>> could just, e.g., change the website to say, "inactive", remove the  
>> website from the TLP's website and remove commit privileges, but  
>> not remove accounts, mailing lists or JIRA instances.  Then  
>> reversal would take about 10 minutes of the PMC chair's time.   
>> Marvin or others could petition this list to have it reversed.
>> But I'd also be fine with putting the project on notice for a few  
>> months, with the understanding that if activity doesn't pick up  
>> soon, it will be mothballed, as outlined above.  Then, after  
>> mothballing, if nothing happens for a while longer, we remove it  
>> altogether.  At each transition we should invite discussion.  I  
>> don't see much point in rushing this.
>> This path does risk dragging out the pain, so we shouldn't go down  
>> it too lightly.  Marvin, do you expect you'll be actively  
>> committing code to Lucy over the next six months?  If so, I think  
>> we should give him that, if not, we should mothball now as outlined  
>> above.
>> Another analysis to consider: If Marvin came to us today and  
>> pitched Lucy, would we accept it as a single-committer subproject?   
>> If not, then we should mothball now.  If so, then we can give him  
>> the benefit of the doubt for a bit longer.
>> Note that, if we give notice now, and nothing happens in six  
>> months, that's likely to considerably reduce our patience.
>> Doug
>> P.S. I hereby resign as a Lucy committer.

View raw message