incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Lucene.NET status
Date Fri, 11 May 2012 08:48:03 GMT
On 2012-05-10, Jukka Zitting wrote:

> On Thu, May 10, 2012 at 9:37 AM, Stefan Bodewig <> wrote:
>> On 2012-05-10, Jukka Zitting wrote:

>>> Your contribution report [1] shows some people who've contributed lots
>>> of patches but aren't committers yet. What's up with that?

>> Many of those contributions happened before Lucene.NET re-entered
>> incubation, the people have been let down back then and never came back
>> when Lucene.NET came back to life.

> That's a good reminder of the importance of bringing in new committers
> when you can. Without a constant stream of new people a project will
> eventually lose steam as existing committers lose interest or become
> otherwise occupied for whatever other reason.

Yes, absolutely.  This is something that's not only true for Lucene.Net
or just incubating projects.  I'm pretty sure some of our existing
projects have missed such opportunities as well.

In Lucene.Net's case I'm pretty sure the team will take the right steps,
they've been welcoming contributors warmly so far.

Not having added new people to the roster is the major (if not only)
obstacle to graduation from my POV.

> I've been involved with quite a few podlings with similar problems in
> attracting longer-term contributors. In my experience the best way to
> solve that problem is to change your mindset of expecting most such
> people to be just one-off contributors. If you instead treat them as
> your next new committers and engage with them as peers, many (though
> of course not all) will respond in kind and actually become more
> involved.

> Many developers, especially from commercial backgrounds, tend to treat
> such contributors as just users reporting a problem. A typical
> interaction goes like "What's the problem? Do you have a test case?
> OK, let me fix it (when I get around to it)." A better approach is
> something like "What's the problem? OK, here are some pointers to the
> relevant bits in code. How do you think this should be fixed?"

This is a really good advice and one that I (even after 10+ years around
here) should follow more often.  Thank you for stating it so clearly.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message