lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <>
Subject Re: Special Board Report for May 2011
Date Wed, 04 May 2011 23:26:25 GMT
+1 to all of these.

The amazing thing to me is that Lucene of all projects is having problems
like this.  Lucene has always been my primary example of Open Source Done

I very much hope that it comes back to those roots.  The people who
contribute to Lucene are too good a group to have these problems.

On Wed, May 4, 2011 at 3:40 PM, Grant Ingersoll <> wrote:

> Due to the recent incidents related to committers reverting others patches
> and the ongoing discussion/impasse around modularizing Solr as well as the
> Solr TLP vote, the Board has asked the PMC to provide a special report as to
> the status of the community and what constructive things we are doing to
> make sure we are moving forward in a positive way.  While I don't agree with
> the severity that some people take on this, I do think we should have an
> open discussion on what we value and how we can all be more respectful of
> each other and how we can move forward in a positive way.
> This thread is to welcome your suggestions on how we might improve things
> to make the community stronger.  I am not interested in and will not
> entertain a rehashing of the disagreements.  Go participate on the other
> threads if that is what you are interested in.  This thread is about what we
> are doing to move forward as a community that primarily outputs two
> products:  Apache Lucene Core and Apache Solr.
> At our core, this means we are supporting a set of libraries that can be
> used for search and related capabilities across a lot of different
> applications ranging in size and shape, as well as a server that makes those
> capabilities available and easy to consume without requiring Java
> programming for those who choose to use it.  Our goal has always been to
> make the parts we like to work on as fast, efficient and capable as
> possible.    As with all open source projects, anyone should be able to
> contribute where they see fit and to "scratch their itch".  Open source has
> always been evolutionary in code development, not revolutionary.
> I will throw out some ideas as possibly helpful in continuing to build a
> strong community, but maybe they aren't.  And, no, I don't think any one of
> these solves everything.
> 1. No more IRC for design decisions (answering user questions is OK, IMO)
> even if they are captured on JIRA.  Either that or we should make IRC logged
> and public and part of the public record on Lucene/Solr.    The fact is,
> most mailing list subscribers are not on IRC and IRC discussions/decisions
> rob many of us of the opportunity to participate in the design and it
> sometimes come across that everything is done by the time it hits JIRA.
>  It's also very hard for people who aren't on IRC to get the full gist of
> the discussion if only a summary is presented in JIRA.  Also, due to time
> zones, many people are asleep while others are working. IRC also prevents
> ideas from "breathing" a bit.  Also, since IRC isn't logged, there is less
> decorum/respect at times (even if I think the banter keeps things lighter
> most of the time) and even though most of us committers are friends,
> outsiders or potential contributors may not see sarcasm or jokes in the same
> way that the rest of us who know each other do.
> 2. I think we need to prioritize getting patch contributors more feedback
> sooner.  I think some of this can be automated much like what Hadoop has
> done.  This should help identify new committers sooner and encourage them to
> keep contributing.
> 3. As a core principal, design discussions, etc. should not take place on
> private emails or via IM or phone calls.  I don't know how much of this
> there is, but I've seen hints of it from a variety of people to know it
> happens.  Obviously, there is no way to enforce this other than people
> should take it to heart and stop it.
> 4.  I think it goes w/o saying that we all learned our lessons about
> committing and reverting things.  Reverting someone else's code is for when
> things break the build, not for political/idealogical reasons.
> 5. People should commit and do their work where they see fit.  If others
> have better ideas about refactoring them, then step up and help or do the
> refactoring afterwards.  It's software.  Not everything need be perfect the
> first time or in just the "right location" the first time.  At the same
> time, if others want to refactor it and it doesn't hurt anything but ends up
> being better for more people b/c it is reusable and componetized, than the
> refactoring should not be a problem.
> So, what other ideas do people have?  I'll leave this thread open for a
> week or so and then add what we think are good things to
The board meeting is on May 19th.  I plan on attending.
> -Grant
> Lucene PMC Chair

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message