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

Reply via email to