+1, this seems like the right next step.
A few more observations on building a community... it can sometimes be
counterintuitive:
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
community.
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.
Once
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
community.
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.
Mike
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.
