maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <rwhee...@artifact-software.com>
Subject Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)
Date Thu, 25 Jul 2013 14:16:35 GMT
There is clearly an underlying issue that prompts this question.
My understanding is that members of the PMC are selected by other 
members of the PMC.
There is no democratic "will of the people" involved.
I am not sure how people get kicked off the PMC.
What are the official grounds for asking someone to leave?
Is there a minimum level of activity?
An annual re-election of the PMC?

What is the origin of the "Standards for Community Commitment"?
They seem to contain some common sense statements about not trying to 
overwhelm the other committee members but that is a judgment question 
and clearly the PMC can take as long as required to review proposed 
changes and the committer who tries to move faster than the rest of the 
PMC can travel, will eventually have to wait for the rest to catch up.

The question of not allowing forking is a bit harder to justify since it 
is open source and anyone is allowed to try to fork the system.
The question about whether one can continue to contribute to the PMC 
while working on a fork is interesting.
I can see where someone who has a lot of new ideas that they want to try 
might want to work on a major change that could be later refused for 
inclusion in the original project
This could lead to a competitive project coming to light.
How this would be treated by Apache is beyond this discussion.

I suppose that if the new project was deemed to be better than the 
original Maven for some people, there would be some users who would 
shift to the new product.
If everyone felt that way, we would all move and the original Maven 
would be dead.
That is not a bad thing if the Maven PMC made a mistake in the roadmap 
and did not adopt the new project's enhancements when they should have.
It would not be the first development tool to die a slow death as the 
world moved on.

I can see situations arising where a fork that supports a different set 
of "Best Practices" might be the only way to satisfy some users.
We have had some interesting discussions about the "Maven Way" that left 
the odd person unconvinced. Perhaps they might like to use a fork of 
Maven that had a different "Way" and supported a different set of "Best 
Practices"

Would the PMC member who initiated the new project want to stay on the 
Maven PMC?
I would expect that their level of involvement would drop as they 
focused on the new fork and its team.
At what point can they be asked to leave if they don't want to?

As a general piece of free advice, I would tread lightly in the area of 
purity of the roadmap and try to keep a consensus. If someone feels 
strongly that the roadmap is not correct, they should be free to try to 
fork a better way forward. The rest of the committee should continue to 
develop while watching the fork to see if there is a way to combine the 
versions and if not, see how the two paths can be supported in a way 
that makes sense for the user community.
The person doing the fork should either resign if they see no value in 
their participation and see no ongoing value of the Maven development 
products as part of their fork or they should continue to work with the 
committee to keep the level of diversion as low as possible and leverage 
the Maven core in the fork.

Ron

On 25/07/2013 9:16 AM, Stephen Connolly wrote:
> There are two schools of thought amongst the current members of this
> projects PMC.
>
> Without wanting to deliberately tip my hand and reveal where my opinion is,
> we would like to solicit the opinions if the community that we serve.
>
> Please give us your thoughts.
>
> The topic is essentially:
>
> Do you want the members of the Maven PMC to be social leaders of the Maven
> community, who's actions demonstrate the best community behaviour?
>
> The alternative is that members of the Maven PMC are here purely to
> complete the legal requirements that an Apache TLP has delegated to PMCs
>
> This is not black and white... The answer can be grey... And everyone is
> human so can make mistakes...
>
> So community, what are you expecting?
>
> - Stephen Connolly
>
> On Thursday, 25 July 2013, wrote:
>
>> Author: jdcasey
>> Date: Wed Jul 24 23:21:58 2013
>> New Revision: 1506778
>>
>> URL: http://svn.apache.org/r1506778
>> Log:
>> Adding section on PMC standards of community commitment
>>
>> Modified:
>>      maven/site/trunk/content/markdown/project-roles.md
>>
>> Modified: maven/site/trunk/content/markdown/project-roles.md
>> URL:
>> http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1506778&r1=1506777&r2=1506778&view=diff
>>
>> ==============================================================================
>> --- maven/site/trunk/content/markdown/project-roles.md (original)
>> +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24
>> 23:21:58 2013
>> @@ -176,6 +176,29 @@ The Project Management Committee has the
>>   * Voting on release artifacts.
>>   * <!-- TODO: get the rest of these -->
>>
>> +#### Standards for Community Commitment
>> +
>> +In the spirit of supporting the health of our community, Project
>> +Management Committee members refrain from actions that subvert the
>> +functioning of the committee itself.
>> +
>> +First, Project Management Committee members should not maintain
>> long-running
>> +forks of Maven code outside of the project itself. Making significant
>> +changes to Maven code outside of the project displays a lack of
>> +investment in the community. Additionally, attempting to re-integrate
>> +a large number of code changes in bulk overwhelms the ability of
>> +volunteers in the community to review (and potentially veto) the
>> +changes. This effectively thwarts the policing function of the
>> +PMC.
>> +
>> +Second, Project Management Committee members should not divert
>> +work on redesigning, reimplementing, or improving Maven code to
>> +alternative projects outside of this community for the purposes of
>> +reintroducing them as replacement for existing Maven code. While there
>> +is a danger here of falling into a Not Invented Here mentality, new
>> projects
>> +created by Maven PMC members strictly to replace Maven code should not be
>> +allowed.
>> +
>>   ### [Project Management Chair](
>> http://www.apache.org/foundation/how-it-works.html#pmc-chair)
>>
>>   For various legal reasons, there are certain things that the Apache
>>
>>
>>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message