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 <gsing...@apache.org> > Date: May 4, 2011 6:40:03 PM EDT > To: general list <general@lucene.apache.org> > Subject: Special Board Report for May 2011 > > 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
