lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
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
Right.

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 <gsingers@apache.org> 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
> https://svn.apache.org/repos/asf/lucene/board-reports/2011/special-board-report-may.txt
The board meeting is on May 19th.  I plan on attending.
>
> -Grant
> Lucene PMC Chair

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