From general-return-3201-apmail-lucene-general-archive=lucene.apache.org@lucene.apache.org Wed May 4 22:55:08 2011 Return-Path: X-Original-To: apmail-lucene-general-archive@www.apache.org Delivered-To: apmail-lucene-general-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 09D9034BC for ; Wed, 4 May 2011 22:55:08 +0000 (UTC) Received: (qmail 65639 invoked by uid 500); 4 May 2011 22:55:07 -0000 Delivered-To: apmail-lucene-general-archive@lucene.apache.org Received: (qmail 65602 invoked by uid 500); 4 May 2011 22:55:07 -0000 Mailing-List: contact general-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@lucene.apache.org Delivered-To: mailing list general@lucene.apache.org Received: (qmail 65590 invoked by uid 99); 4 May 2011 22:55:07 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 May 2011 22:55:07 +0000 Received: from localhost (HELO [10.0.0.77]) (127.0.0.1) (smtp-auth username gsingers, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 May 2011 22:55:07 +0000 From: Grant Ingersoll Content-Type: multipart/alternative; boundary=Apple-Mail-1--175009207 Subject: Fwd: Special Board Report for May 2011 Date: Wed, 4 May 2011 18:55:05 -0400 References: To: general list Message-Id: <7071075B-4607-4D5E-82F1-67E7402B645D@apache.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) --Apple-Mail-1--175009207 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I would also encourage people to review ASF principals, by-laws, etc: http://apache.org/foundation/faq.html http://apache.org/foundation/getinvolved.html http://apache.org/foundation/bylaws.html http://apache.org/foundation/how-it-works.html -Grant Begin forwarded message: > From: Grant Ingersoll > Date: May 4, 2011 6:40:03 PM EDT > To: general list > Subject: Special Board Report for May 2011 >=20 > 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. >=20 > 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. =20 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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-r= eport-may.txt The board meeting is on May 19th. I plan on attending. >=20 > -Grant > Lucene PMC Chair --Apple-Mail-1--175009207--