You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@lucene.apache.org by Troy Howard <th...@gmail.com> on 2010/12/30 06:09:23 UTC
Request for cancellation of current vote regarding Lucene.Net status change
Dear Lucene PMC,
This email is to address the current vote by the Lucene PMC regarding
a change of status for the Lucene.Net sub-project and the general
future of that project.
The current process, which is moving towards a change of status for
the Lucene.Net project (either to the incubator or attic), seems to be
contrary to the interests and needs of the community surrounding the
project. Since the issue has come up, there has been a significant
response from the Lucene.Net community expressing their desire for
this not to happen and their willingness to contribute to the project
in order to see it move forward.
Unfortunately, the committers on the project have not responded in a
meaningful way to either the requests from the Lucene PMC or the
interest expressed by the Lucene.Net community. This does not show a
lack of vitality to the community or project, but rather a lack of
interest on the part of the current committers.
Let's have a look at who is on the current committer list:
- George Aroush
- DIGY
- Doug Sale
- Michael Garski
Of that list, the last two, Doug Sale and Michael Garski have been
uninvolved for the majority of 2010 both in terms of making commits to
source control and in terms of communication on the mailing list.
George has been largely uninvolved with the project since 2008.
DIGY has stated clearly and publicly that he is frustrated with being
the only developer on the project and has decided to no longer work on
the project because of this.
When the issue of a status change came up and the community called for
leadership, DIGY and George both took part in the discussion. George,
the defacto project leader, did not respond to community requests for
changes in the project vision, management or codebase, thereby
alienating a large part of the motivated potential contributors in the
community.
George has also been unresponsive, both to the PMC and the community
at large. Those contributors who have attempted to support the effort
to move forward with the project have not been able to engage him
despite their efforts. There was a general assumption that George
would either meet the needs expressed by the Lucene PMC through his
own efforts or coordinate effort by the community contributors to meet
those needs. Neither of those things have happened.
It is clear the George, like the other three committers, is not able
to meet the needs of the project, either due to a lack of interest,
time, or some other unknown factor.
So, of the four possible committers, all four are completely
unavailable and have displayed a lack of activity and lack of interest
in being part of the project.
This situation has led to a complete confusion in the community as to
how to move forward with the project. The would-be contributors either
do not know what to work to do (and thus have not contributed due to
lack of guidance), or have had their patches and contributions ignored
by the committers. Many of those would-be-contributors have simply
moved on and forked the project outside of the ASF due to their
inability to contribute.
This is following the pattern of 'Revolution' as defined in
http://www.apache.org/foundation/glossary.html#Revolution and detailed
by James Duncan Davison. Unfortunately none of the current committers
are involved in this process, and as such, this revolution is occuring
outside of ASF, rather than in ASF's source control. It also means
that these forks will never have the opportunity to be merged back
into the trunk.
There is a strong community around this project. There are numerous
other significant and active open source projects in the .NET space
which depend on Lucene.Net as a library, as well as countless
commercial products that depend on it. There is a strong community
interest in seeing this project move forward and remain vital and
active.
The sensible and correct action for the Lucene PMC is to remove all
four of the current committers from the Lucene.Net project, and
establish a vote for new committers to be assigned to the project from
the users community.
A change of status will not help this project or it's community in any
possible way. New committers, who are interested, motivated, and
responsive are what this project needs.
This is my personal request, but I believe that I speak for a
substantial portion of the Lucene.Net community by asking the Lucene
PMC to please cancel the current vote and address this problem in a
more appropriate and responsible manner.
Please grant the Lucene.Net community the power to be self-determined
by enabling it's active and motivated members to choose a new group of
committers.
On a related subject, it is notable that unlike other Lucene
sub-projects, Lucene.Net does not have representation within the
Lucene PMC, and as such, the PMC's decision making process is
occurring without any PMC member being directly involved with the
community or project. I further propose that once a new group of
committers is established for the Lucene.Net project that one of those
members be made a Lucene PMC member. This will assist the PMC in
better managing the project in the future.
Sincerely,
Troy Howard
Re: Request for cancellation of current vote regarding Lucene.Net
status change
Posted by Ted Dunning <te...@gmail.com>.
The problem with grouping sub-projects under a super-project is that it
leads to more
politics rather than less because many of the decision makers have to base
their decisions
on personal reputation (or whatever) rather than personal knowledge of the
content.
As a member of the PMC for Mahout, I was formerly a member of the PMC for
Lucene
purely based on my Mahout membership. That entitled me to vote on
Lucene issues.
Occasionally it was tempting to do so, but usually only because I knew the
reputation of
the person proposing the change. That probably goes the other way for
Mahout decisions
by Lucene people. That isn't good for projects in the end and having Mahout
separated is
better for both projects.
There is nothing that prevents related projects from associating, from
sharing committers
or even PMC membership (Grant is on the Mahout and Lucene PMC's, btw)
or from linking back and forth on the project web pages. For all intents
and purposes, such
projects can be as closely associated as ever even if they are not under the
same umbrella.
On Thu, Dec 30, 2010 at 10:57 AM, Troy Howard <th...@gmail.com> wrote:
> So it seems to me that you're essentially saying that sub-projects are
> in a nutshell, problematic from a management point of view, and that
> ASF would prefer as many thing to be TLPs as possible, so that there
> aren't hierarchies of management happening.
>
> This is unintuitive from an external point of view, as you would
> expect all variants of Lucene to be grouped together.
>
Re: Request for cancellation of current vote regarding Lucene.Net
status change
Posted by Ted Dunning <te...@gmail.com>.
On Thu, Dec 30, 2010 at 10:57 AM, Troy Howard <th...@gmail.com> wrote:
> Are there any specific resources we should be aware of?
>
Look at previous incubator proposals. There are a bunch around.
> Is there anything special about this process, of moving a project from
> sub-project status to Incubator status, as opposed to a new project
> proposal?
>
It should be just about the same except that moving from sub-project to
Incubator provides a mechanism for preserving the connection with the
sub-project history.
Re: Request for cancellation of current vote regarding Lucene.Net
status change
Posted by Troy Howard <th...@gmail.com>.
Grant,
Thanks for your considered response. Obviously, assuming that the
project continues to move forward, a change of status is not the end
of the world.
I supposed this is something that those of us who are not yet part of
ASF cannot grok due to lack of a deep understanding of how project
management at ASF works.
So it seems to me that you're essentially saying that sub-projects are
in a nutshell, problematic from a management point of view, and that
ASF would prefer as many thing to be TLPs as possible, so that there
aren't hierarchies of management happening.
This is unintuitive from an external point of view, as you would
expect all variants of Lucene to be grouped together.
I supposed we should just trust your judgement, based on your obvious
merit and experience, and follow your recommendation to go back to the
Incubator without further discourse. This conversation doesn't seem to
be doing much for development, as it's taking up time that could be
spent coding.
I'm reading over the guide to proposals here:
http://incubator.apache.org/guides/proposal.html
Can you elaborate and explain the specific steps required (obvious
create a proposal and find a group of willing potential committers is
an essential step)?
Are there any specific resources we should be aware of?
Is there anything special about this process, of moving a project from
sub-project status to Incubator status, as opposed to a new project
proposal?
Would someone from the Lucene PMC be our Sponsor, or would we just
submit the proposal directly to the Incubator PMC without further
involvement with the Lucene TLP/PMC?
Are you offering to be our Champion?
(as detailed in
http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Champion)
Thanks,
Troy
Re: Request for cancellation of current vote regarding Lucene.Net
status change
Posted by Troy Howard <th...@gmail.com>.
Grant,
Thanks for your considered response. Obviously, assuming that the
project continues to move forward, a change of status is not the end
of the world.
I supposed this is something that those of us who are not yet part of
ASF cannot grok due to lack of a deep understanding of how project
management at ASF works.
So it seems to me that you're essentially saying that sub-projects are
in a nutshell, problematic from a management point of view, and that
ASF would prefer as many thing to be TLPs as possible, so that there
aren't hierarchies of management happening.
This is unintuitive from an external point of view, as you would
expect all variants of Lucene to be grouped together.
I supposed we should just trust your judgement, based on your obvious
merit and experience, and follow your recommendation to go back to the
Incubator without further discourse. This conversation doesn't seem to
be doing much for development, as it's taking up time that could be
spent coding.
I'm reading over the guide to proposals here:
http://incubator.apache.org/guides/proposal.html
Can you elaborate and explain the specific steps required (obvious
create a proposal and find a group of willing potential committers is
an essential step)?
Are there any specific resources we should be aware of?
Is there anything special about this process, of moving a project from
sub-project status to Incubator status, as opposed to a new project
proposal?
Would someone from the Lucene PMC be our Sponsor, or would we just
submit the proposal directly to the Incubator PMC without further
involvement with the Lucene TLP/PMC?
Are you offering to be our Champion?
(as detailed in
http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Champion)
Thanks,
Troy
Re: Request for cancellation of current vote regarding Lucene.Net
status change
Posted by Troy Howard <th...@gmail.com>.
Grant,
Thanks for your considered response. Obviously, assuming that the
project continues to move forward, a change of status is not the end
of the world.
I supposed this is something that those of us who are not yet part of
ASF cannot grok due to lack of a deep understanding of how project
management at ASF works.
So it seems to me that you're essentially saying that sub-projects are
in a nutshell, problematic from a management point of view, and that
ASF would prefer as many thing to be TLPs as possible, so that there
aren't hierarchies of management happening.
This is unintuitive from an external point of view, as you would
expect all variants of Lucene to be grouped together.
I supposed we should just trust your judgement, based on your obvious
merit and experience, and follow your recommendation to go back to the
Incubator without further discourse. This conversation doesn't seem to
be doing much for development, as it's taking up time that could be
spent coding.
I'm reading over the guide to proposals here:
http://incubator.apache.org/guides/proposal.html
Can you elaborate and explain the specific steps required (obvious
create a proposal and find a group of willing potential committers is
an essential step)?
Are there any specific resources we should be aware of?
Is there anything special about this process, of moving a project from
sub-project status to Incubator status, as opposed to a new project
proposal?
Would someone from the Lucene PMC be our Sponsor, or would we just
submit the proposal directly to the Incubator PMC without further
involvement with the Lucene TLP/PMC?
Are you offering to be our Champion?
(as detailed in
http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Champion)
Thanks,
Troy
Re: Request for cancellation of current vote regarding Lucene.Net status change
Posted by Grant Ingersoll <gs...@apache.org>.
Hi Troy,
I appreciate the effort and I think what you are asking for in the end is exactly how the Incubator process works. As I've stated several times before, Incubation is a way for the Lucene.NET community to be on the path of a self-determined PMC and to start with a clean slate of committers. As I have suggested multiple times before, I would go do http://incubator.apache.org/guides/proposal.html. The process is quite simple, for example see http://wiki.apache.org/incubator/OpenNLPProposal. Name your list of committers, etc. and then put it up for a vote on general@incubator.apache.org. I'm happy to help set that up for you if you are throwing your name in the hat.
Some more thoughts inline below.
Sincerely,
Grant
On Dec 30, 2010, at 12:09 AM, Troy Howard wrote:
> Dear Lucene PMC,
>
>
<snip/>
>
> This is following the pattern of 'Revolution' as defined in
> http://www.apache.org/foundation/glossary.html#Revolution and detailed
> by James Duncan Davison. Unfortunately none of the current committers
> are involved in this process, and as such, this revolution is occuring
> outside of ASF, rather than in ASF's source control. It also means
> that these forks will never have the opportunity to be merged back
> into the trunk.
>
> There is a strong community around this project.
I would agree there is a decent user community (strong seems, well, a bit strong) but there is almost zero development community AFAICT (and I don't just mean committers.)
> There are numerous
> other significant and active open source projects in the .NET space
> which depend on Lucene.Net as a library, as well as countless
> commercial products that depend on it. There is a strong community
> interest in seeing this project move forward and remain vital and
> active.
>
> The sensible and correct action for the Lucene PMC is to remove all
> four of the current committers from the Lucene.Net project, and
> establish a vote for new committers to be assigned to the project from
> the users community.
Unfortunately, this is a conundrum for the current PMC. As I have stated before, none of us feel capable of judging who those people are and whether they get how the ASF works or what it takes to be a committer.
>
> A change of status will not help this project or it's community in any
> possible way. New committers, who are interested, motivated, and
> responsive are what this project needs.
>
> This is my personal request, but I believe that I speak for a
> substantial portion of the Lucene.Net community by asking the Lucene
> PMC to please cancel the current vote and address this problem in a
> more appropriate and responsible manner.
>
> Please grant the Lucene.Net community the power to be self-determined
> by enabling it's active and motivated members to choose a new group of
> committers.
Who are those people? Please name them and add them to a proposal. I would be happy to help guide you through the Incubator process. There was a bunch of people who volunteered on the original Oct. thread, gather their names, confirm their interest and add them to the proposal.
>
> On a related subject, it is notable that unlike other Lucene
> sub-projects, Lucene.Net does not have representation within the
> Lucene PMC,
George is on the PMC. But yes, this is exactly the problem with Lucene.NET being a sub-project of Lucene and why it belongs as a standalone project. Even if .NET had 2 or 3 or 10, it is clear to me that it is not the right way to run the PMC (trust me, we tried it for a long time with many subprojects such as Nutch, Tika, Mahout, etc.) The ASF Board has made it clear that large umbrella projects are not best practice.
> and as such, the PMC's decision making process is
> occurring without any PMC member being directly involved with the
> community or project. I further propose that once a new group of
> committers is established for the Lucene.Net project that one of those
> members be made a Lucene PMC member. This will assist the PMC in
> better managing the project in the future.
Why only one? Why not have your whole entire PMC be made up of people who care about Lucene.NET and have complete say over the direction of the community, the committers, etc? Being a TLP will do nothing to diminish your relationship with Lucene itself and will likely expand the visibility of the project.
Re: Request for cancellation of current vote regarding Lucene.Net status change
Posted by Grant Ingersoll <gs...@apache.org>.
Hi Troy,
I appreciate the effort and I think what you are asking for in the end is exactly how the Incubator process works. As I've stated several times before, Incubation is a way for the Lucene.NET community to be on the path of a self-determined PMC and to start with a clean slate of committers. As I have suggested multiple times before, I would go do http://incubator.apache.org/guides/proposal.html. The process is quite simple, for example see http://wiki.apache.org/incubator/OpenNLPProposal. Name your list of committers, etc. and then put it up for a vote on general@incubator.apache.org. I'm happy to help set that up for you if you are throwing your name in the hat.
Some more thoughts inline below.
Sincerely,
Grant
On Dec 30, 2010, at 12:09 AM, Troy Howard wrote:
> Dear Lucene PMC,
>
>
<snip/>
>
> This is following the pattern of 'Revolution' as defined in
> http://www.apache.org/foundation/glossary.html#Revolution and detailed
> by James Duncan Davison. Unfortunately none of the current committers
> are involved in this process, and as such, this revolution is occuring
> outside of ASF, rather than in ASF's source control. It also means
> that these forks will never have the opportunity to be merged back
> into the trunk.
>
> There is a strong community around this project.
I would agree there is a decent user community (strong seems, well, a bit strong) but there is almost zero development community AFAICT (and I don't just mean committers.)
> There are numerous
> other significant and active open source projects in the .NET space
> which depend on Lucene.Net as a library, as well as countless
> commercial products that depend on it. There is a strong community
> interest in seeing this project move forward and remain vital and
> active.
>
> The sensible and correct action for the Lucene PMC is to remove all
> four of the current committers from the Lucene.Net project, and
> establish a vote for new committers to be assigned to the project from
> the users community.
Unfortunately, this is a conundrum for the current PMC. As I have stated before, none of us feel capable of judging who those people are and whether they get how the ASF works or what it takes to be a committer.
>
> A change of status will not help this project or it's community in any
> possible way. New committers, who are interested, motivated, and
> responsive are what this project needs.
>
> This is my personal request, but I believe that I speak for a
> substantial portion of the Lucene.Net community by asking the Lucene
> PMC to please cancel the current vote and address this problem in a
> more appropriate and responsible manner.
>
> Please grant the Lucene.Net community the power to be self-determined
> by enabling it's active and motivated members to choose a new group of
> committers.
Who are those people? Please name them and add them to a proposal. I would be happy to help guide you through the Incubator process. There was a bunch of people who volunteered on the original Oct. thread, gather their names, confirm their interest and add them to the proposal.
>
> On a related subject, it is notable that unlike other Lucene
> sub-projects, Lucene.Net does not have representation within the
> Lucene PMC,
George is on the PMC. But yes, this is exactly the problem with Lucene.NET being a sub-project of Lucene and why it belongs as a standalone project. Even if .NET had 2 or 3 or 10, it is clear to me that it is not the right way to run the PMC (trust me, we tried it for a long time with many subprojects such as Nutch, Tika, Mahout, etc.) The ASF Board has made it clear that large umbrella projects are not best practice.
> and as such, the PMC's decision making process is
> occurring without any PMC member being directly involved with the
> community or project. I further propose that once a new group of
> committers is established for the Lucene.Net project that one of those
> members be made a Lucene PMC member. This will assist the PMC in
> better managing the project in the future.
Why only one? Why not have your whole entire PMC be made up of people who care about Lucene.NET and have complete say over the direction of the community, the committers, etc? Being a TLP will do nothing to diminish your relationship with Lucene itself and will likely expand the visibility of the project.
Re: Request for cancellation of current vote regarding Lucene.Net status change
Posted by Grant Ingersoll <gs...@apache.org>.
Hi Troy,
I appreciate the effort and I think what you are asking for in the end is exactly how the Incubator process works. As I've stated several times before, Incubation is a way for the Lucene.NET community to be on the path of a self-determined PMC and to start with a clean slate of committers. As I have suggested multiple times before, I would go do http://incubator.apache.org/guides/proposal.html. The process is quite simple, for example see http://wiki.apache.org/incubator/OpenNLPProposal. Name your list of committers, etc. and then put it up for a vote on general@incubator.apache.org. I'm happy to help set that up for you if you are throwing your name in the hat.
Some more thoughts inline below.
Sincerely,
Grant
On Dec 30, 2010, at 12:09 AM, Troy Howard wrote:
> Dear Lucene PMC,
>
>
<snip/>
>
> This is following the pattern of 'Revolution' as defined in
> http://www.apache.org/foundation/glossary.html#Revolution and detailed
> by James Duncan Davison. Unfortunately none of the current committers
> are involved in this process, and as such, this revolution is occuring
> outside of ASF, rather than in ASF's source control. It also means
> that these forks will never have the opportunity to be merged back
> into the trunk.
>
> There is a strong community around this project.
I would agree there is a decent user community (strong seems, well, a bit strong) but there is almost zero development community AFAICT (and I don't just mean committers.)
> There are numerous
> other significant and active open source projects in the .NET space
> which depend on Lucene.Net as a library, as well as countless
> commercial products that depend on it. There is a strong community
> interest in seeing this project move forward and remain vital and
> active.
>
> The sensible and correct action for the Lucene PMC is to remove all
> four of the current committers from the Lucene.Net project, and
> establish a vote for new committers to be assigned to the project from
> the users community.
Unfortunately, this is a conundrum for the current PMC. As I have stated before, none of us feel capable of judging who those people are and whether they get how the ASF works or what it takes to be a committer.
>
> A change of status will not help this project or it's community in any
> possible way. New committers, who are interested, motivated, and
> responsive are what this project needs.
>
> This is my personal request, but I believe that I speak for a
> substantial portion of the Lucene.Net community by asking the Lucene
> PMC to please cancel the current vote and address this problem in a
> more appropriate and responsible manner.
>
> Please grant the Lucene.Net community the power to be self-determined
> by enabling it's active and motivated members to choose a new group of
> committers.
Who are those people? Please name them and add them to a proposal. I would be happy to help guide you through the Incubator process. There was a bunch of people who volunteered on the original Oct. thread, gather their names, confirm their interest and add them to the proposal.
>
> On a related subject, it is notable that unlike other Lucene
> sub-projects, Lucene.Net does not have representation within the
> Lucene PMC,
George is on the PMC. But yes, this is exactly the problem with Lucene.NET being a sub-project of Lucene and why it belongs as a standalone project. Even if .NET had 2 or 3 or 10, it is clear to me that it is not the right way to run the PMC (trust me, we tried it for a long time with many subprojects such as Nutch, Tika, Mahout, etc.) The ASF Board has made it clear that large umbrella projects are not best practice.
> and as such, the PMC's decision making process is
> occurring without any PMC member being directly involved with the
> community or project. I further propose that once a new group of
> committers is established for the Lucene.Net project that one of those
> members be made a Lucene PMC member. This will assist the PMC in
> better managing the project in the future.
Why only one? Why not have your whole entire PMC be made up of people who care about Lucene.NET and have complete say over the direction of the community, the committers, etc? Being a TLP will do nothing to diminish your relationship with Lucene itself and will likely expand the visibility of the project.