lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Rutherglen <>
Subject Re: Special Board Report for May 2011
Date Thu, 05 May 2011 17:30:58 GMT
> Freedom to refactor/poach is the bread & butter of open source

True, however as noted, some of the morale damage has already been
done (over years).  If a company is trying to profit from the brand
'Solr' then refactoring clearly will cause consternation amongst it's
core constituents and investors.  It not only guts what's in the
brand, an announcement could (in the eyes of the constituents) 'scare'

The recent fracas looks like a fraternity hazing it's new member.  It
is indeed "hilarious" in many respects.

On Thu, May 5, 2011 at 5:27 AM, Michael McCandless
<> wrote:
> On Wed, May 4, 2011 at 6:40 PM, Grant Ingersoll <> wrote:
>> 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.
> +1
>> 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.
> -0
> Probably we should fork off a separate thread to discuss IRC?  But
> here's my quick take:
> I feel there are times when it's appropriate and time's when it's not
> and we should use the right tool for the job at hand.
> EG, the recent landing of the [very large] concurrent flushing (DWPT)
> branch was a great example where live collaboration was very
> helpful, I think.
> I completely agree that no decisions are made on IRC: "if it's not
> on the list, it didn't happen".  Discussions can happen and if that
> results in an idea, an approach, that suggestion gets moved to an
> issue / to the dev list for iterating.
>> 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.
> Big +1.  We should be using automation everywhere we can.
> But, really, we (as all projects do) need more devs.  Growing the
> community should be job #1 of all committers.
>> 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.
> +1
> Also, "big issues" should not be sent via private email to hand-picked
> people.  Send it to general@
>> 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.
> +1
> Add to this "no way!" list: committing without first resolving
> the objections raised by other committers.
> And also: 'don't walk away from discussions, especially "important"
> ones'.  Radio silence / silent treatment is not a good approach in the
> real world, and it's even worse in the open-source world.  Try always
> to bring closure, to heal the community after strong disagreements.
>> 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.
> +1, progress not perfection, as long as we are free to refactor.
> Freedom to refactor/poach is the bread & butter of open source.
>> 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.
> How about also "PMC members will be more proactive in tackling issues
> that erode the community?  I think this would start with a thread on
> general@.  We need to get in the habit of discussing even tiny
> elephants as soon as they appear, somehow.
> Here's an example: "Is Lucid abusing their too-strong influence over
> Lucene/Solr"?  It's a great question, and I personally feel the answer
> today is "no", but nevertheless we should be able to discuss it and
> similar could-be-controversial topics.
> Maybe IRC is another example...
> I think PMC should strongly encourage anyone in the community to
> ask us to address even the slightest problems.
> As a community we must be able to discuss *anything*, no matter how
> diverse the opinions, how controversial the topic.  It's like a
> marriage: in a healthy marriage, the two people are able to discuss
> any topic.  In an unhealthy one, there are taboo topics that must be
> avoided.  We have to strive for a healthy marriage here...
> We (Lucene PMC) really still need to prove to the board that, 1) we
> have resolved this current problem, and 2) we are equipped, going
> forward, to resolve future problems better than our handling of this
> one.
> Mike

View raw message