You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@lucene.apache.org by Grant Ingersoll <gs...@apache.org> on 2011/05/05 00:40:03 UTC
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
Fwd: Special Board Report for May 2011
Posted by Grant Ingersoll <gs...@apache.org>.
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 <gs...@apache.org>
> Date: May 4, 2011 6:40:03 PM EDT
> To: general list <ge...@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
Re: Special Board Report for May 2011
Posted by Simon Willnauer <si...@googlemail.com>.
On Sun, May 15, 2011 at 8:22 PM, Grant Ingersoll <gs...@apache.org> wrote:
> Lucener's,
>
> Thank you to everyone who has participated in this thread and the many others during this time. I know it's been heated at times as well as painful. I also know this is a pretty big and broad community and that we need to move forward in a positive way (which I firmly believe we are now doing).
>
> I have written up a draft of this board report at https://svn.apache.org/repos/asf/lucene/board-reports/2011/special-board-report-may.txt. I welcome your comments and changes. I intend to file this on Tuesday, May 17th, so please have all edits in by then. Also, if you are a committer or PMC Member, please check that I got your employment correct at the end of the report.
+1 thanks for writing this up!
simon
>
> Thanks again for your patience and your willingness to contribute.
>
> Cheers,
> Grant
Re: Special Board Report for May 2011
Posted by Grant Ingersoll <gs...@apache.org>.
Lucener's,
Thank you to everyone who has participated in this thread and the many others during this time. I know it's been heated at times as well as painful. I also know this is a pretty big and broad community and that we need to move forward in a positive way (which I firmly believe we are now doing).
I have written up a draft of this board report at https://svn.apache.org/repos/asf/lucene/board-reports/2011/special-board-report-may.txt. I welcome your comments and changes. I intend to file this on Tuesday, May 17th, so please have all edits in by then. Also, if you are a committer or PMC Member, please check that I got your employment correct at the end of the report.
Thanks again for your patience and your willingness to contribute.
Cheers,
Grant
Re: Special Board Report for May 2011
Posted by Doron Cohen <cd...@gmail.com>.
Michael McCandless wrote:
> ... "if it's not on the list, it didn't happen"...
This rule of thumb pretty much summarizes my opinion on proper use of IRC.
While using IM in various aspects of work and life I never yet connected to
Lucene's IRC channels.
Not sure if/when I will do that, as I am quite overwhelmed, at the
moment, with the amounts of communications in other channels.
But this does not mean it should not be used by others. I can appreciate the
advantages in speed etc. of IRC.
And, I trust each and any of us to identify the point in a discussion when
it becomes appropriate to move it from IRC to the list.
Doron
Re: Special Board Report for May 2011
Posted by Grant Ingersoll <gs...@apache.org>.
Fine with me. There was always resistance to it before.
On May 7, 2011, at 3:52 AM, Greg Stein wrote:
> I've seen several people note that "IRC is not logged". Fine. LOG IT.
>
> I see absolutely no reason for you guys not to set up logging for the
> channel that you use. We do this for Subversion development:
> http://colabti.org/irclogger/irclogger_logs/svn-dev
>
> If IRC is posing so much of a problem, then just log it. I saw a
> comment about civility on the channel. Well... if it is logged, then
> you may see that fixed. Discussions can then be referenced when it is
> brought to the dev list. And people can always refer back to the log
> to read about the nuances around some particular discussion.
>
> Seems to be a simple solution to me.
>
> Cheers,
> -g
>
> On Fri, May 06, 2011 at 10:17:07PM +0300, Shai Erera wrote:
>> bq. shall I say required reading?
>>
>> You should ! If only so that people don't miss that great article :)
>>
>> On IRC, I agree with Grant (and partly w/ Mike). IMO, we should scale down
>> the amount of discussion on IRC. While there are several advantages to IRC
>> (faster response time, easier to hash things out etc.), I think there are
>> several drawbacks:
>>
>> * As Grant mentioned, TimeZone -- IRC makes it hard for people to follow
>> discussions that happened while they were asleep
>>
>> * IRC is not logged
>>
>> * Even trying to follow discussions on IRC, the nature of the UI sometimes
>> makes it too hard. Many times I've seen two and more discussions happen
>> simultaneously, and the way the UI is constructed, they're all mixed with
>> each other. This is not so with email threads.
>>
>> * I myself have too many communication mediums I need to follow today: my
>> job's email and messaging system, Gmail (Lucene and other mailing lists, as
>> well as private stuff), phone, people stopping by for questions .. IRC is a
>> very busy and demanding channel. You're kinda expected to respond
>> immediately (which is why, I think, it's easier to hash things out -- the
>> response time is instantaneous). If you only want to follow, you must stay
>> tuned to it. If I turn on "flash the taskbar for new messages", it drives me
>> crazy. If I turn it off, I miss important discussions ... it's impossible
>> :).
>> With emails, I can prioritize things. At least, Gmail helps to some extent.
>> That that we now receive all JIRA emails under one thread is a great
>> progress too.
>> With emails, I can always go back when I have time, and re-read the
>> discussion. I can respond to it 2 days after the last email, and people will
>> immediately know what I respond about, because we can include quoted text.
>> And if people's memory is very bad, they can (at least in Gmail) scan
>> quickly previous messages. Hack ... I can do that 1 month after the email
>> was sent, and most people will be able to quickly pick up from where we
>> left. This is not so with IRC ...
>>
>> * Getting in the middle of a discussion is practically impossible on IRC. I
>> have nothing to read for reference (unless I had my IRC client open and I
>> turned on the 'logging' feature).
>>
>> * Is it really that easier to hash things out on IRC? I mean, the response
>> time is great, so you get answers really quick. But then, there are usually
>> only a handful of participants in that discussion, which makes hashing out
>> and agreeing much easier anyway. If the same group of people (usually <=3)
>> communicated in email, they'd hash things out in almost the same speed.
>> After all, IRC mandates they are all awake at the same time, so they could
>> also email each other in NRT :).
>>
>> * Imagine this discussion happening on IRC. Most of us would have been able
>> to pick only shards of it. At some point, maybe Grant or another PMC member
>> would 'summarize' the discussion to the list. The summary could be "we've
>> decided to not use IRC because email is better", followed by some points
>> he's able to pull back from his memory and maybe IRC log. Would *you*
>> (people reading this growing-by-the-minute note) want to get a summary like
>> that? Would you be satisfied?
>> I think that most of us wouldn't and all that would happen is that such
>> email would start its own thread, repeating mostly what have been said on
>> IRC, b/c people would want answers ...
>>
>> I'm not against IRC, don't get me wrong. I think it's useful b/c the
>> turnaround time is great. But we should not have so many discussions there,
>> as we do today. I don't know where to draw the line. I trust the great
>> people of this community to know when it's better to discuss something in
>> email. An example, if a new feature is being discussed, then it's ok if two
>> people want to hash few things out quickly, before they send a detailed and
>> organized proposal to the list -- the details to hash out are the initial
>> proposal's details. The rest should be followed on list, even if it means
>> slightly slower response time.
>>
>> Today's list and JIRA volume always look to me like the response time is
>> instantaneous. We have very active people from around the globe, so you have
>> a high chance receiving response in no time. In the worse case, it will take
>> a couple of hours, but I don't remember when did that happen (which is an
>> amazing thing !)
>>
>> Cheers,
>> Shai
>>
>> On Fri, May 6, 2011 at 8:35 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>
>>> More reading (shall I say required reading?). Benson does a good job of
>>> explaining some of the concepts around consensus and why we also should be
>>> primarily using mailing lists:
>>> https://blogs.apache.org/comdev/entry/how_apache_projects_use_consensus
>>>
>>> -Grant
>>>
>>> On May 5, 2011, at 10:10 AM, Grant Ingersoll wrote:
>>>
>>>>
>>>> I'd like to throw out another idea:
>>>>
>>>> I think we should standardize on rotating the PMC Chair every year. I
>>> think to date, there have been two Chairs: Doug and me. Back when Doug
>>> left, no one wanted to do it (both Hoss and I said we would if no one else
>>> wanted to) and so I took it on. For the most part, it's a thankless task of
>>> herding cats (albeit low volume, thankfully), despite the important sounding
>>> name that marketing types love. I would like us to share the burden across
>>> the PMC by rotating it on an annual basis. Many other ASF projects do
>>> exactly this and I think it removes any political pressure. Have I sold it
>>> enough? ;-) Besides, I just know others are dying to file board reports on
>>> a quarterly basis!
>>>>
>>>> More inline below...
>>>>
>>>> On May 5, 2011, at 8:27 AM, Michael McCandless wrote:
>>>>
>>>>> On Wed, May 4, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org>
>>> wrote:
>>>>>> 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.
>>>>
>>>> Agreed, but this dovetails w/ the use of IRC. I realize live collab is
>>> nice, but it discourages those who aren't "in the know" about the channel
>>> being used from ever contributing. Say, for instance, I'm interested in
>>> DWPT (DocWriterPerThread), how am I supposed to know that at 8 am EDT on May
>>> 5th (made up example), three of the committers are going to be talking about
>>> it on IRC? If there is email about it, then I can participate. Nothing we
>>> do is so important that it can't wait a few hours or a day, besides the
>>> fact, that email is damn near instantaneous these days anyway.
>>>>
>>>> Also, keep in mind that until about a year ago, most everything was done
>>> on the mailing list and I think we progressed just fine. Since then, dev@has almost completely dried up in terms of discussions (factoring out JIRA
>>> mails which have picked up -- which is good) and the large majority of
>>> discussion takes place on IRC. I agree, however, we should have the IRC
>>> discussion on another thread.
>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>
>>>>> 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.
>>>>
>>>> Yeah, I agree. The hard part for me, is I often feel like people on the
>>> outside make big deals about this stuff and don't get that even having the
>>> discussion is a very healthy sign. Besides the fact, that no one likes
>>> confrontation and uncomfortable topics. We also, I think, are all tired of
>>> endless debates that go on and on w/ no resolution. It's one of the big
>>> downsides (and, of course, upsides) to consensus based open source as
>>> opposed to the dictatorial approach.
>>>>
>>>>>
>>>>> 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.
>>>>
>>>> I hopefully would agree we are good stewards of the fact that we employ a
>>> good number of committers (but not nearly all the active ones), but I know
>>> some disagree. I do, however, think that the recent spat shows that we at
>>> Lucid are still free to speak our minds when it comes to open source, as
>>> clearly not all Lucid employees agree on the issue and were pretty outspoken
>>> about it. I firmly believe we baked this into the company from Day 1 and I
>>> consider it one of our best strengths, but of course, most can't see that
>>> from the outside. Does that mean we are perfect? Of course not, but I
>>> think we try to follow the ASF guidelines and show up as individuals. I
>>> also know we work pretty hard to mind the ASF TM policy, etc. (just ask our
>>> marketing folks how much I remind them.) I think we all realize that there
>>> would be no such thing as Lucid if it weren't for the ASF and for
>>> Lucene/Solr, so why would we want to hurt that?
>>>>
>>>> The fact is, every single committer here and a good number of
>>> contributors are paid to work on Lucene all day, (most) every day or have
>>> some other financial stake (i.e. via a book, consulting biz, etc.) Any of
>>> us could be accused of only acting in our own financial interest. At the
>>> end of the day, I like to think that instead, the cool thing is we all have
>>> a great opportunity to have our financial interests aligned with a great
>>> project that we like to work on.
>>>>
>>>> For the record, we have pretty diverse PMC and committer base. As I said
>>> in our Dec. 2010 Board Report, we are comprised of:
>>>> "[a] total to 17 PMC members from 12 different
>>>> companies, spanning the globe. The flagship Lucene/Solr
>>>> has 26 total committers from 20 different companies, again
>>>> spanning the globe."
>>>>
>>>> The only one that has changed since then is Robert has joined Lucid.
>>> Now, one can argue that some of those members from other companies are not
>>> active, but that isn't Lucid's fault. ASF development has always been about
>>> those who do the work and we do a fair amount of that. Those who are not
>>> active, should, ideally, leave on their own by stating they wish to go
>>> Emeritus. Beyond that, we have a pretty standard policy that inactive
>>> people are removed after 1 year of no activity. That has been the case
>>> since I joined Lucene way back when and I think makes sense.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
--------------------------
Grant Ingersoll
http://www.lucidimagination.com/
Search the Lucene ecosystem docs using Solr/Lucene:
http://www.lucidimagination.com/search
Re: Special Board Report for May 2011
Posted by Chris Hostetter <ho...@fucit.org>.
: consensus, at least speak up and say so) Do you have other suggestions?
: The Board Meeting is on the 19th and this report needs to be filled at
: least 2 days prior to that. Claims of thread fatigue, I am sure, are
: not going to go over well with the Board, so I suggest all PMC Members
: (as well as others) take some time to think about how to contribute to
: this report.
I haven't commented much on this thread because I have generally agreed
with the sentements, but as far as what specificly we should say in the
report... welll ... Quite frankly, I don't feel like there is very much
the PMC *officially* can do here.
As I see it, the only concrete problem demonstrated was that two
individuals attempted to revert/veto things inappropriately, and personal
tensions escalated.
(In my opinon) there is no evidence that the PMC (as a whole) handled
things in an inappropriate manner, because a Board member stepped in an
started laying down the law before anyone (else) on the PMC really had a
chance to even attempt to mediate the situation as an individual, let
alone for the entire PMC to formally act in a collective manner (concesus
takes more then 24 hours, and that's really the time frame we're talking
about here where the shit hit the fan)
Unless we want to vote to revoke commit bits here and now based on (as far
as i can remember) only one incident from each of the two individuals of
svn/veto missuse in long histories of productive contribution, the only
actionable steps i can think of moving forward is...
: 4. Write up lessons learned by all on commit/revert and
: scratching/itches and make sure newcomers and old timers alike
: understand how it works.
...and agree that moving forward, such behavior should result in the first
PMC member who notices starting an immediate DISCUSS thread to address the
situation and propose revoking commit/pmc karma
Unofficially: I think that by far the most important thing we can leran
from this experience, and the most productive thing we can all do to help
the community stay strong, is that everyone needs to make a concious
effort to chill, the fuck, out.
(but that probably isn't appropriate for a Board Report)
: 5. I gather, via lazy consensus from the other thread, that we are in
: agreement on refactoring and we have a way forward.
I agree, but again: i don't see how that's really relevant to the Board
Report. It's a discussion we had in the aftermath of some temper
tantrums, but it doesn't change what happen, nor does it have any impact
on what/how we can/should deal with potential conflicts like this in the
future.
-Hoss
RE: Special Board Report for May 2011
Posted by Steven A Rowe <sa...@syr.edu>.
On 5/12/2011 at 5:25 PM, Ryan McKinley wrote:
> funny, i did not even know about #lucene-dev
These two posts of mine (still) reflect my position on the issue:
Initial proposal here (3/17/2010 on java-dev@l.a.o): <http://www.lucidimagination.com/search/document/6c76ea7e22dcb29f/proposed_new_logged_irc_channel_lucene_dev#6c76ea7e22dcb29f>
Announcement here (4/15/2010 on java-dev@l.a.o): <http://www.lucidimagination.com/search/document/8cd16d980a1bbac3/lucene_dev_a_logged_irc_channel>
Steve
Re: Special Board Report for May 2011
Posted by Ryan McKinley <ry...@gmail.com>.
>
> As it stands now, we have the following concrete suggestions:
> 1. Log IRC -- from the looks of #lucene-dev, it appears that people have not migrated to the new logged version. To me, we really should just hook up the logger to #lucene and forget #lucene-dev ever existed. We should also put a note that the room is being logged. I am beginning to be of the mindset that any design/dev conversation that is not logged on IRC is the equivalent of a private conversation.
funny, i did not even know about #lucene-dev
+0, logging seems easy to do, but i don't think it really solves any
real problem. (i don't want to read through IRC logs to figure out
what we are thinking)
> 2. Rotate the Chair -- I would propose that this Report is my last official one and that the next Board meeting contains a resolution changing the chair.
+1
I will put myself way at the bottom of the list -- and thank Grant for
his work/effort to date.
> 3. Put in the automated patch checking system that Hadoop uses. Volunteers? Perhaps we can knock this out at Lucene Revolution?
> 4. Write up lessons learned by all on commit/revert and scratching/itches and make sure newcomers and old timers alike understand how it works.
> 5. I gather, via lazy consensus from the other thread, that we are in agreement on refactoring and we have a way forward.
I believe so -- a summary should be included in #4
> 6. Discourage private emails, phone calls, etc. as they relate to the project. I personally am starting to think that if there is wind of this happening more that it is not at all unreasonable to remove commit bits.
>
Not sure what this means -- perhaps it is a question of scale/subject.
There will always be private mail/phone/im conversations about dev,
but I agree that discussions about project direction etc should be
discouraged.
ryan
RE: Special Board Report for May 2011
Posted by Steven A Rowe <sa...@syr.edu>.
On 5/12/2001 at 4:30 PM, Simon Willnauer wrote:
> On 5/12/2011 at 8:36 PM, Grant Ingersoll wrote:
> > 1. Log IRC -- from the looks of #lucene-dev, it appears that people
> > have not migrated to the new logged version. To me, we really should
> > just hook up the logger to #lucene and forget #lucene-dev ever
> > existed. We should also put a note that the room is being logged. I am
> > beginning to be of the mindset that any design/dev conversation that is
> > not logged on IRC is the equivalent of a private conversation.
>
> I agree we should move the logger to #lucene - according to steven
> this is trivial so lets shoot for it.
It's trivial to actually do it: you just ask someone on the #irclogger channel, and they do it for you.
However, those who handle the logging (the people behind colabti.org) will only do it if the channel participants agree to it. The problem is that several committers on #lucene have expressed in the past that they don't want it to be logged. #lucene-dev exists as a workaround to this issue.
I personally will not ask for logging on #lucene unless we can demonstrate consensus on this issue.
Steve
Re: Special Board Report for May 2011
Posted by Simon Willnauer <si...@googlemail.com>.
On Thu, May 12, 2011 at 8:36 PM, Grant Ingersoll <gs...@apache.org> wrote:
> I'm not trying to be a pest here, but this conversation and this report is hugely important to the future of this Lucene PMC. So far, I see a sum total of 4 PMC members out of 20+ total PMC members weighing in here, as well as a few other community members, on proactive things to do to move forward.
>
> Are you all really in lazy consensus with what has been said so far? (hint: lazy consensus is not a good idea here, so, if you are in consensus, at least speak up and say so) Do you have other suggestions? The Board Meeting is on the 19th and this report needs to be filled at least 2 days prior to that. Claims of thread fatigue, I am sure, are not going to go over well with the Board, so I suggest all PMC Members (as well as others) take some time to think about how to contribute to this report.
>
> As it stands now, we have the following concrete suggestions:
> 1. Log IRC -- from the looks of #lucene-dev, it appears that people have not migrated to the new logged version. To me, we really should just hook up the logger to #lucene and forget #lucene-dev ever existed. We should also put a note that the room is being logged. I am beginning to be of the mindset that any design/dev conversation that is not logged on IRC is the equivalent of a private conversation.
I agree we should move the logger to #lucene - according to steven
this is trivial so lets shoot for it.
> 2. Rotate the Chair -- I would propose that this Report is my last official one and that the next Board meeting contains a resolution changing the chair.
+1
> 3. Put in the automated patch checking system that Hadoop uses. Volunteers? Perhaps we can knock this out at Lucene Revolution?
+1 we should get at least a proposal done. I have no idea how they did
it but I will try figuring out and start a mail on dev@l.a.o
> 4. Write up lessons learned by all on commit/revert and scratching/itches and make sure newcomers and old timers alike understand how it works.
I am not sure if we should make a big deal out of it - I think
everybody knows that it was a wrong reaction and we learned our
lesson. I think we should only mention our agreement that reverts
should only be done if voted etc.
> 5. I gather, via lazy consensus from the other thread, that we are in agreement on refactoring and we have a way forward.
this is my impression too! +1
> 6. Discourage private emails, phone calls, etc. as they relate to the project. I personally am starting to think that if there is wind of this happening more that it is not at all unreasonable to remove commit bits.
I don't know where this comes from but I don't think we are having
those conversations. can you explain where you get those impression
from?
Simon
>
> -Grant
>
>
> On May 7, 2011, at 6:47 AM, Michael McCandless wrote:
>
>> +1
>>
>> Mike
>>
>> http://blog.mikemccandless.com
>>
>> On Sat, May 7, 2011 at 6:41 AM, Simon Willnauer
>> <si...@googlemail.com> wrote:
>>> On Sat, May 7, 2011 at 9:52 AM, Greg Stein <gs...@gmail.com> wrote:
>>>> I've seen several people note that "IRC is not logged". Fine. LOG IT.
>>>>
>>>> I see absolutely no reason for you guys not to set up logging for the
>>>> channel that you use. We do this for Subversion development:
>>>> http://colabti.org/irclogger/irclogger_logs/svn-dev
>>>>
>>>> If IRC is posing so much of a problem, then just log it. I saw a
>>>> comment about civility on the channel. Well... if it is logged, then
>>>> you may see that fixed. Discussions can then be referenced when it is
>>>> brought to the dev list. And people can always refer back to the log
>>>> to read about the nuances around some particular discussion.
>>>>
>>>> Seems to be a simple solution to me.
>>> huge +1! IRC is so powerful we should not put it down just because we
>>> don't log the channel.
>>>
>>> We already have a logged channel #lucene-dev and its logged here
>>>
>>> http://colabti.org/irclogger/irclogger_logs/lucene-dev
>>>
>>> having tech discussion there should be ok I think and for major
>>> decisions we can still send a mail to dev@l.a.o referencing the
>>> discussion. I think we all have the discipline to do that right?
>>>
>>> I am moving there now... we should also eventually add this channel to
>>> the website and maybe mark #lucene as the user channel?
>>>
>>> Simon
>>>>
>>>> Cheers,
>>>> -g
>>>>
>>>> On Fri, May 06, 2011 at 10:17:07PM +0300, Shai Erera wrote:
>>>>> bq. shall I say required reading?
>>>>>
>>>>> You should ! If only so that people don't miss that great article :)
>>>>>
>>>>> On IRC, I agree with Grant (and partly w/ Mike). IMO, we should scale down
>>>>> the amount of discussion on IRC. While there are several advantages to IRC
>>>>> (faster response time, easier to hash things out etc.), I think there are
>>>>> several drawbacks:
>>>>>
>>>>> * As Grant mentioned, TimeZone -- IRC makes it hard for people to follow
>>>>> discussions that happened while they were asleep
>>>>>
>>>>> * IRC is not logged
>>>>>
>>>>> * Even trying to follow discussions on IRC, the nature of the UI sometimes
>>>>> makes it too hard. Many times I've seen two and more discussions happen
>>>>> simultaneously, and the way the UI is constructed, they're all mixed with
>>>>> each other. This is not so with email threads.
>>>>>
>>>>> * I myself have too many communication mediums I need to follow today: my
>>>>> job's email and messaging system, Gmail (Lucene and other mailing lists, as
>>>>> well as private stuff), phone, people stopping by for questions .. IRC is a
>>>>> very busy and demanding channel. You're kinda expected to respond
>>>>> immediately (which is why, I think, it's easier to hash things out -- the
>>>>> response time is instantaneous). If you only want to follow, you must stay
>>>>> tuned to it. If I turn on "flash the taskbar for new messages", it drives me
>>>>> crazy. If I turn it off, I miss important discussions ... it's impossible
>>>>> :).
>>>>> With emails, I can prioritize things. At least, Gmail helps to some extent.
>>>>> That that we now receive all JIRA emails under one thread is a great
>>>>> progress too.
>>>>> With emails, I can always go back when I have time, and re-read the
>>>>> discussion. I can respond to it 2 days after the last email, and people will
>>>>> immediately know what I respond about, because we can include quoted text.
>>>>> And if people's memory is very bad, they can (at least in Gmail) scan
>>>>> quickly previous messages. Hack ... I can do that 1 month after the email
>>>>> was sent, and most people will be able to quickly pick up from where we
>>>>> left. This is not so with IRC ...
>>>>>
>>>>> * Getting in the middle of a discussion is practically impossible on IRC. I
>>>>> have nothing to read for reference (unless I had my IRC client open and I
>>>>> turned on the 'logging' feature).
>>>>>
>>>>> * Is it really that easier to hash things out on IRC? I mean, the response
>>>>> time is great, so you get answers really quick. But then, there are usually
>>>>> only a handful of participants in that discussion, which makes hashing out
>>>>> and agreeing much easier anyway. If the same group of people (usually <=3)
>>>>> communicated in email, they'd hash things out in almost the same speed.
>>>>> After all, IRC mandates they are all awake at the same time, so they could
>>>>> also email each other in NRT :).
>>>>>
>>>>> * Imagine this discussion happening on IRC. Most of us would have been able
>>>>> to pick only shards of it. At some point, maybe Grant or another PMC member
>>>>> would 'summarize' the discussion to the list. The summary could be "we've
>>>>> decided to not use IRC because email is better", followed by some points
>>>>> he's able to pull back from his memory and maybe IRC log. Would *you*
>>>>> (people reading this growing-by-the-minute note) want to get a summary like
>>>>> that? Would you be satisfied?
>>>>> I think that most of us wouldn't and all that would happen is that such
>>>>> email would start its own thread, repeating mostly what have been said on
>>>>> IRC, b/c people would want answers ...
>>>>>
>>>>> I'm not against IRC, don't get me wrong. I think it's useful b/c the
>>>>> turnaround time is great. But we should not have so many discussions there,
>>>>> as we do today. I don't know where to draw the line. I trust the great
>>>>> people of this community to know when it's better to discuss something in
>>>>> email. An example, if a new feature is being discussed, then it's ok if two
>>>>> people want to hash few things out quickly, before they send a detailed and
>>>>> organized proposal to the list -- the details to hash out are the initial
>>>>> proposal's details. The rest should be followed on list, even if it means
>>>>> slightly slower response time.
>>>>>
>>>>> Today's list and JIRA volume always look to me like the response time is
>>>>> instantaneous. We have very active people from around the globe, so you have
>>>>> a high chance receiving response in no time. In the worse case, it will take
>>>>> a couple of hours, but I don't remember when did that happen (which is an
>>>>> amazing thing !)
>>>>>
>>>>> Cheers,
>>>>> Shai
>>>>>
>>>>> On Fri, May 6, 2011 at 8:35 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>
>>>>>> More reading (shall I say required reading?). Benson does a good job of
>>>>>> explaining some of the concepts around consensus and why we also should be
>>>>>> primarily using mailing lists:
>>>>>> https://blogs.apache.org/comdev/entry/how_apache_projects_use_consensus
>>>>>>
>>>>>> -Grant
>>>>>>
>>>>>> On May 5, 2011, at 10:10 AM, Grant Ingersoll wrote:
>>>>>>
>>>>>>>
>>>>>>> I'd like to throw out another idea:
>>>>>>>
>>>>>>> I think we should standardize on rotating the PMC Chair every year. I
>>>>>> think to date, there have been two Chairs: Doug and me. Back when Doug
>>>>>> left, no one wanted to do it (both Hoss and I said we would if no one else
>>>>>> wanted to) and so I took it on. For the most part, it's a thankless task of
>>>>>> herding cats (albeit low volume, thankfully), despite the important sounding
>>>>>> name that marketing types love. I would like us to share the burden across
>>>>>> the PMC by rotating it on an annual basis. Many other ASF projects do
>>>>>> exactly this and I think it removes any political pressure. Have I sold it
>>>>>> enough? ;-) Besides, I just know others are dying to file board reports on
>>>>>> a quarterly basis!
>>>>>>>
>>>>>>> More inline below...
>>>>>>>
>>>>>>> On May 5, 2011, at 8:27 AM, Michael McCandless wrote:
>>>>>>>
>>>>>>>> On Wed, May 4, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org>
>>>>>> wrote:
>>>>>>>>> 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.
>>>>>>>
>>>>>>> Agreed, but this dovetails w/ the use of IRC. I realize live collab is
>>>>>> nice, but it discourages those who aren't "in the know" about the channel
>>>>>> being used from ever contributing. Say, for instance, I'm interested in
>>>>>> DWPT (DocWriterPerThread), how am I supposed to know that at 8 am EDT on May
>>>>>> 5th (made up example), three of the committers are going to be talking about
>>>>>> it on IRC? If there is email about it, then I can participate. Nothing we
>>>>>> do is so important that it can't wait a few hours or a day, besides the
>>>>>> fact, that email is damn near instantaneous these days anyway.
>>>>>>>
>>>>>>> Also, keep in mind that until about a year ago, most everything was done
>>>>>> on the mailing list and I think we progressed just fine. Since then, dev@has almost completely dried up in terms of discussions (factoring out JIRA
>>>>>> mails which have picked up -- which is good) and the large majority of
>>>>>> discussion takes place on IRC. I agree, however, we should have the IRC
>>>>>> discussion on another thread.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> Yeah, I agree. The hard part for me, is I often feel like people on the
>>>>>> outside make big deals about this stuff and don't get that even having the
>>>>>> discussion is a very healthy sign. Besides the fact, that no one likes
>>>>>> confrontation and uncomfortable topics. We also, I think, are all tired of
>>>>>> endless debates that go on and on w/ no resolution. It's one of the big
>>>>>> downsides (and, of course, upsides) to consensus based open source as
>>>>>> opposed to the dictatorial approach.
>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> I hopefully would agree we are good stewards of the fact that we employ a
>>>>>> good number of committers (but not nearly all the active ones), but I know
>>>>>> some disagree. I do, however, think that the recent spat shows that we at
>>>>>> Lucid are still free to speak our minds when it comes to open source, as
>>>>>> clearly not all Lucid employees agree on the issue and were pretty outspoken
>>>>>> about it. I firmly believe we baked this into the company from Day 1 and I
>>>>>> consider it one of our best strengths, but of course, most can't see that
>>>>>> from the outside. Does that mean we are perfect? Of course not, but I
>>>>>> think we try to follow the ASF guidelines and show up as individuals. I
>>>>>> also know we work pretty hard to mind the ASF TM policy, etc. (just ask our
>>>>>> marketing folks how much I remind them.) I think we all realize that there
>>>>>> would be no such thing as Lucid if it weren't for the ASF and for
>>>>>> Lucene/Solr, so why would we want to hurt that?
>>>>>>>
>>>>>>> The fact is, every single committer here and a good number of
>>>>>> contributors are paid to work on Lucene all day, (most) every day or have
>>>>>> some other financial stake (i.e. via a book, consulting biz, etc.) Any of
>>>>>> us could be accused of only acting in our own financial interest. At the
>>>>>> end of the day, I like to think that instead, the cool thing is we all have
>>>>>> a great opportunity to have our financial interests aligned with a great
>>>>>> project that we like to work on.
>>>>>>>
>>>>>>> For the record, we have pretty diverse PMC and committer base. As I said
>>>>>> in our Dec. 2010 Board Report, we are comprised of:
>>>>>>> "[a] total to 17 PMC members from 12 different
>>>>>>> companies, spanning the globe. The flagship Lucene/Solr
>>>>>>> has 26 total committers from 20 different companies, again
>>>>>>> spanning the globe."
>>>>>>>
>>>>>>> The only one that has changed since then is Robert has joined Lucid.
>>>>>> Now, one can argue that some of those members from other companies are not
>>>>>> active, but that isn't Lucid's fault. ASF development has always been about
>>>>>> those who do the work and we do a fair amount of that. Those who are not
>>>>>> active, should, ideally, leave on their own by stating they wish to go
>>>>>> Emeritus. Beyond that, we have a pretty standard policy that inactive
>>>>>> people are removed after 1 year of no activity. That has been the case
>>>>>> since I joined Lucene way back when and I think makes sense.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>
>
>
Re: Special Board Report for May 2011
Posted by Grant Ingersoll <gs...@apache.org>.
On May 12, 2011, at 5:31 PM, Uwe Schindler wrote:
>>> I think the current state of logging only #lucene-dev is good.
>>
>> Yeah, except no one is on it other than a few people even though many of
>> them (committers that is) are on #lucene
>
> I haven't seen any technical discussions anymore on #lucene. I was
> discussing with simon and mike on #lucene-dev the past days and had some
> work going on for the IndexUpgrader tool and MergePolicies. The discussions
> were even linked on JIRA issues.
>
>>> I go to #lucene-dev now. I think only IRC channel(s) that are
> Lucene/Solr
>> internal development in nature need to be logged -- and that's just
> #lucene-
>> dev. So just because you have observed many developers are on #lucene
>> instead of #lucene-dev doesn't indicate a problem, so long as no design
>> decisions for Lucene/Solr take place on #lucene or #solr. #lucene and
> #solr is
>> where users get to ask questions, much like how it is on the user mailing
> lists.
>> So *if* (I don't know if it happens) internal Lucene / Solr design
> decisions are
>> taking place on #lucene or #solr then obviously that must stop. I'd rather
>> these channels not get logged so that we can have an expectation of a
> single
>> place for these discussions on IRC and have that place be clear of user
>> support questions.
>>>
>>> RE refactoring / modularization, it's good to finally see a sense of
>> agreement on how to move forward.
>
> Yeah that ok, I have nothing to add to that (and don't want anymore, it's a
> soap opera).
>
>>>> 3. Put in the automated patch checking system that Hadoop uses.
>> Volunteers? Perhaps we can knock this out at Lucene Revolution?
>
> Who logs the stuff there? In my opinion, a meeting on Lucene-Rev is also
> "private" - or is this different somehow? What's difference between a
> private talk between two or three people in a bar at Lucene Revolution
> without somebody writing down a log? A log can also be written if somebody
> else talks with me in a private Skype chat!
>
Point taken. For this particular thing at Revolution, I was just saying we could get the Patch checker implemented while in person and it would be logged b/c we write up how it works (which Nigel Daley has already on Builds and which I think I forwarded)
At any rate, you are right. We should just make sure we log things as appropriate. People have discussions all the time. The gist of the discussions and any proposals should be logged. Then it needs some time to be noticed before it is officially acted on, I guess. In other words, if two people get together on IRC and make a decision then it should be logged and they can say something like "I plan to commit this in a day or two" instead of simply committing it right then and there. Of course, for small stuff, use your judgment. I think we all get it, at this point, so I will stop beating the dead horse.
-Grant
Re: Special Board Report for May 2011
Posted by Mark Miller <ma...@gmail.com>.
On May 13, 2011, at 2:35 PM, Simon Willnauer wrote:
> I would appreciate it if we concentrate on relevant things
> again.
To someone it was relevant. Some of us had various opinions about it - but it was brought up and responded too and so had some relevance purely by those facts IMO - I don't think we should try to close the book on anything anyone wants to discuss. I found that discussion useful myself.
Spreading and communicating the Apache Way is part of what we should be doing.
- Mark Miller
lucidimagination.com
Lucene/Solr User Conference
May 25-26, San Francisco
www.lucenerevolution.org
Re: Special Board Report for May 2011
Posted by Simon Willnauer <si...@googlemail.com>.
On Fri, May 13, 2011 at 8:59 PM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> On Fri, May 13, 2011 at 2:50 PM, Chris Hostetter
> <ho...@fucit.org> wrote:
>
>> The point i'm trying to make is that none of these things are bad, and no
>> one is at fault for having these conversations in any of these places --
>> as long as they are just discussions, and brainstorming, and sharing of
>> opinions, etc... --- not attempts at making decisions off list.
>
> +1
thanks clear enought! thanks! +1
>
>> My secondary point: Even if we start logging IRC, it can not, and must
>> not, be used for making decisions about the project. An IRC log is not a
>> substitute for the mailing list.
>
> +1
>
> Mike
>
> http://blog.mikemccandless.com
>
Re: Special Board Report for May 2011
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Fri, May 13, 2011 at 2:50 PM, Chris Hostetter
<ho...@fucit.org> wrote:
> The point i'm trying to make is that none of these things are bad, and no
> one is at fault for having these conversations in any of these places --
> as long as they are just discussions, and brainstorming, and sharing of
> opinions, etc... --- not attempts at making decisions off list.
+1
> My secondary point: Even if we start logging IRC, it can not, and must
> not, be used for making decisions about the project. An IRC log is not a
> substitute for the mailing list.
+1
Mike
http://blog.mikemccandless.com
Re: Special Board Report for May 2011
Posted by Chris Hostetter <ho...@fucit.org>.
: > I don't give a fuck if IRC is logged, i don't give a fuck if someone took
: > minutes at a meetup, it's wrong -- it's not how things are done.
:
: Why are we discussing that? honestly, has it happen here in lucene land?
Sorry, i guess i kind of got side tracked from my point...
As far as i know, no decisions have been made unilaterally off list -- but
there has been a decent amount of rumblings about the inappropriateness of
private emails, and private discussions at peoples jobs, and people talking on IRC.
The point i'm trying to make is that none of these things are bad, and no
one is at fault for having these conversations in any of these places --
as long as they are just discussions, and brainstorming, and sharing of
opinions, etc... --- not attempts at making decisions off list.
My secondary point: Even if we start logging IRC, it can not, and must
not, be used for making decisions about the project. An IRC log is not a
substitute for the mailing list.
-Hoss
Re: Special Board Report for May 2011
Posted by Simon Willnauer <si...@googlemail.com>.
On Fri, May 13, 2011 at 8:20 PM, Chris Hostetter
<ho...@fucit.org> wrote:
>
> : > "private" - or is this different somehow? What's difference between a
> : > private talk between two or three people in a bar at Lucene Revolution
> : > without somebody writing down a log? A log can also be written if somebody
> : > else talks with me in a private Skype chat!
>
> There is absolutely no differnce.
>
> : reign in a little - but let's be honest - two developers getting
> : together and speeding through some stuff is no different than one dev
> : thinking through a lot on his own. You then bring it to the mailing list
> : since otherwise it didn't happen. Other than that, we are all big boys
>
> Exactly.
>
> There is nothing wrong, and has never been anything wrong, with large
> groups of people meeting in person to discuss lucene, or two people having
> private conversations about lucene, or talking about lucene on IRC.
>
> There is nothing wrong, and has never been anything worng, with large
> groups of people meeting in person to discuss technical changes to lucene,
> or two people having private conversations about technical cahnges to
> lucene, or talking about technical changes to lucene on IRC.
>
> There is nothing wrong, and has never been anything worng, with large
> groups of people meeting in person to discuss project planning/vision of
> lucene, or two people having private conversations about project
> planning/vision to lucene, or talking about project planning/vision of
> lucene on IRC.
>
> What is wrong, and what has always been wrong, is anyone, anywhere, making
> *decisions* about any of these things, that is not on the list.
>
> It doesn't matter how many committers/PMC members are involved, it doesn't
> matter if it's logged or not, if people have a discussion it's fine -- but
> if that discussion becomes a "decision" it's wrong. If two or more people
> on IRC (or at apachecon, or at a meetup, or standing by the water cooler
> at work) are chatting and agree that it would probably be a good idea to
> do X, Y, and Z that is fine -- as long as that is then sumiarzed in an
> email or jira issue and other people have a chance to way in and give
> their opinions.
>
> The moment someone says "it was decided on irc (or at apachecon, or at
> bar, or in a meeting) that we should do X, Y, and Z" that is wrong.
>
> I don't give a fuck if IRC is logged, i don't give a fuck if someone took
> minutes at a meetup, it's wrong -- it's not how things are done.
Why are we discussing that? honestly, has it happen here in lucene land?
Not that I know that we made decisions not mentioned on the list or in
jira! I would appreciate it if we concentrate on relevant things
again.
simon
>
>
>
> -Hoss
>
Re: Special Board Report for May 2011
Posted by Chris Hostetter <ho...@fucit.org>.
: > "private" - or is this different somehow? What's difference between a
: > private talk between two or three people in a bar at Lucene Revolution
: > without somebody writing down a log? A log can also be written if somebody
: > else talks with me in a private Skype chat!
There is absolutely no differnce.
: reign in a little - but let's be honest - two developers getting
: together and speeding through some stuff is no different than one dev
: thinking through a lot on his own. You then bring it to the mailing list
: since otherwise it didn't happen. Other than that, we are all big boys
Exactly.
There is nothing wrong, and has never been anything wrong, with large
groups of people meeting in person to discuss lucene, or two people having
private conversations about lucene, or talking about lucene on IRC.
There is nothing wrong, and has never been anything worng, with large
groups of people meeting in person to discuss technical changes to lucene,
or two people having private conversations about technical cahnges to
lucene, or talking about technical changes to lucene on IRC.
There is nothing wrong, and has never been anything worng, with large
groups of people meeting in person to discuss project planning/vision of
lucene, or two people having private conversations about project
planning/vision to lucene, or talking about project planning/vision of
lucene on IRC.
What is wrong, and what has always been wrong, is anyone, anywhere, making
*decisions* about any of these things, that is not on the list.
It doesn't matter how many committers/PMC members are involved, it doesn't
matter if it's logged or not, if people have a discussion it's fine -- but
if that discussion becomes a "decision" it's wrong. If two or more people
on IRC (or at apachecon, or at a meetup, or standing by the water cooler
at work) are chatting and agree that it would probably be a good idea to
do X, Y, and Z that is fine -- as long as that is then sumiarzed in an
email or jira issue and other people have a chance to way in and give
their opinions.
The moment someone says "it was decided on irc (or at apachecon, or at
bar, or in a meeting) that we should do X, Y, and Z" that is wrong.
I don't give a fuck if IRC is logged, i don't give a fuck if someone took
minutes at a meetup, it's wrong -- it's not how things are done.
-Hoss
Re: Special Board Report for May 2011
Posted by Mark Miller <ma...@gmail.com>.
On May 12, 2011, at 5:31 PM, Uwe Schindler wrote:
> Who logs the stuff there? In my opinion, a meeting on Lucene-Rev is also
> "private" - or is this different somehow? What's difference between a
> private talk between two or three people in a bar at Lucene Revolution
> without somebody writing down a log? A log can also be written if somebody
> else talks with me in a private Skype chat!
+1. If it didn't happen on the mailing list, it didn't happen. To me, that does not mean we must not discuss Lucene/Solr together off list here and there. This is just one of those lines I think most people understand to a degree. Perhaps we should do a little self check and reign in a little - but let's be honest - two developers getting together and speeding through some stuff is no different than one dev thinking through a lot on his own. You then bring it to the mailing list since otherwise it didn't happen. Other than that, we are all big boys and I think we can self regulate. It starts getting into fuzzy territory of sub groups regularly meeting or something - but like I said - I think everyone largely gets it. Personally I've found enough to make it to JIRA issues to be satisfied. If I thought something was missing, I'd ask for more detail about the issue. I don't see others doing that much, but perhaps I've missed it. You want to curate JIRA issues well in either case.
- Mark Miller
lucidimagination.com
Lucene/Solr User Conference
May 25-26, San Francisco
www.lucenerevolution.org
RE: Special Board Report for May 2011
Posted by Uwe Schindler <uw...@thetaphi.de>.
> > I think the current state of logging only #lucene-dev is good.
>
> Yeah, except no one is on it other than a few people even though many of
> them (committers that is) are on #lucene
I haven't seen any technical discussions anymore on #lucene. I was
discussing with simon and mike on #lucene-dev the past days and had some
work going on for the IndexUpgrader tool and MergePolicies. The discussions
were even linked on JIRA issues.
> > I go to #lucene-dev now. I think only IRC channel(s) that are
Lucene/Solr
> internal development in nature need to be logged -- and that's just
#lucene-
> dev. So just because you have observed many developers are on #lucene
> instead of #lucene-dev doesn't indicate a problem, so long as no design
> decisions for Lucene/Solr take place on #lucene or #solr. #lucene and
#solr is
> where users get to ask questions, much like how it is on the user mailing
lists.
> So *if* (I don't know if it happens) internal Lucene / Solr design
decisions are
> taking place on #lucene or #solr then obviously that must stop. I'd rather
> these channels not get logged so that we can have an expectation of a
single
> place for these discussions on IRC and have that place be clear of user
> support questions.
> >
> > RE refactoring / modularization, it's good to finally see a sense of
> agreement on how to move forward.
Yeah that ok, I have nothing to add to that (and don't want anymore, it's a
soap opera).
> >> 3. Put in the automated patch checking system that Hadoop uses.
> Volunteers? Perhaps we can knock this out at Lucene Revolution?
Who logs the stuff there? In my opinion, a meeting on Lucene-Rev is also
"private" - or is this different somehow? What's difference between a
private talk between two or three people in a bar at Lucene Revolution
without somebody writing down a log? A log can also be written if somebody
else talks with me in a private Skype chat!
Uwe
Re: Special Board Report for May 2011
Posted by Grant Ingersoll <gs...@apache.org>.
On May 12, 2011, at 3:23 PM, Smiley, David W. wrote:
> Hi.
> I haven't commented yet but I've absolutely been following this soap opera. I'm referring to all related threads and JIRA discussions, not just this thread.
>
> I think the current state of logging only #lucene-dev is good.
Yeah, except no one is on it other than a few people even though many of them (committers that is) are on #lucene
> I go to #lucene-dev now. I think only IRC channel(s) that are Lucene/Solr internal development in nature need to be logged -- and that's just #lucene-dev. So just because you have observed many developers are on #lucene instead of #lucene-dev doesn't indicate a problem, so long as no design decisions for Lucene/Solr take place on #lucene or #solr. #lucene and #solr is where users get to ask questions, much like how it is on the user mailing lists. So *if* (I don't know if it happens) internal Lucene / Solr design decisions are taking place on #lucene or #solr then obviously that must stop. I'd rather these channels not get logged so that we can have an expectation of a single place for these discussions on IRC and have that place be clear of user support questions.
>
> RE refactoring / modularization, it's good to finally see a sense of agreement on how to move forward.
>
> ~ David Smiley
>
> On May 12, 2011, at 2:36 PM, Grant Ingersoll wrote:
>
>> I'm not trying to be a pest here, but this conversation and this report is hugely important to the future of this Lucene PMC. So far, I see a sum total of 4 PMC members out of 20+ total PMC members weighing in here, as well as a few other community members, on proactive things to do to move forward.
>>
>> Are you all really in lazy consensus with what has been said so far? (hint: lazy consensus is not a good idea here, so, if you are in consensus, at least speak up and say so) Do you have other suggestions? The Board Meeting is on the 19th and this report needs to be filled at least 2 days prior to that. Claims of thread fatigue, I am sure, are not going to go over well with the Board, so I suggest all PMC Members (as well as others) take some time to think about how to contribute to this report.
>>
>> As it stands now, we have the following concrete suggestions:
>> 1. Log IRC -- from the looks of #lucene-dev, it appears that people have not migrated to the new logged version. To me, we really should just hook up the logger to #lucene and forget #lucene-dev ever existed. We should also put a note that the room is being logged. I am beginning to be of the mindset that any design/dev conversation that is not logged on IRC is the equivalent of a private conversation.
>> 2. Rotate the Chair -- I would propose that this Report is my last official one and that the next Board meeting contains a resolution changing the chair.
>> 3. Put in the automated patch checking system that Hadoop uses. Volunteers? Perhaps we can knock this out at Lucene Revolution?
>> 4. Write up lessons learned by all on commit/revert and scratching/itches and make sure newcomers and old timers alike understand how it works.
>> 5. I gather, via lazy consensus from the other thread, that we are in agreement on refactoring and we have a way forward.
>> 6. Discourage private emails, phone calls, etc. as they relate to the project. I personally am starting to think that if there is wind of this happening more that it is not at all unreasonable to remove commit bits.
>>
>> -Grant
>>
>>
>> On May 7, 2011, at 6:47 AM, Michael McCandless wrote:
>>
>>> +1
>>>
>>> Mike
>>>
>>> http://blog.mikemccandless.com
>>>
>>> On Sat, May 7, 2011 at 6:41 AM, Simon Willnauer
>>> <si...@googlemail.com> wrote:
>>>> On Sat, May 7, 2011 at 9:52 AM, Greg Stein <gs...@gmail.com> wrote:
>>>>> I've seen several people note that "IRC is not logged". Fine. LOG IT.
>>>>>
>>>>> I see absolutely no reason for you guys not to set up logging for the
>>>>> channel that you use. We do this for Subversion development:
>>>>> http://colabti.org/irclogger/irclogger_logs/svn-dev
>>>>>
>>>>> If IRC is posing so much of a problem, then just log it. I saw a
>>>>> comment about civility on the channel. Well... if it is logged, then
>>>>> you may see that fixed. Discussions can then be referenced when it is
>>>>> brought to the dev list. And people can always refer back to the log
>>>>> to read about the nuances around some particular discussion.
>>>>>
>>>>> Seems to be a simple solution to me.
>>>> huge +1! IRC is so powerful we should not put it down just because we
>>>> don't log the channel.
>>>>
>>>> We already have a logged channel #lucene-dev and its logged here
>>>>
>>>> http://colabti.org/irclogger/irclogger_logs/lucene-dev
>>>>
>>>> having tech discussion there should be ok I think and for major
>>>> decisions we can still send a mail to dev@l.a.o referencing the
>>>> discussion. I think we all have the discipline to do that right?
>>>>
>>>> I am moving there now... we should also eventually add this channel to
>>>> the website and maybe mark #lucene as the user channel?
>>>>
>>>> Simon
>>>>>
>>>>> Cheers,
>>>>> -g
>>>>>
>>>>> On Fri, May 06, 2011 at 10:17:07PM +0300, Shai Erera wrote:
>>>>>> bq. shall I say required reading?
>>>>>>
>>>>>> You should ! If only so that people don't miss that great article :)
>>>>>>
>>>>>> On IRC, I agree with Grant (and partly w/ Mike). IMO, we should scale down
>>>>>> the amount of discussion on IRC. While there are several advantages to IRC
>>>>>> (faster response time, easier to hash things out etc.), I think there are
>>>>>> several drawbacks:
>>>>>>
>>>>>> * As Grant mentioned, TimeZone -- IRC makes it hard for people to follow
>>>>>> discussions that happened while they were asleep
>>>>>>
>>>>>> * IRC is not logged
>>>>>>
>>>>>> * Even trying to follow discussions on IRC, the nature of the UI sometimes
>>>>>> makes it too hard. Many times I've seen two and more discussions happen
>>>>>> simultaneously, and the way the UI is constructed, they're all mixed with
>>>>>> each other. This is not so with email threads.
>>>>>>
>>>>>> * I myself have too many communication mediums I need to follow today: my
>>>>>> job's email and messaging system, Gmail (Lucene and other mailing lists, as
>>>>>> well as private stuff), phone, people stopping by for questions .. IRC is a
>>>>>> very busy and demanding channel. You're kinda expected to respond
>>>>>> immediately (which is why, I think, it's easier to hash things out -- the
>>>>>> response time is instantaneous). If you only want to follow, you must stay
>>>>>> tuned to it. If I turn on "flash the taskbar for new messages", it drives me
>>>>>> crazy. If I turn it off, I miss important discussions ... it's impossible
>>>>>> :).
>>>>>> With emails, I can prioritize things. At least, Gmail helps to some extent.
>>>>>> That that we now receive all JIRA emails under one thread is a great
>>>>>> progress too.
>>>>>> With emails, I can always go back when I have time, and re-read the
>>>>>> discussion. I can respond to it 2 days after the last email, and people will
>>>>>> immediately know what I respond about, because we can include quoted text.
>>>>>> And if people's memory is very bad, they can (at least in Gmail) scan
>>>>>> quickly previous messages. Hack ... I can do that 1 month after the email
>>>>>> was sent, and most people will be able to quickly pick up from where we
>>>>>> left. This is not so with IRC ...
>>>>>>
>>>>>> * Getting in the middle of a discussion is practically impossible on IRC. I
>>>>>> have nothing to read for reference (unless I had my IRC client open and I
>>>>>> turned on the 'logging' feature).
>>>>>>
>>>>>> * Is it really that easier to hash things out on IRC? I mean, the response
>>>>>> time is great, so you get answers really quick. But then, there are usually
>>>>>> only a handful of participants in that discussion, which makes hashing out
>>>>>> and agreeing much easier anyway. If the same group of people (usually <=3)
>>>>>> communicated in email, they'd hash things out in almost the same speed.
>>>>>> After all, IRC mandates they are all awake at the same time, so they could
>>>>>> also email each other in NRT :).
>>>>>>
>>>>>> * Imagine this discussion happening on IRC. Most of us would have been able
>>>>>> to pick only shards of it. At some point, maybe Grant or another PMC member
>>>>>> would 'summarize' the discussion to the list. The summary could be "we've
>>>>>> decided to not use IRC because email is better", followed by some points
>>>>>> he's able to pull back from his memory and maybe IRC log. Would *you*
>>>>>> (people reading this growing-by-the-minute note) want to get a summary like
>>>>>> that? Would you be satisfied?
>>>>>> I think that most of us wouldn't and all that would happen is that such
>>>>>> email would start its own thread, repeating mostly what have been said on
>>>>>> IRC, b/c people would want answers ...
>>>>>>
>>>>>> I'm not against IRC, don't get me wrong. I think it's useful b/c the
>>>>>> turnaround time is great. But we should not have so many discussions there,
>>>>>> as we do today. I don't know where to draw the line. I trust the great
>>>>>> people of this community to know when it's better to discuss something in
>>>>>> email. An example, if a new feature is being discussed, then it's ok if two
>>>>>> people want to hash few things out quickly, before they send a detailed and
>>>>>> organized proposal to the list -- the details to hash out are the initial
>>>>>> proposal's details. The rest should be followed on list, even if it means
>>>>>> slightly slower response time.
>>>>>>
>>>>>> Today's list and JIRA volume always look to me like the response time is
>>>>>> instantaneous. We have very active people from around the globe, so you have
>>>>>> a high chance receiving response in no time. In the worse case, it will take
>>>>>> a couple of hours, but I don't remember when did that happen (which is an
>>>>>> amazing thing !)
>>>>>>
>>>>>> Cheers,
>>>>>> Shai
>>>>>>
>>>>>> On Fri, May 6, 2011 at 8:35 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>
>>>>>>> More reading (shall I say required reading?). Benson does a good job of
>>>>>>> explaining some of the concepts around consensus and why we also should be
>>>>>>> primarily using mailing lists:
>>>>>>> https://blogs.apache.org/comdev/entry/how_apache_projects_use_consensus
>>>>>>>
>>>>>>> -Grant
>>>>>>>
>>>>>>> On May 5, 2011, at 10:10 AM, Grant Ingersoll wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> I'd like to throw out another idea:
>>>>>>>>
>>>>>>>> I think we should standardize on rotating the PMC Chair every year. I
>>>>>>> think to date, there have been two Chairs: Doug and me. Back when Doug
>>>>>>> left, no one wanted to do it (both Hoss and I said we would if no one else
>>>>>>> wanted to) and so I took it on. For the most part, it's a thankless task of
>>>>>>> herding cats (albeit low volume, thankfully), despite the important sounding
>>>>>>> name that marketing types love. I would like us to share the burden across
>>>>>>> the PMC by rotating it on an annual basis. Many other ASF projects do
>>>>>>> exactly this and I think it removes any political pressure. Have I sold it
>>>>>>> enough? ;-) Besides, I just know others are dying to file board reports on
>>>>>>> a quarterly basis!
>>>>>>>>
>>>>>>>> More inline below...
>>>>>>>>
>>>>>>>> On May 5, 2011, at 8:27 AM, Michael McCandless wrote:
>>>>>>>>
>>>>>>>>> On Wed, May 4, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org>
>>>>>>> wrote:
>>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> Agreed, but this dovetails w/ the use of IRC. I realize live collab is
>>>>>>> nice, but it discourages those who aren't "in the know" about the channel
>>>>>>> being used from ever contributing. Say, for instance, I'm interested in
>>>>>>> DWPT (DocWriterPerThread), how am I supposed to know that at 8 am EDT on May
>>>>>>> 5th (made up example), three of the committers are going to be talking about
>>>>>>> it on IRC? If there is email about it, then I can participate. Nothing we
>>>>>>> do is so important that it can't wait a few hours or a day, besides the
>>>>>>> fact, that email is damn near instantaneous these days anyway.
>>>>>>>>
>>>>>>>> Also, keep in mind that until about a year ago, most everything was done
>>>>>>> on the mailing list and I think we progressed just fine. Since then, dev@has almost completely dried up in terms of discussions (factoring out JIRA
>>>>>>> mails which have picked up -- which is good) and the large majority of
>>>>>>> discussion takes place on IRC. I agree, however, we should have the IRC
>>>>>>> discussion on another thread.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> Yeah, I agree. The hard part for me, is I often feel like people on the
>>>>>>> outside make big deals about this stuff and don't get that even having the
>>>>>>> discussion is a very healthy sign. Besides the fact, that no one likes
>>>>>>> confrontation and uncomfortable topics. We also, I think, are all tired of
>>>>>>> endless debates that go on and on w/ no resolution. It's one of the big
>>>>>>> downsides (and, of course, upsides) to consensus based open source as
>>>>>>> opposed to the dictatorial approach.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> I hopefully would agree we are good stewards of the fact that we employ a
>>>>>>> good number of committers (but not nearly all the active ones), but I know
>>>>>>> some disagree. I do, however, think that the recent spat shows that we at
>>>>>>> Lucid are still free to speak our minds when it comes to open source, as
>>>>>>> clearly not all Lucid employees agree on the issue and were pretty outspoken
>>>>>>> about it. I firmly believe we baked this into the company from Day 1 and I
>>>>>>> consider it one of our best strengths, but of course, most can't see that
>>>>>>> from the outside. Does that mean we are perfect? Of course not, but I
>>>>>>> think we try to follow the ASF guidelines and show up as individuals. I
>>>>>>> also know we work pretty hard to mind the ASF TM policy, etc. (just ask our
>>>>>>> marketing folks how much I remind them.) I think we all realize that there
>>>>>>> would be no such thing as Lucid if it weren't for the ASF and for
>>>>>>> Lucene/Solr, so why would we want to hurt that?
>>>>>>>>
>>>>>>>> The fact is, every single committer here and a good number of
>>>>>>> contributors are paid to work on Lucene all day, (most) every day or have
>>>>>>> some other financial stake (i.e. via a book, consulting biz, etc.) Any of
>>>>>>> us could be accused of only acting in our own financial interest. At the
>>>>>>> end of the day, I like to think that instead, the cool thing is we all have
>>>>>>> a great opportunity to have our financial interests aligned with a great
>>>>>>> project that we like to work on.
>>>>>>>>
>>>>>>>> For the record, we have pretty diverse PMC and committer base. As I said
>>>>>>> in our Dec. 2010 Board Report, we are comprised of:
>>>>>>>> "[a] total to 17 PMC members from 12 different
>>>>>>>> companies, spanning the globe. The flagship Lucene/Solr
>>>>>>>> has 26 total committers from 20 different companies, again
>>>>>>>> spanning the globe."
>>>>>>>>
>>>>>>>> The only one that has changed since then is Robert has joined Lucid.
>>>>>>> Now, one can argue that some of those members from other companies are not
>>>>>>> active, but that isn't Lucid's fault. ASF development has always been about
>>>>>>> those who do the work and we do a fair amount of that. Those who are not
>>>>>>> active, should, ideally, leave on their own by stating they wish to go
>>>>>>> Emeritus. Beyond that, we have a pretty standard policy that inactive
>>>>>>> people are removed after 1 year of no activity. That has been the case
>>>>>>> since I joined Lucene way back when and I think makes sense.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>
>>
>
--------------------------------------------
Grant Ingersoll
Join the LUCENE REVOLUTION
Lucene & Solr User Conference
May 25-26, San Francisco
www.lucenerevolution.org
Re: Special Board Report for May 2011
Posted by "Smiley, David W." <ds...@mitre.org>.
Hi.
I haven't commented yet but I've absolutely been following this soap opera. I'm referring to all related threads and JIRA discussions, not just this thread.
I think the current state of logging only #lucene-dev is good. I go to #lucene-dev now. I think only IRC channel(s) that are Lucene/Solr internal development in nature need to be logged -- and that's just #lucene-dev. So just because you have observed many developers are on #lucene instead of #lucene-dev doesn't indicate a problem, so long as no design decisions for Lucene/Solr take place on #lucene or #solr. #lucene and #solr is where users get to ask questions, much like how it is on the user mailing lists. So *if* (I don't know if it happens) internal Lucene / Solr design decisions are taking place on #lucene or #solr then obviously that must stop. I'd rather these channels not get logged so that we can have an expectation of a single place for these discussions on IRC and have that place be clear of user support questions.
RE refactoring / modularization, it's good to finally see a sense of agreement on how to move forward.
~ David Smiley
On May 12, 2011, at 2:36 PM, Grant Ingersoll wrote:
> I'm not trying to be a pest here, but this conversation and this report is hugely important to the future of this Lucene PMC. So far, I see a sum total of 4 PMC members out of 20+ total PMC members weighing in here, as well as a few other community members, on proactive things to do to move forward.
>
> Are you all really in lazy consensus with what has been said so far? (hint: lazy consensus is not a good idea here, so, if you are in consensus, at least speak up and say so) Do you have other suggestions? The Board Meeting is on the 19th and this report needs to be filled at least 2 days prior to that. Claims of thread fatigue, I am sure, are not going to go over well with the Board, so I suggest all PMC Members (as well as others) take some time to think about how to contribute to this report.
>
> As it stands now, we have the following concrete suggestions:
> 1. Log IRC -- from the looks of #lucene-dev, it appears that people have not migrated to the new logged version. To me, we really should just hook up the logger to #lucene and forget #lucene-dev ever existed. We should also put a note that the room is being logged. I am beginning to be of the mindset that any design/dev conversation that is not logged on IRC is the equivalent of a private conversation.
> 2. Rotate the Chair -- I would propose that this Report is my last official one and that the next Board meeting contains a resolution changing the chair.
> 3. Put in the automated patch checking system that Hadoop uses. Volunteers? Perhaps we can knock this out at Lucene Revolution?
> 4. Write up lessons learned by all on commit/revert and scratching/itches and make sure newcomers and old timers alike understand how it works.
> 5. I gather, via lazy consensus from the other thread, that we are in agreement on refactoring and we have a way forward.
> 6. Discourage private emails, phone calls, etc. as they relate to the project. I personally am starting to think that if there is wind of this happening more that it is not at all unreasonable to remove commit bits.
>
> -Grant
>
>
> On May 7, 2011, at 6:47 AM, Michael McCandless wrote:
>
>> +1
>>
>> Mike
>>
>> http://blog.mikemccandless.com
>>
>> On Sat, May 7, 2011 at 6:41 AM, Simon Willnauer
>> <si...@googlemail.com> wrote:
>>> On Sat, May 7, 2011 at 9:52 AM, Greg Stein <gs...@gmail.com> wrote:
>>>> I've seen several people note that "IRC is not logged". Fine. LOG IT.
>>>>
>>>> I see absolutely no reason for you guys not to set up logging for the
>>>> channel that you use. We do this for Subversion development:
>>>> http://colabti.org/irclogger/irclogger_logs/svn-dev
>>>>
>>>> If IRC is posing so much of a problem, then just log it. I saw a
>>>> comment about civility on the channel. Well... if it is logged, then
>>>> you may see that fixed. Discussions can then be referenced when it is
>>>> brought to the dev list. And people can always refer back to the log
>>>> to read about the nuances around some particular discussion.
>>>>
>>>> Seems to be a simple solution to me.
>>> huge +1! IRC is so powerful we should not put it down just because we
>>> don't log the channel.
>>>
>>> We already have a logged channel #lucene-dev and its logged here
>>>
>>> http://colabti.org/irclogger/irclogger_logs/lucene-dev
>>>
>>> having tech discussion there should be ok I think and for major
>>> decisions we can still send a mail to dev@l.a.o referencing the
>>> discussion. I think we all have the discipline to do that right?
>>>
>>> I am moving there now... we should also eventually add this channel to
>>> the website and maybe mark #lucene as the user channel?
>>>
>>> Simon
>>>>
>>>> Cheers,
>>>> -g
>>>>
>>>> On Fri, May 06, 2011 at 10:17:07PM +0300, Shai Erera wrote:
>>>>> bq. shall I say required reading?
>>>>>
>>>>> You should ! If only so that people don't miss that great article :)
>>>>>
>>>>> On IRC, I agree with Grant (and partly w/ Mike). IMO, we should scale down
>>>>> the amount of discussion on IRC. While there are several advantages to IRC
>>>>> (faster response time, easier to hash things out etc.), I think there are
>>>>> several drawbacks:
>>>>>
>>>>> * As Grant mentioned, TimeZone -- IRC makes it hard for people to follow
>>>>> discussions that happened while they were asleep
>>>>>
>>>>> * IRC is not logged
>>>>>
>>>>> * Even trying to follow discussions on IRC, the nature of the UI sometimes
>>>>> makes it too hard. Many times I've seen two and more discussions happen
>>>>> simultaneously, and the way the UI is constructed, they're all mixed with
>>>>> each other. This is not so with email threads.
>>>>>
>>>>> * I myself have too many communication mediums I need to follow today: my
>>>>> job's email and messaging system, Gmail (Lucene and other mailing lists, as
>>>>> well as private stuff), phone, people stopping by for questions .. IRC is a
>>>>> very busy and demanding channel. You're kinda expected to respond
>>>>> immediately (which is why, I think, it's easier to hash things out -- the
>>>>> response time is instantaneous). If you only want to follow, you must stay
>>>>> tuned to it. If I turn on "flash the taskbar for new messages", it drives me
>>>>> crazy. If I turn it off, I miss important discussions ... it's impossible
>>>>> :).
>>>>> With emails, I can prioritize things. At least, Gmail helps to some extent.
>>>>> That that we now receive all JIRA emails under one thread is a great
>>>>> progress too.
>>>>> With emails, I can always go back when I have time, and re-read the
>>>>> discussion. I can respond to it 2 days after the last email, and people will
>>>>> immediately know what I respond about, because we can include quoted text.
>>>>> And if people's memory is very bad, they can (at least in Gmail) scan
>>>>> quickly previous messages. Hack ... I can do that 1 month after the email
>>>>> was sent, and most people will be able to quickly pick up from where we
>>>>> left. This is not so with IRC ...
>>>>>
>>>>> * Getting in the middle of a discussion is practically impossible on IRC. I
>>>>> have nothing to read for reference (unless I had my IRC client open and I
>>>>> turned on the 'logging' feature).
>>>>>
>>>>> * Is it really that easier to hash things out on IRC? I mean, the response
>>>>> time is great, so you get answers really quick. But then, there are usually
>>>>> only a handful of participants in that discussion, which makes hashing out
>>>>> and agreeing much easier anyway. If the same group of people (usually <=3)
>>>>> communicated in email, they'd hash things out in almost the same speed.
>>>>> After all, IRC mandates they are all awake at the same time, so they could
>>>>> also email each other in NRT :).
>>>>>
>>>>> * Imagine this discussion happening on IRC. Most of us would have been able
>>>>> to pick only shards of it. At some point, maybe Grant or another PMC member
>>>>> would 'summarize' the discussion to the list. The summary could be "we've
>>>>> decided to not use IRC because email is better", followed by some points
>>>>> he's able to pull back from his memory and maybe IRC log. Would *you*
>>>>> (people reading this growing-by-the-minute note) want to get a summary like
>>>>> that? Would you be satisfied?
>>>>> I think that most of us wouldn't and all that would happen is that such
>>>>> email would start its own thread, repeating mostly what have been said on
>>>>> IRC, b/c people would want answers ...
>>>>>
>>>>> I'm not against IRC, don't get me wrong. I think it's useful b/c the
>>>>> turnaround time is great. But we should not have so many discussions there,
>>>>> as we do today. I don't know where to draw the line. I trust the great
>>>>> people of this community to know when it's better to discuss something in
>>>>> email. An example, if a new feature is being discussed, then it's ok if two
>>>>> people want to hash few things out quickly, before they send a detailed and
>>>>> organized proposal to the list -- the details to hash out are the initial
>>>>> proposal's details. The rest should be followed on list, even if it means
>>>>> slightly slower response time.
>>>>>
>>>>> Today's list and JIRA volume always look to me like the response time is
>>>>> instantaneous. We have very active people from around the globe, so you have
>>>>> a high chance receiving response in no time. In the worse case, it will take
>>>>> a couple of hours, but I don't remember when did that happen (which is an
>>>>> amazing thing !)
>>>>>
>>>>> Cheers,
>>>>> Shai
>>>>>
>>>>> On Fri, May 6, 2011 at 8:35 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>
>>>>>> More reading (shall I say required reading?). Benson does a good job of
>>>>>> explaining some of the concepts around consensus and why we also should be
>>>>>> primarily using mailing lists:
>>>>>> https://blogs.apache.org/comdev/entry/how_apache_projects_use_consensus
>>>>>>
>>>>>> -Grant
>>>>>>
>>>>>> On May 5, 2011, at 10:10 AM, Grant Ingersoll wrote:
>>>>>>
>>>>>>>
>>>>>>> I'd like to throw out another idea:
>>>>>>>
>>>>>>> I think we should standardize on rotating the PMC Chair every year. I
>>>>>> think to date, there have been two Chairs: Doug and me. Back when Doug
>>>>>> left, no one wanted to do it (both Hoss and I said we would if no one else
>>>>>> wanted to) and so I took it on. For the most part, it's a thankless task of
>>>>>> herding cats (albeit low volume, thankfully), despite the important sounding
>>>>>> name that marketing types love. I would like us to share the burden across
>>>>>> the PMC by rotating it on an annual basis. Many other ASF projects do
>>>>>> exactly this and I think it removes any political pressure. Have I sold it
>>>>>> enough? ;-) Besides, I just know others are dying to file board reports on
>>>>>> a quarterly basis!
>>>>>>>
>>>>>>> More inline below...
>>>>>>>
>>>>>>> On May 5, 2011, at 8:27 AM, Michael McCandless wrote:
>>>>>>>
>>>>>>>> On Wed, May 4, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org>
>>>>>> wrote:
>>>>>>>>> 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.
>>>>>>>
>>>>>>> Agreed, but this dovetails w/ the use of IRC. I realize live collab is
>>>>>> nice, but it discourages those who aren't "in the know" about the channel
>>>>>> being used from ever contributing. Say, for instance, I'm interested in
>>>>>> DWPT (DocWriterPerThread), how am I supposed to know that at 8 am EDT on May
>>>>>> 5th (made up example), three of the committers are going to be talking about
>>>>>> it on IRC? If there is email about it, then I can participate. Nothing we
>>>>>> do is so important that it can't wait a few hours or a day, besides the
>>>>>> fact, that email is damn near instantaneous these days anyway.
>>>>>>>
>>>>>>> Also, keep in mind that until about a year ago, most everything was done
>>>>>> on the mailing list and I think we progressed just fine. Since then, dev@has almost completely dried up in terms of discussions (factoring out JIRA
>>>>>> mails which have picked up -- which is good) and the large majority of
>>>>>> discussion takes place on IRC. I agree, however, we should have the IRC
>>>>>> discussion on another thread.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> Yeah, I agree. The hard part for me, is I often feel like people on the
>>>>>> outside make big deals about this stuff and don't get that even having the
>>>>>> discussion is a very healthy sign. Besides the fact, that no one likes
>>>>>> confrontation and uncomfortable topics. We also, I think, are all tired of
>>>>>> endless debates that go on and on w/ no resolution. It's one of the big
>>>>>> downsides (and, of course, upsides) to consensus based open source as
>>>>>> opposed to the dictatorial approach.
>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> I hopefully would agree we are good stewards of the fact that we employ a
>>>>>> good number of committers (but not nearly all the active ones), but I know
>>>>>> some disagree. I do, however, think that the recent spat shows that we at
>>>>>> Lucid are still free to speak our minds when it comes to open source, as
>>>>>> clearly not all Lucid employees agree on the issue and were pretty outspoken
>>>>>> about it. I firmly believe we baked this into the company from Day 1 and I
>>>>>> consider it one of our best strengths, but of course, most can't see that
>>>>>> from the outside. Does that mean we are perfect? Of course not, but I
>>>>>> think we try to follow the ASF guidelines and show up as individuals. I
>>>>>> also know we work pretty hard to mind the ASF TM policy, etc. (just ask our
>>>>>> marketing folks how much I remind them.) I think we all realize that there
>>>>>> would be no such thing as Lucid if it weren't for the ASF and for
>>>>>> Lucene/Solr, so why would we want to hurt that?
>>>>>>>
>>>>>>> The fact is, every single committer here and a good number of
>>>>>> contributors are paid to work on Lucene all day, (most) every day or have
>>>>>> some other financial stake (i.e. via a book, consulting biz, etc.) Any of
>>>>>> us could be accused of only acting in our own financial interest. At the
>>>>>> end of the day, I like to think that instead, the cool thing is we all have
>>>>>> a great opportunity to have our financial interests aligned with a great
>>>>>> project that we like to work on.
>>>>>>>
>>>>>>> For the record, we have pretty diverse PMC and committer base. As I said
>>>>>> in our Dec. 2010 Board Report, we are comprised of:
>>>>>>> "[a] total to 17 PMC members from 12 different
>>>>>>> companies, spanning the globe. The flagship Lucene/Solr
>>>>>>> has 26 total committers from 20 different companies, again
>>>>>>> spanning the globe."
>>>>>>>
>>>>>>> The only one that has changed since then is Robert has joined Lucid.
>>>>>> Now, one can argue that some of those members from other companies are not
>>>>>> active, but that isn't Lucid's fault. ASF development has always been about
>>>>>> those who do the work and we do a fair amount of that. Those who are not
>>>>>> active, should, ideally, leave on their own by stating they wish to go
>>>>>> Emeritus. Beyond that, we have a pretty standard policy that inactive
>>>>>> people are removed after 1 year of no activity. That has been the case
>>>>>> since I joined Lucene way back when and I think makes sense.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>
>
Re: Special Board Report for May 2011
Posted by Grant Ingersoll <gs...@apache.org>.
I'm not trying to be a pest here, but this conversation and this report is hugely important to the future of this Lucene PMC. So far, I see a sum total of 4 PMC members out of 20+ total PMC members weighing in here, as well as a few other community members, on proactive things to do to move forward.
Are you all really in lazy consensus with what has been said so far? (hint: lazy consensus is not a good idea here, so, if you are in consensus, at least speak up and say so) Do you have other suggestions? The Board Meeting is on the 19th and this report needs to be filled at least 2 days prior to that. Claims of thread fatigue, I am sure, are not going to go over well with the Board, so I suggest all PMC Members (as well as others) take some time to think about how to contribute to this report.
As it stands now, we have the following concrete suggestions:
1. Log IRC -- from the looks of #lucene-dev, it appears that people have not migrated to the new logged version. To me, we really should just hook up the logger to #lucene and forget #lucene-dev ever existed. We should also put a note that the room is being logged. I am beginning to be of the mindset that any design/dev conversation that is not logged on IRC is the equivalent of a private conversation.
2. Rotate the Chair -- I would propose that this Report is my last official one and that the next Board meeting contains a resolution changing the chair.
3. Put in the automated patch checking system that Hadoop uses. Volunteers? Perhaps we can knock this out at Lucene Revolution?
4. Write up lessons learned by all on commit/revert and scratching/itches and make sure newcomers and old timers alike understand how it works.
5. I gather, via lazy consensus from the other thread, that we are in agreement on refactoring and we have a way forward.
6. Discourage private emails, phone calls, etc. as they relate to the project. I personally am starting to think that if there is wind of this happening more that it is not at all unreasonable to remove commit bits.
-Grant
On May 7, 2011, at 6:47 AM, Michael McCandless wrote:
> +1
>
> Mike
>
> http://blog.mikemccandless.com
>
> On Sat, May 7, 2011 at 6:41 AM, Simon Willnauer
> <si...@googlemail.com> wrote:
>> On Sat, May 7, 2011 at 9:52 AM, Greg Stein <gs...@gmail.com> wrote:
>>> I've seen several people note that "IRC is not logged". Fine. LOG IT.
>>>
>>> I see absolutely no reason for you guys not to set up logging for the
>>> channel that you use. We do this for Subversion development:
>>> http://colabti.org/irclogger/irclogger_logs/svn-dev
>>>
>>> If IRC is posing so much of a problem, then just log it. I saw a
>>> comment about civility on the channel. Well... if it is logged, then
>>> you may see that fixed. Discussions can then be referenced when it is
>>> brought to the dev list. And people can always refer back to the log
>>> to read about the nuances around some particular discussion.
>>>
>>> Seems to be a simple solution to me.
>> huge +1! IRC is so powerful we should not put it down just because we
>> don't log the channel.
>>
>> We already have a logged channel #lucene-dev and its logged here
>>
>> http://colabti.org/irclogger/irclogger_logs/lucene-dev
>>
>> having tech discussion there should be ok I think and for major
>> decisions we can still send a mail to dev@l.a.o referencing the
>> discussion. I think we all have the discipline to do that right?
>>
>> I am moving there now... we should also eventually add this channel to
>> the website and maybe mark #lucene as the user channel?
>>
>> Simon
>>>
>>> Cheers,
>>> -g
>>>
>>> On Fri, May 06, 2011 at 10:17:07PM +0300, Shai Erera wrote:
>>>> bq. shall I say required reading?
>>>>
>>>> You should ! If only so that people don't miss that great article :)
>>>>
>>>> On IRC, I agree with Grant (and partly w/ Mike). IMO, we should scale down
>>>> the amount of discussion on IRC. While there are several advantages to IRC
>>>> (faster response time, easier to hash things out etc.), I think there are
>>>> several drawbacks:
>>>>
>>>> * As Grant mentioned, TimeZone -- IRC makes it hard for people to follow
>>>> discussions that happened while they were asleep
>>>>
>>>> * IRC is not logged
>>>>
>>>> * Even trying to follow discussions on IRC, the nature of the UI sometimes
>>>> makes it too hard. Many times I've seen two and more discussions happen
>>>> simultaneously, and the way the UI is constructed, they're all mixed with
>>>> each other. This is not so with email threads.
>>>>
>>>> * I myself have too many communication mediums I need to follow today: my
>>>> job's email and messaging system, Gmail (Lucene and other mailing lists, as
>>>> well as private stuff), phone, people stopping by for questions .. IRC is a
>>>> very busy and demanding channel. You're kinda expected to respond
>>>> immediately (which is why, I think, it's easier to hash things out -- the
>>>> response time is instantaneous). If you only want to follow, you must stay
>>>> tuned to it. If I turn on "flash the taskbar for new messages", it drives me
>>>> crazy. If I turn it off, I miss important discussions ... it's impossible
>>>> :).
>>>> With emails, I can prioritize things. At least, Gmail helps to some extent.
>>>> That that we now receive all JIRA emails under one thread is a great
>>>> progress too.
>>>> With emails, I can always go back when I have time, and re-read the
>>>> discussion. I can respond to it 2 days after the last email, and people will
>>>> immediately know what I respond about, because we can include quoted text.
>>>> And if people's memory is very bad, they can (at least in Gmail) scan
>>>> quickly previous messages. Hack ... I can do that 1 month after the email
>>>> was sent, and most people will be able to quickly pick up from where we
>>>> left. This is not so with IRC ...
>>>>
>>>> * Getting in the middle of a discussion is practically impossible on IRC. I
>>>> have nothing to read for reference (unless I had my IRC client open and I
>>>> turned on the 'logging' feature).
>>>>
>>>> * Is it really that easier to hash things out on IRC? I mean, the response
>>>> time is great, so you get answers really quick. But then, there are usually
>>>> only a handful of participants in that discussion, which makes hashing out
>>>> and agreeing much easier anyway. If the same group of people (usually <=3)
>>>> communicated in email, they'd hash things out in almost the same speed.
>>>> After all, IRC mandates they are all awake at the same time, so they could
>>>> also email each other in NRT :).
>>>>
>>>> * Imagine this discussion happening on IRC. Most of us would have been able
>>>> to pick only shards of it. At some point, maybe Grant or another PMC member
>>>> would 'summarize' the discussion to the list. The summary could be "we've
>>>> decided to not use IRC because email is better", followed by some points
>>>> he's able to pull back from his memory and maybe IRC log. Would *you*
>>>> (people reading this growing-by-the-minute note) want to get a summary like
>>>> that? Would you be satisfied?
>>>> I think that most of us wouldn't and all that would happen is that such
>>>> email would start its own thread, repeating mostly what have been said on
>>>> IRC, b/c people would want answers ...
>>>>
>>>> I'm not against IRC, don't get me wrong. I think it's useful b/c the
>>>> turnaround time is great. But we should not have so many discussions there,
>>>> as we do today. I don't know where to draw the line. I trust the great
>>>> people of this community to know when it's better to discuss something in
>>>> email. An example, if a new feature is being discussed, then it's ok if two
>>>> people want to hash few things out quickly, before they send a detailed and
>>>> organized proposal to the list -- the details to hash out are the initial
>>>> proposal's details. The rest should be followed on list, even if it means
>>>> slightly slower response time.
>>>>
>>>> Today's list and JIRA volume always look to me like the response time is
>>>> instantaneous. We have very active people from around the globe, so you have
>>>> a high chance receiving response in no time. In the worse case, it will take
>>>> a couple of hours, but I don't remember when did that happen (which is an
>>>> amazing thing !)
>>>>
>>>> Cheers,
>>>> Shai
>>>>
>>>> On Fri, May 6, 2011 at 8:35 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>
>>>>> More reading (shall I say required reading?). Benson does a good job of
>>>>> explaining some of the concepts around consensus and why we also should be
>>>>> primarily using mailing lists:
>>>>> https://blogs.apache.org/comdev/entry/how_apache_projects_use_consensus
>>>>>
>>>>> -Grant
>>>>>
>>>>> On May 5, 2011, at 10:10 AM, Grant Ingersoll wrote:
>>>>>
>>>>>>
>>>>>> I'd like to throw out another idea:
>>>>>>
>>>>>> I think we should standardize on rotating the PMC Chair every year. I
>>>>> think to date, there have been two Chairs: Doug and me. Back when Doug
>>>>> left, no one wanted to do it (both Hoss and I said we would if no one else
>>>>> wanted to) and so I took it on. For the most part, it's a thankless task of
>>>>> herding cats (albeit low volume, thankfully), despite the important sounding
>>>>> name that marketing types love. I would like us to share the burden across
>>>>> the PMC by rotating it on an annual basis. Many other ASF projects do
>>>>> exactly this and I think it removes any political pressure. Have I sold it
>>>>> enough? ;-) Besides, I just know others are dying to file board reports on
>>>>> a quarterly basis!
>>>>>>
>>>>>> More inline below...
>>>>>>
>>>>>> On May 5, 2011, at 8:27 AM, Michael McCandless wrote:
>>>>>>
>>>>>>> On Wed, May 4, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org>
>>>>> wrote:
>>>>>>>> 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.
>>>>>>
>>>>>> Agreed, but this dovetails w/ the use of IRC. I realize live collab is
>>>>> nice, but it discourages those who aren't "in the know" about the channel
>>>>> being used from ever contributing. Say, for instance, I'm interested in
>>>>> DWPT (DocWriterPerThread), how am I supposed to know that at 8 am EDT on May
>>>>> 5th (made up example), three of the committers are going to be talking about
>>>>> it on IRC? If there is email about it, then I can participate. Nothing we
>>>>> do is so important that it can't wait a few hours or a day, besides the
>>>>> fact, that email is damn near instantaneous these days anyway.
>>>>>>
>>>>>> Also, keep in mind that until about a year ago, most everything was done
>>>>> on the mailing list and I think we progressed just fine. Since then, dev@has almost completely dried up in terms of discussions (factoring out JIRA
>>>>> mails which have picked up -- which is good) and the large majority of
>>>>> discussion takes place on IRC. I agree, however, we should have the IRC
>>>>> discussion on another thread.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> Yeah, I agree. The hard part for me, is I often feel like people on the
>>>>> outside make big deals about this stuff and don't get that even having the
>>>>> discussion is a very healthy sign. Besides the fact, that no one likes
>>>>> confrontation and uncomfortable topics. We also, I think, are all tired of
>>>>> endless debates that go on and on w/ no resolution. It's one of the big
>>>>> downsides (and, of course, upsides) to consensus based open source as
>>>>> opposed to the dictatorial approach.
>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> I hopefully would agree we are good stewards of the fact that we employ a
>>>>> good number of committers (but not nearly all the active ones), but I know
>>>>> some disagree. I do, however, think that the recent spat shows that we at
>>>>> Lucid are still free to speak our minds when it comes to open source, as
>>>>> clearly not all Lucid employees agree on the issue and were pretty outspoken
>>>>> about it. I firmly believe we baked this into the company from Day 1 and I
>>>>> consider it one of our best strengths, but of course, most can't see that
>>>>> from the outside. Does that mean we are perfect? Of course not, but I
>>>>> think we try to follow the ASF guidelines and show up as individuals. I
>>>>> also know we work pretty hard to mind the ASF TM policy, etc. (just ask our
>>>>> marketing folks how much I remind them.) I think we all realize that there
>>>>> would be no such thing as Lucid if it weren't for the ASF and for
>>>>> Lucene/Solr, so why would we want to hurt that?
>>>>>>
>>>>>> The fact is, every single committer here and a good number of
>>>>> contributors are paid to work on Lucene all day, (most) every day or have
>>>>> some other financial stake (i.e. via a book, consulting biz, etc.) Any of
>>>>> us could be accused of only acting in our own financial interest. At the
>>>>> end of the day, I like to think that instead, the cool thing is we all have
>>>>> a great opportunity to have our financial interests aligned with a great
>>>>> project that we like to work on.
>>>>>>
>>>>>> For the record, we have pretty diverse PMC and committer base. As I said
>>>>> in our Dec. 2010 Board Report, we are comprised of:
>>>>>> "[a] total to 17 PMC members from 12 different
>>>>>> companies, spanning the globe. The flagship Lucene/Solr
>>>>>> has 26 total committers from 20 different companies, again
>>>>>> spanning the globe."
>>>>>>
>>>>>> The only one that has changed since then is Robert has joined Lucid.
>>>>> Now, one can argue that some of those members from other companies are not
>>>>> active, but that isn't Lucid's fault. ASF development has always been about
>>>>> those who do the work and we do a fair amount of that. Those who are not
>>>>> active, should, ideally, leave on their own by stating they wish to go
>>>>> Emeritus. Beyond that, we have a pretty standard policy that inactive
>>>>> people are removed after 1 year of no activity. That has been the case
>>>>> since I joined Lucene way back when and I think makes sense.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>
Re: Special Board Report for May 2011
Posted by Michael McCandless <lu...@mikemccandless.com>.
+1
Mike
http://blog.mikemccandless.com
On Sat, May 7, 2011 at 6:41 AM, Simon Willnauer
<si...@googlemail.com> wrote:
> On Sat, May 7, 2011 at 9:52 AM, Greg Stein <gs...@gmail.com> wrote:
>> I've seen several people note that "IRC is not logged". Fine. LOG IT.
>>
>> I see absolutely no reason for you guys not to set up logging for the
>> channel that you use. We do this for Subversion development:
>> http://colabti.org/irclogger/irclogger_logs/svn-dev
>>
>> If IRC is posing so much of a problem, then just log it. I saw a
>> comment about civility on the channel. Well... if it is logged, then
>> you may see that fixed. Discussions can then be referenced when it is
>> brought to the dev list. And people can always refer back to the log
>> to read about the nuances around some particular discussion.
>>
>> Seems to be a simple solution to me.
> huge +1! IRC is so powerful we should not put it down just because we
> don't log the channel.
>
> We already have a logged channel #lucene-dev and its logged here
>
> http://colabti.org/irclogger/irclogger_logs/lucene-dev
>
> having tech discussion there should be ok I think and for major
> decisions we can still send a mail to dev@l.a.o referencing the
> discussion. I think we all have the discipline to do that right?
>
> I am moving there now... we should also eventually add this channel to
> the website and maybe mark #lucene as the user channel?
>
> Simon
>>
>> Cheers,
>> -g
>>
>> On Fri, May 06, 2011 at 10:17:07PM +0300, Shai Erera wrote:
>>> bq. shall I say required reading?
>>>
>>> You should ! If only so that people don't miss that great article :)
>>>
>>> On IRC, I agree with Grant (and partly w/ Mike). IMO, we should scale down
>>> the amount of discussion on IRC. While there are several advantages to IRC
>>> (faster response time, easier to hash things out etc.), I think there are
>>> several drawbacks:
>>>
>>> * As Grant mentioned, TimeZone -- IRC makes it hard for people to follow
>>> discussions that happened while they were asleep
>>>
>>> * IRC is not logged
>>>
>>> * Even trying to follow discussions on IRC, the nature of the UI sometimes
>>> makes it too hard. Many times I've seen two and more discussions happen
>>> simultaneously, and the way the UI is constructed, they're all mixed with
>>> each other. This is not so with email threads.
>>>
>>> * I myself have too many communication mediums I need to follow today: my
>>> job's email and messaging system, Gmail (Lucene and other mailing lists, as
>>> well as private stuff), phone, people stopping by for questions .. IRC is a
>>> very busy and demanding channel. You're kinda expected to respond
>>> immediately (which is why, I think, it's easier to hash things out -- the
>>> response time is instantaneous). If you only want to follow, you must stay
>>> tuned to it. If I turn on "flash the taskbar for new messages", it drives me
>>> crazy. If I turn it off, I miss important discussions ... it's impossible
>>> :).
>>> With emails, I can prioritize things. At least, Gmail helps to some extent.
>>> That that we now receive all JIRA emails under one thread is a great
>>> progress too.
>>> With emails, I can always go back when I have time, and re-read the
>>> discussion. I can respond to it 2 days after the last email, and people will
>>> immediately know what I respond about, because we can include quoted text.
>>> And if people's memory is very bad, they can (at least in Gmail) scan
>>> quickly previous messages. Hack ... I can do that 1 month after the email
>>> was sent, and most people will be able to quickly pick up from where we
>>> left. This is not so with IRC ...
>>>
>>> * Getting in the middle of a discussion is practically impossible on IRC. I
>>> have nothing to read for reference (unless I had my IRC client open and I
>>> turned on the 'logging' feature).
>>>
>>> * Is it really that easier to hash things out on IRC? I mean, the response
>>> time is great, so you get answers really quick. But then, there are usually
>>> only a handful of participants in that discussion, which makes hashing out
>>> and agreeing much easier anyway. If the same group of people (usually <=3)
>>> communicated in email, they'd hash things out in almost the same speed.
>>> After all, IRC mandates they are all awake at the same time, so they could
>>> also email each other in NRT :).
>>>
>>> * Imagine this discussion happening on IRC. Most of us would have been able
>>> to pick only shards of it. At some point, maybe Grant or another PMC member
>>> would 'summarize' the discussion to the list. The summary could be "we've
>>> decided to not use IRC because email is better", followed by some points
>>> he's able to pull back from his memory and maybe IRC log. Would *you*
>>> (people reading this growing-by-the-minute note) want to get a summary like
>>> that? Would you be satisfied?
>>> I think that most of us wouldn't and all that would happen is that such
>>> email would start its own thread, repeating mostly what have been said on
>>> IRC, b/c people would want answers ...
>>>
>>> I'm not against IRC, don't get me wrong. I think it's useful b/c the
>>> turnaround time is great. But we should not have so many discussions there,
>>> as we do today. I don't know where to draw the line. I trust the great
>>> people of this community to know when it's better to discuss something in
>>> email. An example, if a new feature is being discussed, then it's ok if two
>>> people want to hash few things out quickly, before they send a detailed and
>>> organized proposal to the list -- the details to hash out are the initial
>>> proposal's details. The rest should be followed on list, even if it means
>>> slightly slower response time.
>>>
>>> Today's list and JIRA volume always look to me like the response time is
>>> instantaneous. We have very active people from around the globe, so you have
>>> a high chance receiving response in no time. In the worse case, it will take
>>> a couple of hours, but I don't remember when did that happen (which is an
>>> amazing thing !)
>>>
>>> Cheers,
>>> Shai
>>>
>>> On Fri, May 6, 2011 at 8:35 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>
>>> > More reading (shall I say required reading?). Benson does a good job of
>>> > explaining some of the concepts around consensus and why we also should be
>>> > primarily using mailing lists:
>>> > https://blogs.apache.org/comdev/entry/how_apache_projects_use_consensus
>>> >
>>> > -Grant
>>> >
>>> > On May 5, 2011, at 10:10 AM, Grant Ingersoll wrote:
>>> >
>>> > >
>>> > > I'd like to throw out another idea:
>>> > >
>>> > > I think we should standardize on rotating the PMC Chair every year. I
>>> > think to date, there have been two Chairs: Doug and me. Back when Doug
>>> > left, no one wanted to do it (both Hoss and I said we would if no one else
>>> > wanted to) and so I took it on. For the most part, it's a thankless task of
>>> > herding cats (albeit low volume, thankfully), despite the important sounding
>>> > name that marketing types love. I would like us to share the burden across
>>> > the PMC by rotating it on an annual basis. Many other ASF projects do
>>> > exactly this and I think it removes any political pressure. Have I sold it
>>> > enough? ;-) Besides, I just know others are dying to file board reports on
>>> > a quarterly basis!
>>> > >
>>> > > More inline below...
>>> > >
>>> > > On May 5, 2011, at 8:27 AM, Michael McCandless wrote:
>>> > >
>>> > >> On Wed, May 4, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org>
>>> > wrote:
>>> > >>> 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.
>>> > >
>>> > > Agreed, but this dovetails w/ the use of IRC. I realize live collab is
>>> > nice, but it discourages those who aren't "in the know" about the channel
>>> > being used from ever contributing. Say, for instance, I'm interested in
>>> > DWPT (DocWriterPerThread), how am I supposed to know that at 8 am EDT on May
>>> > 5th (made up example), three of the committers are going to be talking about
>>> > it on IRC? If there is email about it, then I can participate. Nothing we
>>> > do is so important that it can't wait a few hours or a day, besides the
>>> > fact, that email is damn near instantaneous these days anyway.
>>> > >
>>> > > Also, keep in mind that until about a year ago, most everything was done
>>> > on the mailing list and I think we progressed just fine. Since then, dev@has almost completely dried up in terms of discussions (factoring out JIRA
>>> > mails which have picked up -- which is good) and the large majority of
>>> > discussion takes place on IRC. I agree, however, we should have the IRC
>>> > discussion on another thread.
>>> > >
>>> > >>
>>> > >>
>>> > >>> 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.
>>> > >>
>>> > >> 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.
>>> > >
>>> > > Yeah, I agree. The hard part for me, is I often feel like people on the
>>> > outside make big deals about this stuff and don't get that even having the
>>> > discussion is a very healthy sign. Besides the fact, that no one likes
>>> > confrontation and uncomfortable topics. We also, I think, are all tired of
>>> > endless debates that go on and on w/ no resolution. It's one of the big
>>> > downsides (and, of course, upsides) to consensus based open source as
>>> > opposed to the dictatorial approach.
>>> > >
>>> > >>
>>> > >> 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.
>>> > >
>>> > > I hopefully would agree we are good stewards of the fact that we employ a
>>> > good number of committers (but not nearly all the active ones), but I know
>>> > some disagree. I do, however, think that the recent spat shows that we at
>>> > Lucid are still free to speak our minds when it comes to open source, as
>>> > clearly not all Lucid employees agree on the issue and were pretty outspoken
>>> > about it. I firmly believe we baked this into the company from Day 1 and I
>>> > consider it one of our best strengths, but of course, most can't see that
>>> > from the outside. Does that mean we are perfect? Of course not, but I
>>> > think we try to follow the ASF guidelines and show up as individuals. I
>>> > also know we work pretty hard to mind the ASF TM policy, etc. (just ask our
>>> > marketing folks how much I remind them.) I think we all realize that there
>>> > would be no such thing as Lucid if it weren't for the ASF and for
>>> > Lucene/Solr, so why would we want to hurt that?
>>> > >
>>> > > The fact is, every single committer here and a good number of
>>> > contributors are paid to work on Lucene all day, (most) every day or have
>>> > some other financial stake (i.e. via a book, consulting biz, etc.) Any of
>>> > us could be accused of only acting in our own financial interest. At the
>>> > end of the day, I like to think that instead, the cool thing is we all have
>>> > a great opportunity to have our financial interests aligned with a great
>>> > project that we like to work on.
>>> > >
>>> > > For the record, we have pretty diverse PMC and committer base. As I said
>>> > in our Dec. 2010 Board Report, we are comprised of:
>>> > > "[a] total to 17 PMC members from 12 different
>>> > > companies, spanning the globe. The flagship Lucene/Solr
>>> > > has 26 total committers from 20 different companies, again
>>> > > spanning the globe."
>>> > >
>>> > > The only one that has changed since then is Robert has joined Lucid.
>>> > Now, one can argue that some of those members from other companies are not
>>> > active, but that isn't Lucid's fault. ASF development has always been about
>>> > those who do the work and we do a fair amount of that. Those who are not
>>> > active, should, ideally, leave on their own by stating they wish to go
>>> > Emeritus. Beyond that, we have a pretty standard policy that inactive
>>> > people are removed after 1 year of no activity. That has been the case
>>> > since I joined Lucene way back when and I think makes sense.
>>> > >
>>> > >
>>> > >
>>> > >
>>> >
>>> >
>>> >
>>
>
Re: Special Board Report for May 2011
Posted by Simon Willnauer <si...@googlemail.com>.
On Sat, May 7, 2011 at 9:52 AM, Greg Stein <gs...@gmail.com> wrote:
> I've seen several people note that "IRC is not logged". Fine. LOG IT.
>
> I see absolutely no reason for you guys not to set up logging for the
> channel that you use. We do this for Subversion development:
> http://colabti.org/irclogger/irclogger_logs/svn-dev
>
> If IRC is posing so much of a problem, then just log it. I saw a
> comment about civility on the channel. Well... if it is logged, then
> you may see that fixed. Discussions can then be referenced when it is
> brought to the dev list. And people can always refer back to the log
> to read about the nuances around some particular discussion.
>
> Seems to be a simple solution to me.
huge +1! IRC is so powerful we should not put it down just because we
don't log the channel.
We already have a logged channel #lucene-dev and its logged here
http://colabti.org/irclogger/irclogger_logs/lucene-dev
having tech discussion there should be ok I think and for major
decisions we can still send a mail to dev@l.a.o referencing the
discussion. I think we all have the discipline to do that right?
I am moving there now... we should also eventually add this channel to
the website and maybe mark #lucene as the user channel?
Simon
>
> Cheers,
> -g
>
> On Fri, May 06, 2011 at 10:17:07PM +0300, Shai Erera wrote:
>> bq. shall I say required reading?
>>
>> You should ! If only so that people don't miss that great article :)
>>
>> On IRC, I agree with Grant (and partly w/ Mike). IMO, we should scale down
>> the amount of discussion on IRC. While there are several advantages to IRC
>> (faster response time, easier to hash things out etc.), I think there are
>> several drawbacks:
>>
>> * As Grant mentioned, TimeZone -- IRC makes it hard for people to follow
>> discussions that happened while they were asleep
>>
>> * IRC is not logged
>>
>> * Even trying to follow discussions on IRC, the nature of the UI sometimes
>> makes it too hard. Many times I've seen two and more discussions happen
>> simultaneously, and the way the UI is constructed, they're all mixed with
>> each other. This is not so with email threads.
>>
>> * I myself have too many communication mediums I need to follow today: my
>> job's email and messaging system, Gmail (Lucene and other mailing lists, as
>> well as private stuff), phone, people stopping by for questions .. IRC is a
>> very busy and demanding channel. You're kinda expected to respond
>> immediately (which is why, I think, it's easier to hash things out -- the
>> response time is instantaneous). If you only want to follow, you must stay
>> tuned to it. If I turn on "flash the taskbar for new messages", it drives me
>> crazy. If I turn it off, I miss important discussions ... it's impossible
>> :).
>> With emails, I can prioritize things. At least, Gmail helps to some extent.
>> That that we now receive all JIRA emails under one thread is a great
>> progress too.
>> With emails, I can always go back when I have time, and re-read the
>> discussion. I can respond to it 2 days after the last email, and people will
>> immediately know what I respond about, because we can include quoted text.
>> And if people's memory is very bad, they can (at least in Gmail) scan
>> quickly previous messages. Hack ... I can do that 1 month after the email
>> was sent, and most people will be able to quickly pick up from where we
>> left. This is not so with IRC ...
>>
>> * Getting in the middle of a discussion is practically impossible on IRC. I
>> have nothing to read for reference (unless I had my IRC client open and I
>> turned on the 'logging' feature).
>>
>> * Is it really that easier to hash things out on IRC? I mean, the response
>> time is great, so you get answers really quick. But then, there are usually
>> only a handful of participants in that discussion, which makes hashing out
>> and agreeing much easier anyway. If the same group of people (usually <=3)
>> communicated in email, they'd hash things out in almost the same speed.
>> After all, IRC mandates they are all awake at the same time, so they could
>> also email each other in NRT :).
>>
>> * Imagine this discussion happening on IRC. Most of us would have been able
>> to pick only shards of it. At some point, maybe Grant or another PMC member
>> would 'summarize' the discussion to the list. The summary could be "we've
>> decided to not use IRC because email is better", followed by some points
>> he's able to pull back from his memory and maybe IRC log. Would *you*
>> (people reading this growing-by-the-minute note) want to get a summary like
>> that? Would you be satisfied?
>> I think that most of us wouldn't and all that would happen is that such
>> email would start its own thread, repeating mostly what have been said on
>> IRC, b/c people would want answers ...
>>
>> I'm not against IRC, don't get me wrong. I think it's useful b/c the
>> turnaround time is great. But we should not have so many discussions there,
>> as we do today. I don't know where to draw the line. I trust the great
>> people of this community to know when it's better to discuss something in
>> email. An example, if a new feature is being discussed, then it's ok if two
>> people want to hash few things out quickly, before they send a detailed and
>> organized proposal to the list -- the details to hash out are the initial
>> proposal's details. The rest should be followed on list, even if it means
>> slightly slower response time.
>>
>> Today's list and JIRA volume always look to me like the response time is
>> instantaneous. We have very active people from around the globe, so you have
>> a high chance receiving response in no time. In the worse case, it will take
>> a couple of hours, but I don't remember when did that happen (which is an
>> amazing thing !)
>>
>> Cheers,
>> Shai
>>
>> On Fri, May 6, 2011 at 8:35 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>
>> > More reading (shall I say required reading?). Benson does a good job of
>> > explaining some of the concepts around consensus and why we also should be
>> > primarily using mailing lists:
>> > https://blogs.apache.org/comdev/entry/how_apache_projects_use_consensus
>> >
>> > -Grant
>> >
>> > On May 5, 2011, at 10:10 AM, Grant Ingersoll wrote:
>> >
>> > >
>> > > I'd like to throw out another idea:
>> > >
>> > > I think we should standardize on rotating the PMC Chair every year. I
>> > think to date, there have been two Chairs: Doug and me. Back when Doug
>> > left, no one wanted to do it (both Hoss and I said we would if no one else
>> > wanted to) and so I took it on. For the most part, it's a thankless task of
>> > herding cats (albeit low volume, thankfully), despite the important sounding
>> > name that marketing types love. I would like us to share the burden across
>> > the PMC by rotating it on an annual basis. Many other ASF projects do
>> > exactly this and I think it removes any political pressure. Have I sold it
>> > enough? ;-) Besides, I just know others are dying to file board reports on
>> > a quarterly basis!
>> > >
>> > > More inline below...
>> > >
>> > > On May 5, 2011, at 8:27 AM, Michael McCandless wrote:
>> > >
>> > >> On Wed, May 4, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org>
>> > wrote:
>> > >>> 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.
>> > >
>> > > Agreed, but this dovetails w/ the use of IRC. I realize live collab is
>> > nice, but it discourages those who aren't "in the know" about the channel
>> > being used from ever contributing. Say, for instance, I'm interested in
>> > DWPT (DocWriterPerThread), how am I supposed to know that at 8 am EDT on May
>> > 5th (made up example), three of the committers are going to be talking about
>> > it on IRC? If there is email about it, then I can participate. Nothing we
>> > do is so important that it can't wait a few hours or a day, besides the
>> > fact, that email is damn near instantaneous these days anyway.
>> > >
>> > > Also, keep in mind that until about a year ago, most everything was done
>> > on the mailing list and I think we progressed just fine. Since then, dev@has almost completely dried up in terms of discussions (factoring out JIRA
>> > mails which have picked up -- which is good) and the large majority of
>> > discussion takes place on IRC. I agree, however, we should have the IRC
>> > discussion on another thread.
>> > >
>> > >>
>> > >>
>> > >>> 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.
>> > >>
>> > >> 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.
>> > >
>> > > Yeah, I agree. The hard part for me, is I often feel like people on the
>> > outside make big deals about this stuff and don't get that even having the
>> > discussion is a very healthy sign. Besides the fact, that no one likes
>> > confrontation and uncomfortable topics. We also, I think, are all tired of
>> > endless debates that go on and on w/ no resolution. It's one of the big
>> > downsides (and, of course, upsides) to consensus based open source as
>> > opposed to the dictatorial approach.
>> > >
>> > >>
>> > >> 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.
>> > >
>> > > I hopefully would agree we are good stewards of the fact that we employ a
>> > good number of committers (but not nearly all the active ones), but I know
>> > some disagree. I do, however, think that the recent spat shows that we at
>> > Lucid are still free to speak our minds when it comes to open source, as
>> > clearly not all Lucid employees agree on the issue and were pretty outspoken
>> > about it. I firmly believe we baked this into the company from Day 1 and I
>> > consider it one of our best strengths, but of course, most can't see that
>> > from the outside. Does that mean we are perfect? Of course not, but I
>> > think we try to follow the ASF guidelines and show up as individuals. I
>> > also know we work pretty hard to mind the ASF TM policy, etc. (just ask our
>> > marketing folks how much I remind them.) I think we all realize that there
>> > would be no such thing as Lucid if it weren't for the ASF and for
>> > Lucene/Solr, so why would we want to hurt that?
>> > >
>> > > The fact is, every single committer here and a good number of
>> > contributors are paid to work on Lucene all day, (most) every day or have
>> > some other financial stake (i.e. via a book, consulting biz, etc.) Any of
>> > us could be accused of only acting in our own financial interest. At the
>> > end of the day, I like to think that instead, the cool thing is we all have
>> > a great opportunity to have our financial interests aligned with a great
>> > project that we like to work on.
>> > >
>> > > For the record, we have pretty diverse PMC and committer base. As I said
>> > in our Dec. 2010 Board Report, we are comprised of:
>> > > "[a] total to 17 PMC members from 12 different
>> > > companies, spanning the globe. The flagship Lucene/Solr
>> > > has 26 total committers from 20 different companies, again
>> > > spanning the globe."
>> > >
>> > > The only one that has changed since then is Robert has joined Lucid.
>> > Now, one can argue that some of those members from other companies are not
>> > active, but that isn't Lucid's fault. ASF development has always been about
>> > those who do the work and we do a fair amount of that. Those who are not
>> > active, should, ideally, leave on their own by stating they wish to go
>> > Emeritus. Beyond that, we have a pretty standard policy that inactive
>> > people are removed after 1 year of no activity. That has been the case
>> > since I joined Lucene way back when and I think makes sense.
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>
Re: Special Board Report for May 2011
Posted by Greg Stein <gs...@gmail.com>.
I've seen several people note that "IRC is not logged". Fine. LOG IT.
I see absolutely no reason for you guys not to set up logging for the
channel that you use. We do this for Subversion development:
http://colabti.org/irclogger/irclogger_logs/svn-dev
If IRC is posing so much of a problem, then just log it. I saw a
comment about civility on the channel. Well... if it is logged, then
you may see that fixed. Discussions can then be referenced when it is
brought to the dev list. And people can always refer back to the log
to read about the nuances around some particular discussion.
Seems to be a simple solution to me.
Cheers,
-g
On Fri, May 06, 2011 at 10:17:07PM +0300, Shai Erera wrote:
> bq. shall I say required reading?
>
> You should ! If only so that people don't miss that great article :)
>
> On IRC, I agree with Grant (and partly w/ Mike). IMO, we should scale down
> the amount of discussion on IRC. While there are several advantages to IRC
> (faster response time, easier to hash things out etc.), I think there are
> several drawbacks:
>
> * As Grant mentioned, TimeZone -- IRC makes it hard for people to follow
> discussions that happened while they were asleep
>
> * IRC is not logged
>
> * Even trying to follow discussions on IRC, the nature of the UI sometimes
> makes it too hard. Many times I've seen two and more discussions happen
> simultaneously, and the way the UI is constructed, they're all mixed with
> each other. This is not so with email threads.
>
> * I myself have too many communication mediums I need to follow today: my
> job's email and messaging system, Gmail (Lucene and other mailing lists, as
> well as private stuff), phone, people stopping by for questions .. IRC is a
> very busy and demanding channel. You're kinda expected to respond
> immediately (which is why, I think, it's easier to hash things out -- the
> response time is instantaneous). If you only want to follow, you must stay
> tuned to it. If I turn on "flash the taskbar for new messages", it drives me
> crazy. If I turn it off, I miss important discussions ... it's impossible
> :).
> With emails, I can prioritize things. At least, Gmail helps to some extent.
> That that we now receive all JIRA emails under one thread is a great
> progress too.
> With emails, I can always go back when I have time, and re-read the
> discussion. I can respond to it 2 days after the last email, and people will
> immediately know what I respond about, because we can include quoted text.
> And if people's memory is very bad, they can (at least in Gmail) scan
> quickly previous messages. Hack ... I can do that 1 month after the email
> was sent, and most people will be able to quickly pick up from where we
> left. This is not so with IRC ...
>
> * Getting in the middle of a discussion is practically impossible on IRC. I
> have nothing to read for reference (unless I had my IRC client open and I
> turned on the 'logging' feature).
>
> * Is it really that easier to hash things out on IRC? I mean, the response
> time is great, so you get answers really quick. But then, there are usually
> only a handful of participants in that discussion, which makes hashing out
> and agreeing much easier anyway. If the same group of people (usually <=3)
> communicated in email, they'd hash things out in almost the same speed.
> After all, IRC mandates they are all awake at the same time, so they could
> also email each other in NRT :).
>
> * Imagine this discussion happening on IRC. Most of us would have been able
> to pick only shards of it. At some point, maybe Grant or another PMC member
> would 'summarize' the discussion to the list. The summary could be "we've
> decided to not use IRC because email is better", followed by some points
> he's able to pull back from his memory and maybe IRC log. Would *you*
> (people reading this growing-by-the-minute note) want to get a summary like
> that? Would you be satisfied?
> I think that most of us wouldn't and all that would happen is that such
> email would start its own thread, repeating mostly what have been said on
> IRC, b/c people would want answers ...
>
> I'm not against IRC, don't get me wrong. I think it's useful b/c the
> turnaround time is great. But we should not have so many discussions there,
> as we do today. I don't know where to draw the line. I trust the great
> people of this community to know when it's better to discuss something in
> email. An example, if a new feature is being discussed, then it's ok if two
> people want to hash few things out quickly, before they send a detailed and
> organized proposal to the list -- the details to hash out are the initial
> proposal's details. The rest should be followed on list, even if it means
> slightly slower response time.
>
> Today's list and JIRA volume always look to me like the response time is
> instantaneous. We have very active people from around the globe, so you have
> a high chance receiving response in no time. In the worse case, it will take
> a couple of hours, but I don't remember when did that happen (which is an
> amazing thing !)
>
> Cheers,
> Shai
>
> On Fri, May 6, 2011 at 8:35 PM, Grant Ingersoll <gs...@apache.org> wrote:
>
> > More reading (shall I say required reading?). Benson does a good job of
> > explaining some of the concepts around consensus and why we also should be
> > primarily using mailing lists:
> > https://blogs.apache.org/comdev/entry/how_apache_projects_use_consensus
> >
> > -Grant
> >
> > On May 5, 2011, at 10:10 AM, Grant Ingersoll wrote:
> >
> > >
> > > I'd like to throw out another idea:
> > >
> > > I think we should standardize on rotating the PMC Chair every year. I
> > think to date, there have been two Chairs: Doug and me. Back when Doug
> > left, no one wanted to do it (both Hoss and I said we would if no one else
> > wanted to) and so I took it on. For the most part, it's a thankless task of
> > herding cats (albeit low volume, thankfully), despite the important sounding
> > name that marketing types love. I would like us to share the burden across
> > the PMC by rotating it on an annual basis. Many other ASF projects do
> > exactly this and I think it removes any political pressure. Have I sold it
> > enough? ;-) Besides, I just know others are dying to file board reports on
> > a quarterly basis!
> > >
> > > More inline below...
> > >
> > > On May 5, 2011, at 8:27 AM, Michael McCandless wrote:
> > >
> > >> On Wed, May 4, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org>
> > wrote:
> > >>> 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.
> > >
> > > Agreed, but this dovetails w/ the use of IRC. I realize live collab is
> > nice, but it discourages those who aren't "in the know" about the channel
> > being used from ever contributing. Say, for instance, I'm interested in
> > DWPT (DocWriterPerThread), how am I supposed to know that at 8 am EDT on May
> > 5th (made up example), three of the committers are going to be talking about
> > it on IRC? If there is email about it, then I can participate. Nothing we
> > do is so important that it can't wait a few hours or a day, besides the
> > fact, that email is damn near instantaneous these days anyway.
> > >
> > > Also, keep in mind that until about a year ago, most everything was done
> > on the mailing list and I think we progressed just fine. Since then, dev@has almost completely dried up in terms of discussions (factoring out JIRA
> > mails which have picked up -- which is good) and the large majority of
> > discussion takes place on IRC. I agree, however, we should have the IRC
> > discussion on another thread.
> > >
> > >>
> > >>
> > >>> 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.
> > >>
> > >> 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.
> > >
> > > Yeah, I agree. The hard part for me, is I often feel like people on the
> > outside make big deals about this stuff and don't get that even having the
> > discussion is a very healthy sign. Besides the fact, that no one likes
> > confrontation and uncomfortable topics. We also, I think, are all tired of
> > endless debates that go on and on w/ no resolution. It's one of the big
> > downsides (and, of course, upsides) to consensus based open source as
> > opposed to the dictatorial approach.
> > >
> > >>
> > >> 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.
> > >
> > > I hopefully would agree we are good stewards of the fact that we employ a
> > good number of committers (but not nearly all the active ones), but I know
> > some disagree. I do, however, think that the recent spat shows that we at
> > Lucid are still free to speak our minds when it comes to open source, as
> > clearly not all Lucid employees agree on the issue and were pretty outspoken
> > about it. I firmly believe we baked this into the company from Day 1 and I
> > consider it one of our best strengths, but of course, most can't see that
> > from the outside. Does that mean we are perfect? Of course not, but I
> > think we try to follow the ASF guidelines and show up as individuals. I
> > also know we work pretty hard to mind the ASF TM policy, etc. (just ask our
> > marketing folks how much I remind them.) I think we all realize that there
> > would be no such thing as Lucid if it weren't for the ASF and for
> > Lucene/Solr, so why would we want to hurt that?
> > >
> > > The fact is, every single committer here and a good number of
> > contributors are paid to work on Lucene all day, (most) every day or have
> > some other financial stake (i.e. via a book, consulting biz, etc.) Any of
> > us could be accused of only acting in our own financial interest. At the
> > end of the day, I like to think that instead, the cool thing is we all have
> > a great opportunity to have our financial interests aligned with a great
> > project that we like to work on.
> > >
> > > For the record, we have pretty diverse PMC and committer base. As I said
> > in our Dec. 2010 Board Report, we are comprised of:
> > > "[a] total to 17 PMC members from 12 different
> > > companies, spanning the globe. The flagship Lucene/Solr
> > > has 26 total committers from 20 different companies, again
> > > spanning the globe."
> > >
> > > The only one that has changed since then is Robert has joined Lucid.
> > Now, one can argue that some of those members from other companies are not
> > active, but that isn't Lucid's fault. ASF development has always been about
> > those who do the work and we do a fair amount of that. Those who are not
> > active, should, ideally, leave on their own by stating they wish to go
> > Emeritus. Beyond that, we have a pretty standard policy that inactive
> > people are removed after 1 year of no activity. That has been the case
> > since I joined Lucene way back when and I think makes sense.
> > >
> > >
> > >
> > >
> >
> >
> >
Re: Special Board Report for May 2011
Posted by Upayavira <uv...@odoko.co.uk>.
To put it simply, IRC can be great for solving "my" problem, but is not
a good too for solving "our" problems.
That is, my Solr system won't do XYZ, and I can't work out why. We
discuss it, explore, work it out, and I'm happy. No-one has missed
anything much, because it was just a few folks helping me sort out my
own tiny problem.
But if that problem is shared (e.g. how to implement ABC feature in
Solr) then we loose out because we are not pulling on the full range of
experience that exists on the list, and we also go faster than some
participants can muster.
So, as soon as a problem explored on IRC ceases to be the domain of just
one person, and we start looking at something more general, it should
move over to a mailing list.
That's my take on it anyhow.
Upayavira
On Fri, 06 May 2011 22:17 +0300, "Shai Erera" <se...@gmail.com> wrote:
> bq. shall I say required reading?
>
> You should ! If only so that people don't miss that great article :)
>
> On IRC, I agree with Grant (and partly w/ Mike). IMO, we should scale
> down
> the amount of discussion on IRC. While there are several advantages to
> IRC
> (faster response time, easier to hash things out etc.), I think there are
> several drawbacks:
>
> * As Grant mentioned, TimeZone -- IRC makes it hard for people to follow
> discussions that happened while they were asleep
>
> * IRC is not logged
>
> * Even trying to follow discussions on IRC, the nature of the UI
> sometimes
> makes it too hard. Many times I've seen two and more discussions happen
> simultaneously, and the way the UI is constructed, they're all mixed with
> each other. This is not so with email threads.
>
> * I myself have too many communication mediums I need to follow today: my
> job's email and messaging system, Gmail (Lucene and other mailing lists,
> as
> well as private stuff), phone, people stopping by for questions .. IRC is
> a
> very busy and demanding channel. You're kinda expected to respond
> immediately (which is why, I think, it's easier to hash things out -- the
> response time is instantaneous). If you only want to follow, you must
> stay
> tuned to it. If I turn on "flash the taskbar for new messages", it drives
> me
> crazy. If I turn it off, I miss important discussions ... it's impossible
> :).
> With emails, I can prioritize things. At least, Gmail helps to some
> extent.
> That that we now receive all JIRA emails under one thread is a great
> progress too.
> With emails, I can always go back when I have time, and re-read the
> discussion. I can respond to it 2 days after the last email, and people
> will
> immediately know what I respond about, because we can include quoted
> text.
> And if people's memory is very bad, they can (at least in Gmail) scan
> quickly previous messages. Hack ... I can do that 1 month after the email
> was sent, and most people will be able to quickly pick up from where we
> left. This is not so with IRC ...
>
> * Getting in the middle of a discussion is practically impossible on IRC.
> I
> have nothing to read for reference (unless I had my IRC client open and I
> turned on the 'logging' feature).
>
> * Is it really that easier to hash things out on IRC? I mean, the
> response
> time is great, so you get answers really quick. But then, there are
> usually
> only a handful of participants in that discussion, which makes hashing
> out
> and agreeing much easier anyway. If the same group of people (usually
> <=3)
> communicated in email, they'd hash things out in almost the same speed.
> After all, IRC mandates they are all awake at the same time, so they
> could
> also email each other in NRT :).
>
> * Imagine this discussion happening on IRC. Most of us would have been
> able
> to pick only shards of it. At some point, maybe Grant or another PMC
> member
> would 'summarize' the discussion to the list. The summary could be "we've
> decided to not use IRC because email is better", followed by some points
> he's able to pull back from his memory and maybe IRC log. Would *you*
> (people reading this growing-by-the-minute note) want to get a summary
> like
> that? Would you be satisfied?
> I think that most of us wouldn't and all that would happen is that such
> email would start its own thread, repeating mostly what have been said on
> IRC, b/c people would want answers ...
>
> I'm not against IRC, don't get me wrong. I think it's useful b/c the
> turnaround time is great. But we should not have so many discussions
> there,
> as we do today. I don't know where to draw the line. I trust the great
> people of this community to know when it's better to discuss something in
> email. An example, if a new feature is being discussed, then it's ok if
> two
> people want to hash few things out quickly, before they send a detailed
> and
> organized proposal to the list -- the details to hash out are the initial
> proposal's details. The rest should be followed on list, even if it means
> slightly slower response time.
>
> Today's list and JIRA volume always look to me like the response time is
> instantaneous. We have very active people from around the globe, so you
> have
> a high chance receiving response in no time. In the worse case, it will
> take
> a couple of hours, but I don't remember when did that happen (which is an
> amazing thing !)
>
> Cheers,
> Shai
>
> On Fri, May 6, 2011 at 8:35 PM, Grant Ingersoll <gs...@apache.org>
> wrote:
>
> > More reading (shall I say required reading?). Benson does a good job of
> > explaining some of the concepts around consensus and why we also should be
> > primarily using mailing lists:
> > https://blogs.apache.org/comdev/entry/how_apache_projects_use_consensus
> >
> > -Grant
> >
> > On May 5, 2011, at 10:10 AM, Grant Ingersoll wrote:
> >
> > >
> > > I'd like to throw out another idea:
> > >
> > > I think we should standardize on rotating the PMC Chair every year. I
> > think to date, there have been two Chairs: Doug and me. Back when Doug
> > left, no one wanted to do it (both Hoss and I said we would if no one else
> > wanted to) and so I took it on. For the most part, it's a thankless task of
> > herding cats (albeit low volume, thankfully), despite the important sounding
> > name that marketing types love. I would like us to share the burden across
> > the PMC by rotating it on an annual basis. Many other ASF projects do
> > exactly this and I think it removes any political pressure. Have I sold it
> > enough? ;-) Besides, I just know others are dying to file board reports on
> > a quarterly basis!
> > >
> > > More inline below...
> > >
> > > On May 5, 2011, at 8:27 AM, Michael McCandless wrote:
> > >
> > >> On Wed, May 4, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org>
> > wrote:
> > >>> 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.
> > >
> > > Agreed, but this dovetails w/ the use of IRC. I realize live collab is
> > nice, but it discourages those who aren't "in the know" about the channel
> > being used from ever contributing. Say, for instance, I'm interested in
> > DWPT (DocWriterPerThread), how am I supposed to know that at 8 am EDT on May
> > 5th (made up example), three of the committers are going to be talking about
> > it on IRC? If there is email about it, then I can participate. Nothing we
> > do is so important that it can't wait a few hours or a day, besides the
> > fact, that email is damn near instantaneous these days anyway.
> > >
> > > Also, keep in mind that until about a year ago, most everything was done
> > on the mailing list and I think we progressed just fine. Since then, dev@has almost completely dried up in terms of discussions (factoring out JIRA
> > mails which have picked up -- which is good) and the large majority of
> > discussion takes place on IRC. I agree, however, we should have the IRC
> > discussion on another thread.
> > >
> > >>
> > >>
> > >>> 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.
> > >>
> > >> 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.
> > >
> > > Yeah, I agree. The hard part for me, is I often feel like people on the
> > outside make big deals about this stuff and don't get that even having the
> > discussion is a very healthy sign. Besides the fact, that no one likes
> > confrontation and uncomfortable topics. We also, I think, are all tired of
> > endless debates that go on and on w/ no resolution. It's one of the big
> > downsides (and, of course, upsides) to consensus based open source as
> > opposed to the dictatorial approach.
> > >
> > >>
> > >> 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.
> > >
> > > I hopefully would agree we are good stewards of the fact that we employ a
> > good number of committers (but not nearly all the active ones), but I know
> > some disagree. I do, however, think that the recent spat shows that we at
> > Lucid are still free to speak our minds when it comes to open source, as
> > clearly not all Lucid employees agree on the issue and were pretty outspoken
> > about it. I firmly believe we baked this into the company from Day 1 and I
> > consider it one of our best strengths, but of course, most can't see that
> > from the outside. Does that mean we are perfect? Of course not, but I
> > think we try to follow the ASF guidelines and show up as individuals. I
> > also know we work pretty hard to mind the ASF TM policy, etc. (just ask our
> > marketing folks how much I remind them.) I think we all realize that there
> > would be no such thing as Lucid if it weren't for the ASF and for
> > Lucene/Solr, so why would we want to hurt that?
> > >
> > > The fact is, every single committer here and a good number of
> > contributors are paid to work on Lucene all day, (most) every day or have
> > some other financial stake (i.e. via a book, consulting biz, etc.) Any of
> > us could be accused of only acting in our own financial interest. At the
> > end of the day, I like to think that instead, the cool thing is we all have
> > a great opportunity to have our financial interests aligned with a great
> > project that we like to work on.
> > >
> > > For the record, we have pretty diverse PMC and committer base. As I said
> > in our Dec. 2010 Board Report, we are comprised of:
> > > "[a] total to 17 PMC members from 12 different
> > > companies, spanning the globe. The flagship Lucene/Solr
> > > has 26 total committers from 20 different companies, again
> > > spanning the globe."
> > >
> > > The only one that has changed since then is Robert has joined Lucid.
> > Now, one can argue that some of those members from other companies are not
> > active, but that isn't Lucid's fault. ASF development has always been about
> > those who do the work and we do a fair amount of that. Those who are not
> > active, should, ideally, leave on their own by stating they wish to go
> > Emeritus. Beyond that, we have a pretty standard policy that inactive
> > people are removed after 1 year of no activity. That has been the case
> > since I joined Lucene way back when and I think makes sense.
> > >
> > >
> > >
> > >
> >
> >
> >
>
Re: Special Board Report for May 2011
Posted by Shai Erera <se...@gmail.com>.
bq. shall I say required reading?
You should ! If only so that people don't miss that great article :)
On IRC, I agree with Grant (and partly w/ Mike). IMO, we should scale down
the amount of discussion on IRC. While there are several advantages to IRC
(faster response time, easier to hash things out etc.), I think there are
several drawbacks:
* As Grant mentioned, TimeZone -- IRC makes it hard for people to follow
discussions that happened while they were asleep
* IRC is not logged
* Even trying to follow discussions on IRC, the nature of the UI sometimes
makes it too hard. Many times I've seen two and more discussions happen
simultaneously, and the way the UI is constructed, they're all mixed with
each other. This is not so with email threads.
* I myself have too many communication mediums I need to follow today: my
job's email and messaging system, Gmail (Lucene and other mailing lists, as
well as private stuff), phone, people stopping by for questions .. IRC is a
very busy and demanding channel. You're kinda expected to respond
immediately (which is why, I think, it's easier to hash things out -- the
response time is instantaneous). If you only want to follow, you must stay
tuned to it. If I turn on "flash the taskbar for new messages", it drives me
crazy. If I turn it off, I miss important discussions ... it's impossible
:).
With emails, I can prioritize things. At least, Gmail helps to some extent.
That that we now receive all JIRA emails under one thread is a great
progress too.
With emails, I can always go back when I have time, and re-read the
discussion. I can respond to it 2 days after the last email, and people will
immediately know what I respond about, because we can include quoted text.
And if people's memory is very bad, they can (at least in Gmail) scan
quickly previous messages. Hack ... I can do that 1 month after the email
was sent, and most people will be able to quickly pick up from where we
left. This is not so with IRC ...
* Getting in the middle of a discussion is practically impossible on IRC. I
have nothing to read for reference (unless I had my IRC client open and I
turned on the 'logging' feature).
* Is it really that easier to hash things out on IRC? I mean, the response
time is great, so you get answers really quick. But then, there are usually
only a handful of participants in that discussion, which makes hashing out
and agreeing much easier anyway. If the same group of people (usually <=3)
communicated in email, they'd hash things out in almost the same speed.
After all, IRC mandates they are all awake at the same time, so they could
also email each other in NRT :).
* Imagine this discussion happening on IRC. Most of us would have been able
to pick only shards of it. At some point, maybe Grant or another PMC member
would 'summarize' the discussion to the list. The summary could be "we've
decided to not use IRC because email is better", followed by some points
he's able to pull back from his memory and maybe IRC log. Would *you*
(people reading this growing-by-the-minute note) want to get a summary like
that? Would you be satisfied?
I think that most of us wouldn't and all that would happen is that such
email would start its own thread, repeating mostly what have been said on
IRC, b/c people would want answers ...
I'm not against IRC, don't get me wrong. I think it's useful b/c the
turnaround time is great. But we should not have so many discussions there,
as we do today. I don't know where to draw the line. I trust the great
people of this community to know when it's better to discuss something in
email. An example, if a new feature is being discussed, then it's ok if two
people want to hash few things out quickly, before they send a detailed and
organized proposal to the list -- the details to hash out are the initial
proposal's details. The rest should be followed on list, even if it means
slightly slower response time.
Today's list and JIRA volume always look to me like the response time is
instantaneous. We have very active people from around the globe, so you have
a high chance receiving response in no time. In the worse case, it will take
a couple of hours, but I don't remember when did that happen (which is an
amazing thing !)
Cheers,
Shai
On Fri, May 6, 2011 at 8:35 PM, Grant Ingersoll <gs...@apache.org> wrote:
> More reading (shall I say required reading?). Benson does a good job of
> explaining some of the concepts around consensus and why we also should be
> primarily using mailing lists:
> https://blogs.apache.org/comdev/entry/how_apache_projects_use_consensus
>
> -Grant
>
> On May 5, 2011, at 10:10 AM, Grant Ingersoll wrote:
>
> >
> > I'd like to throw out another idea:
> >
> > I think we should standardize on rotating the PMC Chair every year. I
> think to date, there have been two Chairs: Doug and me. Back when Doug
> left, no one wanted to do it (both Hoss and I said we would if no one else
> wanted to) and so I took it on. For the most part, it's a thankless task of
> herding cats (albeit low volume, thankfully), despite the important sounding
> name that marketing types love. I would like us to share the burden across
> the PMC by rotating it on an annual basis. Many other ASF projects do
> exactly this and I think it removes any political pressure. Have I sold it
> enough? ;-) Besides, I just know others are dying to file board reports on
> a quarterly basis!
> >
> > More inline below...
> >
> > On May 5, 2011, at 8:27 AM, Michael McCandless wrote:
> >
> >> On Wed, May 4, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org>
> wrote:
> >>> 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.
> >
> > Agreed, but this dovetails w/ the use of IRC. I realize live collab is
> nice, but it discourages those who aren't "in the know" about the channel
> being used from ever contributing. Say, for instance, I'm interested in
> DWPT (DocWriterPerThread), how am I supposed to know that at 8 am EDT on May
> 5th (made up example), three of the committers are going to be talking about
> it on IRC? If there is email about it, then I can participate. Nothing we
> do is so important that it can't wait a few hours or a day, besides the
> fact, that email is damn near instantaneous these days anyway.
> >
> > Also, keep in mind that until about a year ago, most everything was done
> on the mailing list and I think we progressed just fine. Since then, dev@has almost completely dried up in terms of discussions (factoring out JIRA
> mails which have picked up -- which is good) and the large majority of
> discussion takes place on IRC. I agree, however, we should have the IRC
> discussion on another thread.
> >
> >>
> >>
> >>> 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.
> >>
> >> 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.
> >
> > Yeah, I agree. The hard part for me, is I often feel like people on the
> outside make big deals about this stuff and don't get that even having the
> discussion is a very healthy sign. Besides the fact, that no one likes
> confrontation and uncomfortable topics. We also, I think, are all tired of
> endless debates that go on and on w/ no resolution. It's one of the big
> downsides (and, of course, upsides) to consensus based open source as
> opposed to the dictatorial approach.
> >
> >>
> >> 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.
> >
> > I hopefully would agree we are good stewards of the fact that we employ a
> good number of committers (but not nearly all the active ones), but I know
> some disagree. I do, however, think that the recent spat shows that we at
> Lucid are still free to speak our minds when it comes to open source, as
> clearly not all Lucid employees agree on the issue and were pretty outspoken
> about it. I firmly believe we baked this into the company from Day 1 and I
> consider it one of our best strengths, but of course, most can't see that
> from the outside. Does that mean we are perfect? Of course not, but I
> think we try to follow the ASF guidelines and show up as individuals. I
> also know we work pretty hard to mind the ASF TM policy, etc. (just ask our
> marketing folks how much I remind them.) I think we all realize that there
> would be no such thing as Lucid if it weren't for the ASF and for
> Lucene/Solr, so why would we want to hurt that?
> >
> > The fact is, every single committer here and a good number of
> contributors are paid to work on Lucene all day, (most) every day or have
> some other financial stake (i.e. via a book, consulting biz, etc.) Any of
> us could be accused of only acting in our own financial interest. At the
> end of the day, I like to think that instead, the cool thing is we all have
> a great opportunity to have our financial interests aligned with a great
> project that we like to work on.
> >
> > For the record, we have pretty diverse PMC and committer base. As I said
> in our Dec. 2010 Board Report, we are comprised of:
> > "[a] total to 17 PMC members from 12 different
> > companies, spanning the globe. The flagship Lucene/Solr
> > has 26 total committers from 20 different companies, again
> > spanning the globe."
> >
> > The only one that has changed since then is Robert has joined Lucid.
> Now, one can argue that some of those members from other companies are not
> active, but that isn't Lucid's fault. ASF development has always been about
> those who do the work and we do a fair amount of that. Those who are not
> active, should, ideally, leave on their own by stating they wish to go
> Emeritus. Beyond that, we have a pretty standard policy that inactive
> people are removed after 1 year of no activity. That has been the case
> since I joined Lucene way back when and I think makes sense.
> >
> >
> >
> >
>
>
>
Re: Special Board Report for May 2011
Posted by Grant Ingersoll <gs...@apache.org>.
More reading (shall I say required reading?). Benson does a good job of explaining some of the concepts around consensus and why we also should be primarily using mailing lists:
https://blogs.apache.org/comdev/entry/how_apache_projects_use_consensus
-Grant
On May 5, 2011, at 10:10 AM, Grant Ingersoll wrote:
>
> I'd like to throw out another idea:
>
> I think we should standardize on rotating the PMC Chair every year. I think to date, there have been two Chairs: Doug and me. Back when Doug left, no one wanted to do it (both Hoss and I said we would if no one else wanted to) and so I took it on. For the most part, it's a thankless task of herding cats (albeit low volume, thankfully), despite the important sounding name that marketing types love. I would like us to share the burden across the PMC by rotating it on an annual basis. Many other ASF projects do exactly this and I think it removes any political pressure. Have I sold it enough? ;-) Besides, I just know others are dying to file board reports on a quarterly basis!
>
> More inline below...
>
> On May 5, 2011, at 8:27 AM, Michael McCandless wrote:
>
>> On Wed, May 4, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>> 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.
>
> Agreed, but this dovetails w/ the use of IRC. I realize live collab is nice, but it discourages those who aren't "in the know" about the channel being used from ever contributing. Say, for instance, I'm interested in DWPT (DocWriterPerThread), how am I supposed to know that at 8 am EDT on May 5th (made up example), three of the committers are going to be talking about it on IRC? If there is email about it, then I can participate. Nothing we do is so important that it can't wait a few hours or a day, besides the fact, that email is damn near instantaneous these days anyway.
>
> Also, keep in mind that until about a year ago, most everything was done on the mailing list and I think we progressed just fine. Since then, dev@ has almost completely dried up in terms of discussions (factoring out JIRA mails which have picked up -- which is good) and the large majority of discussion takes place on IRC. I agree, however, we should have the IRC discussion on another thread.
>
>>
>>
>>> 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.
>>
>> 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.
>
> Yeah, I agree. The hard part for me, is I often feel like people on the outside make big deals about this stuff and don't get that even having the discussion is a very healthy sign. Besides the fact, that no one likes confrontation and uncomfortable topics. We also, I think, are all tired of endless debates that go on and on w/ no resolution. It's one of the big downsides (and, of course, upsides) to consensus based open source as opposed to the dictatorial approach.
>
>>
>> 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.
>
> I hopefully would agree we are good stewards of the fact that we employ a good number of committers (but not nearly all the active ones), but I know some disagree. I do, however, think that the recent spat shows that we at Lucid are still free to speak our minds when it comes to open source, as clearly not all Lucid employees agree on the issue and were pretty outspoken about it. I firmly believe we baked this into the company from Day 1 and I consider it one of our best strengths, but of course, most can't see that from the outside. Does that mean we are perfect? Of course not, but I think we try to follow the ASF guidelines and show up as individuals. I also know we work pretty hard to mind the ASF TM policy, etc. (just ask our marketing folks how much I remind them.) I think we all realize that there would be no such thing as Lucid if it weren't for the ASF and for Lucene/Solr, so why would we want to hurt that?
>
> The fact is, every single committer here and a good number of contributors are paid to work on Lucene all day, (most) every day or have some other financial stake (i.e. via a book, consulting biz, etc.) Any of us could be accused of only acting in our own financial interest. At the end of the day, I like to think that instead, the cool thing is we all have a great opportunity to have our financial interests aligned with a great project that we like to work on.
>
> For the record, we have pretty diverse PMC and committer base. As I said in our Dec. 2010 Board Report, we are comprised of:
> "[a] total to 17 PMC members from 12 different
> companies, spanning the globe. The flagship Lucene/Solr
> has 26 total committers from 20 different companies, again
> spanning the globe."
>
> The only one that has changed since then is Robert has joined Lucid. Now, one can argue that some of those members from other companies are not active, but that isn't Lucid's fault. ASF development has always been about those who do the work and we do a fair amount of that. Those who are not active, should, ideally, leave on their own by stating they wish to go Emeritus. Beyond that, we have a pretty standard policy that inactive people are removed after 1 year of no activity. That has been the case since I joined Lucene way back when and I think makes sense.
>
>
>
>
Re: Special Board Report for May 2011
Posted by Grant Ingersoll <gs...@apache.org>.
I'd like to throw out another idea:
I think we should standardize on rotating the PMC Chair every year. I think to date, there have been two Chairs: Doug and me. Back when Doug left, no one wanted to do it (both Hoss and I said we would if no one else wanted to) and so I took it on. For the most part, it's a thankless task of herding cats (albeit low volume, thankfully), despite the important sounding name that marketing types love. I would like us to share the burden across the PMC by rotating it on an annual basis. Many other ASF projects do exactly this and I think it removes any political pressure. Have I sold it enough? ;-) Besides, I just know others are dying to file board reports on a quarterly basis!
More inline below...
On May 5, 2011, at 8:27 AM, Michael McCandless wrote:
> On Wed, May 4, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org> wrote:
>> 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.
Agreed, but this dovetails w/ the use of IRC. I realize live collab is nice, but it discourages those who aren't "in the know" about the channel being used from ever contributing. Say, for instance, I'm interested in DWPT (DocWriterPerThread), how am I supposed to know that at 8 am EDT on May 5th (made up example), three of the committers are going to be talking about it on IRC? If there is email about it, then I can participate. Nothing we do is so important that it can't wait a few hours or a day, besides the fact, that email is damn near instantaneous these days anyway.
Also, keep in mind that until about a year ago, most everything was done on the mailing list and I think we progressed just fine. Since then, dev@ has almost completely dried up in terms of discussions (factoring out JIRA mails which have picked up -- which is good) and the large majority of discussion takes place on IRC. I agree, however, we should have the IRC discussion on another thread.
>
>
>> 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.
>
> 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.
Yeah, I agree. The hard part for me, is I often feel like people on the outside make big deals about this stuff and don't get that even having the discussion is a very healthy sign. Besides the fact, that no one likes confrontation and uncomfortable topics. We also, I think, are all tired of endless debates that go on and on w/ no resolution. It's one of the big downsides (and, of course, upsides) to consensus based open source as opposed to the dictatorial approach.
>
> 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.
I hopefully would agree we are good stewards of the fact that we employ a good number of committers (but not nearly all the active ones), but I know some disagree. I do, however, think that the recent spat shows that we at Lucid are still free to speak our minds when it comes to open source, as clearly not all Lucid employees agree on the issue and were pretty outspoken about it. I firmly believe we baked this into the company from Day 1 and I consider it one of our best strengths, but of course, most can't see that from the outside. Does that mean we are perfect? Of course not, but I think we try to follow the ASF guidelines and show up as individuals. I also know we work pretty hard to mind the ASF TM policy, etc. (just ask our marketing folks how much I remind them.) I think we all realize that there would be no such thing as Lucid if it weren't for the ASF and for Lucene/Solr, so why would we want to hurt that?
The fact is, every single committer here and a good number of contributors are paid to work on Lucene all day, (most) every day or have some other financial stake (i.e. via a book, consulting biz, etc.) Any of us could be accused of only acting in our own financial interest. At the end of the day, I like to think that instead, the cool thing is we all have a great opportunity to have our financial interests aligned with a great project that we like to work on.
For the record, we have pretty diverse PMC and committer base. As I said in our Dec. 2010 Board Report, we are comprised of:
"[a] total to 17 PMC members from 12 different
companies, spanning the globe. The flagship Lucene/Solr
has 26 total committers from 20 different companies, again
spanning the globe."
The only one that has changed since then is Robert has joined Lucid. Now, one can argue that some of those members from other companies are not active, but that isn't Lucid's fault. ASF development has always been about those who do the work and we do a fair amount of that. Those who are not active, should, ideally, leave on their own by stating they wish to go Emeritus. Beyond that, we have a pretty standard policy that inactive people are removed after 1 year of no activity. That has been the case since I joined Lucene way back when and I think makes sense.
Re: Special Board Report for May 2011
Posted by Jason Rutherglen <ja...@gmail.com>.
> 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'
customers.
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
<lu...@mikemccandless.com> wrote:
> On Wed, May 4, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org> 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 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.
>
> 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
>
Re: Special Board Report for May 2011
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Wed, May 4, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org> 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 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.
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
Re: Special Board Report for May 2011
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Wed, May 4, 2011 at 7:26 PM, Ted Dunning <te...@gmail.com> wrote:
> 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 think with passion comes blowups. I think it's natural, and, as long
as the community heals, healthy. We will emerge stronger from this.
> 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.
We will. This is a resilient community ;)
In fact I find it very inspiring that despite this storm in the
background, committers were still actively pushing things forward.
EG, Simon & others landed the concurrent flushing (DWPT)
branch... resulting in astounding gains in Lucene's indexing
throughput on concurrent hardware
(http://people.apache.org/~mikemccand/lucenebench/indexing.html).
Mike
http://blog.mikemccandless.com
Re: Special Board Report for May 2011
Posted by Ted Dunning <te...@gmail.com>.
+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 <gs...@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