[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)

[Stephen Connolly <st...@gmail.com>]

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
>
>
>

-- 
Sent from my phone

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)

[Ron Wheeler <rw...@artifact-software.com>]

+1

On 25/07/2013 11:16 AM, Jason van Zyl wrote:
> So what's outlined in those paragraphs have counter examples at the ASF. I do not believe it is a bad thing to have alternative distributions or forks, and it doesn't matter where they are. What you are saying is that committers are obliged to share all their work with other committers. Which is more coercion than a matter of choice. For all work that happens within the bounds of the ASF absolutely. Core changes should not be made projects without discussion. That's a good rule and helps with stability. For work that happens outside the bounds of the ASF an author is obliged to do nothing of the sort and the assert as much is absurd quite honestly. What right does the ASF have over work that is not done at Apache?
>
> In fact there are people on the ASF Board who belong to companies that have long standing forks and/or alternative distributions of ASF projects. Look at Hadoop: there are two companies that have people on PMCs who maintain alternative distributions with code that does not exist in standard distributions. Both Cloudera and HortonWorks maintain versions of Hadoop that are not compatible and/or have different code than the version from Apache. There is selective patching and additions made to try and provide a better distribution of Hadoop. I don't think this is a bad thing. This also happens with Cassandra and the people who work at Datastax where an alternative distribution is made. I don't know as much about what is in those distributions insofar as code that doesn't exist in the standard Apache distribution. Again, I don't think this is a bad thing. I'm sure they would all tell you that they are trying to make a better version of said project, they work with customers, work at a different pace and hope to integrate their work back in later if possible.
>
> If this is a sideways attempt to address what I'm doing in Tesla, which is what it appears like to me, then just start a discussion on the dev list. Happy to discuss it.
>
> But if someone posits that all work related to an Apache project has to be done at Apache, then I will say that is a ridiculous supposition and you can find ten counter examples in ten minutes if you went looking.
>
> On Jul 25, 2013, at 10:31 AM, Stephen Connolly <st...@gmail.com> wrote:
>
>> On Thursday, 25 July 2013, Curtis Rueden wrote:
>>
>>> Hi Stephen and everyone,
>>>
>>> I largely agree with Nigel, and would add that in general, bureaucratic
>>> rules prohibiting various (often technically and/or socially sound) actions
>>> such as forking are a great way to ensure that skilled people distance
>>> themselves from the organization (i.e., quit the PMC, decline to join,
>>> etc.). You will be left with only bureaucrats who can tolerate those
>>> restrictions, and worse, create even more of them.
>>>
>>> Of course, there should be good, publicly stated reasons for long-running
>>> forks.
>>
>> I will not speak for the author of the proposed revision, but my
>> understanding of the intent is that these forks should be hosted on ASF
>> hardware in public and as part of our community.
>>
>> It's not about no forking, but allowing the committers to have an ongoing
>> view of things in the community.
>>
>> Any committer is free to edit the wording if they want right now... The doc
>> is a work in progress proposal
>>
>>
>>> Merging to mainline is ideal but not always practical in the real
>>> world. Developers need the freedom to experiment, even (perhaps especially)
>>> when in active community positions such as the PMC.
>>>
>>> That said, it is certainly the responsibility of those on the PMC to act as
>>> community leaders via best practices. But enforcing that in writing, at
>>> least as the current proposal does, seems very counterproductive to me.
>>>
>>> Regards,
>>> Curtis
>>> On Jul 25, 2013 8:59 AM, "Nigel Magnay" <ni...@gmail.com> wrote:
>>>
>>>> That whole section I find pretty bizarre.
>>>>
>>>> - Apache is about (open-source) software.
>>>> - Writing code is *good*.
>>>> - Forks are *good*
>>>> *
>>>> *
>>>> I'm put in mind of Linus' talk about why git distribution is so
>>> important -
>>>> that 'if you don't think I'm doing a good job, then you can just take
>>> your
>>>> code from another maintainer. *That's* what keeps a project honest and
>>>> responsive to the users.
>>>>
>>>> I would have thought that the kinds of people who are interested in
>>> writing
>>>> maven-esque code would be some of the people you'd want on a PMC. If they
>>>> have a "long running fork" or a "reimplementation", surely they would be
>>>> lobbying for its integration? Merging is also good. If, despite this,
>>>> they're choosing to do this elsewhere, and/or are having trouble merging
>>>> projects in, isn't that a pretty sad indictment for the health of the
>>>> project? Isn't it a bit like saying "boo-hoo, those that are doing the
>>>> actual work might go work in their own sandpit if we won't play ball,
>>> let's
>>>> ex-communicate them" ?
>>>>
>>>> Unless (as some have suspected for a while) Apache isn't about software
>>>> anymore, it's about the continued existence of Apache (cfex:
>>> OpenOffice).-
>>>> a political edifice where projects go to die. That's certainly what those
>>>> added paragraphs say to me.
>>>>
>>>>
>>>> On Thu, Jul 25, 2013 at 2:16 PM, Stephen Connolly <
>>>> stephen.alan.connolly@gmail.com> 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
>>>>>> +
>>
>>
>> -- 
>> Sent from my phone
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is,
> the search for a superior moral justification for selfishness.
>
>   -- John Kenneth Galbraith
>
>
>
>
>
>
>


-- 
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

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)

[Ron Wheeler <rw...@artifact-software.com>]

I gather that the process is a simple vote by the existing members.

Perhaps this is one of those things that is best left uncodified and 
allow each person who has to make the decision to chose their own criteria.

Clearly people like to work with people that they find intelligent, 
people whose judgment they trust and people who are fun to work with and 
people who are willing to do the tasks required to keep the project on 
track.

If someone has additional criteria that they want to apply, I suppose 
there is not much that you can do about it.
If they can persuade others that their criteria matters in a particular 
case, I suppose a new candidate could be turned down who the minority 
think should be added.

If this criteria eliminates enough good candidates, the project will 
suffer and another Maven will emerge to take up the space.

As an outsider, I personally would not support the inclusion of the 
criteria and would be hard to persuade that this is grounds for 
rejection of an otherwise acceptable candidate.

Ron



On 25/07/2013 12:03 PM, Stephen Connolly wrote:
> As part of trying to kick this project back to life, we need to grow both
> committers and the PMC.
>
> One of the issues with growing either is determining if potential
> candidates are the "right sort of person".
>
> There is a disagreement in the PMC as to whether "dedication to the Maven
> project community" is relevant to such discussions.
>
> For growing committers, this is usually a small issue, if at all.
>
> For growing the PMC it can be quite contentious, especially when
> considering "controversial" candidates.
>
> In an effort to try and harmonise the PMC, I - as one of the fence sitters
> - started this debate... In essence calling on that group that trumps the
> PMC... ie the community.
>
> John posted the proposed - remember we are CTR not RTC - addition to the
> page I started, at least as a stalking horse (or perhaps it is his
> opinion... I will leave it up to him to state his position)
>
> On Thursday, 25 July 2013, Jason van Zyl wrote:
>
>> So what's outlined in those paragraphs have counter examples at the ASF. I
>> do not believe it is a bad thing to have alternative distributions or
>> forks, and it doesn't matter where they are. What you are saying is that
>> committers are obliged to share all their work with other committers. Which
>> is more coercion than a matter of choice. For all work that happens within
>> the bounds of the ASF absolutely. Core changes should not be made projects
>> without discussion. That's a good rule and helps with stability. For work
>> that happens outside the bounds of the ASF an author is obliged to do
>> nothing of the sort and the assert as much is absurd quite honestly. What
>> right does the ASF have over work that is not done at Apache?
>>
>> In fact there are people on the ASF Board who belong to companies that
>> have long standing forks and/or alternative distributions of ASF projects.
>> Look at Hadoop: there are two companies that have people on PMCs who
>> maintain alternative distributions with code that does not exist in
>> standard distributions. Both Cloudera and HortonWorks maintain versions of
>> Hadoop that are not compatible and/or have different code than the version
>> from Apache. There is selective patching and additions made to try and
>> provide a better distribution of Hadoop. I don't think this is a bad thing.
>> This also happens with Cassandra and the people who work at Datastax where
>> an alternative distribution is made. I don't know as much about what is in
>> those distributions insofar as code that doesn't exist in the standard
>> Apache distribution. Again, I don't think this is a bad thing. I'm sure
>> they would all tell you that they are trying to make a better version of
>> said project, they work with customers, work at a different pace and hope
>> to integrate their work back in later if possible.
>>
>> If this is a sideways attempt to address what I'm doing in Tesla, which is
>> what it appears like to me, then just start a discussion on the dev list.
>> Happy to discuss it.
>
> It would be great if you could have that discussion on the dev list any
> way... But what prompted me to prod John to commit the text and me to start
> this discussion is a long running debate on the PMC private list as to what
> kind of person should be on the PMC... By long running I mean that some
> aspects of this are more than a year old and have been in mails since
> before you started to re-engage with the project.
>
> That does not mean that the stuff you are doing at Tesla is not relevant or
> a trigger for trying to sort out the disconnect between two camps in the
> PMC... More that it is being considered in a common context of an ongoing
> debate, and in an effort to resolve the debate we are asking those we are
> supposed to serve for their input.
>
> HTH
>
>
>> But if someone posits that all work related to an Apache project has to be
>> done at Apache, then I will say that is a ridiculous supposition and you
>> can find ten counter examples in ten minutes if you went looking.
>>
>> On Jul 25, 2013, at 10:31 AM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>>> On Thursday, 25 July 2013, Curtis Rueden wrote:
>>>
>>>> Hi Stephen and everyone,
>>>>
>>>> I largely agree with Nigel, and would add that in general, bureaucratic
>>>> rules prohibiting various (often technically and/or socially sound)
>> actions
>>>> such as forking are a great way to ensure that skilled people distance
>>>> themselves from the organization (i.e., quit the PMC, decline to join,
>>>> etc.). You will be left with only bureaucrats who can tolerate those
>>>> restrictions, and worse, create even more of them.
>>>>
>>>> Of course, there should be good, publicly stated reasons for
>> long-running
>>>> forks.
>>>
>>> I will not speak for the author of the proposed revision, but my
>>> understanding of the intent is that these forks should be hosted on ASF
>>> hardware in public and as part of our community.
>>>
>>> It's not about no forking, but allowing the committers to have an ongoing
>>> view of things in the community.
>>>
>>> Any committer is free to edit the wording if they want right now... The
>> doc
>>> is a work in progress proposal
>>>
>>>
>>>> Merging to mainline is ideal but not always practical in the real
>>>> world. Developers need the freedom to experiment, even (perhaps
>> especially)
>>>> when in active community positions such as the PMC.
>>>>
>>>> That said, it is certainly the responsibility of those on the PMC to
>> act as
>>>> community leaders via best practices. But enforcing that in writing, at
>>>> least as the current proposal does, seems very counterproductive to me.
>>>>
>>>> Regards,
>>>> Curtis
>>>> On Jul 25, 2013 8:59 AM, "Nigel Magnay" <ni...@gmail.com> wrote:
>>>>
>>>>> That whole section I find pretty bizarre.
>>>>>
>>>>> - Apache is about (open-source) software.
>>>>> - Writing code is *good*.
>>>>> - Forks are *good*
>>>>> *
>>>>> *
>>>>> I'm put in mind of Linus' talk about why git distribution is so
>>>> important -
>>>>> that 'if you don't think I'm doing a good job, then you can just take
>>>> your
>>>>> code from another maintainer. *That's* what keeps a project honest and
>>>>> responsive to the users.
>>>>>
>>>>> I would have thought that the kinds of people who are interested in
>>>> writing
>>>>> maven-esque code would be some of the people you'd want on a PMC. If
>> they
>>>>> have a "long running fork" or a "reimplementation", surely they would
>> be
>>>>> lobbying for its integration? Merging is also good. If, despite this,
>>>>> they're choosing to do this elsewhere, and/or are having trouble
>> merging
>>>>> projects in, isn't that a pretty sad indictment for the health of the
>>>>> project? Isn't it a bit like saying "boo-hoo, those that are doing the
>>>>> actual work might go work in their own sandpit if we won't play ball,
>>>> let's
>>>>> ex-communicate them" ?
>>>>>
>>>>> Unless (as some have suspected for a while) Apache isn't about software
>>>>> anymore, it's about the continued existence of Apache (cfex:
>>>> OpenOffice).-
>>>>> a political edifice where projects go to die. That's certainly what
>> those
>>>>> added paragraphs say to me.
>>>>>
>>>>>
>>>>> On Thu, Jul 25, 2013 at 2:16 PM, Stephen Connolly <
>>>>> stephen.alan.connolly@gmail.com> 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 beThanks,
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> The modern conservative is engaged in one of man's oldest exercises in
>> moral philosophy; that is,
>> the search for a superior moral justification for selfishness.
>>
>>   -- John Kenneth Galbraith
>>
>>
>>
>>
>>
>>
>>


-- 
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

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)

[Stephen Connolly <st...@gmail.com>]

On Thursday, 25 July 2013, Ron Wheeler wrote:

> The last thing that you need is a bunch of smart committed people who talk
> about doing stuff the "Apache way" but don't actually write code or
> participate in supporting users.


The key thing is it is not just about writing code.

We need people to help on the mailing lists

We need people to identify bogus/valid bug reports

We need people to document how to use/extend maven

Also somebody else said they think maven needs a strong leader... The ASF
does not want a single "leader" for a project. The closest you might get is
the PMC as a whole. There is no dictator in an Apache project (benevolent
or not)

>From outside you might think the PMC Chair is the "leader"... Wrong, they
are just the (un)lucky victim that gets the legal responsibilities that the
ASF board needs to vest in an officer of the foundation...

The PMC chair is there *to serve* the PMC.

Right now there is a need for strong leadership of this project. While the
project remains at the ASF that means a strong PMC... And right now this is
a PMC somewhat fractured over the core issue I started this thread with...

If you want to help this project, I suggest you engage this debate...
Saying it is the wrong debate actually misses the point and will just
further the festering that has lead some to disengage from this project.

There are other debates we can and should have, but right now this is one
we *need* to have, not because I want to have it, or because I enjoy this
type of debate, but because we have reached a stagnant position and it
needs to change... I don't mind which direction too much mind


> If someone is writing code that works, faster than the rest of the team
> can read it, you are in a great position. Get more code readers!
>
> If someone is generating more ideas for improvement than the team can
> evaluate, then add more marketing/analyst types to the committee.
>
>
> Ron
>
> On 25/07/2013 12:56 PM, Jason van Zyl wrote:
>
> On Jul 25, 2013, at 12:03 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>  As part of trying to kick this project back to life, we need to grow both
> committers and the PMC.
>
>  You don't need either. You need people who do work. People who do work
> may happen to be a committer or PMC member but you have it backward. You
> need a lot of people who do a lot of work to drive a project forward.
>
>  One of the issues with growing either is determining if potential
> candidates are the "right sort of person".
>
>  People who do work. I'm not sure how you decide the "right sort of
> person" if it's not based in the actual contributions to the project. Not
> what might be contributed, but what has actually been contributed.
>
>  There is a disagreement in the PMC as to whether "dedication to the Maven
> project community" is relevant to such discussions.
>
>  Are not people who do work dedicated? Are not people who have done the
> most work the most dedicated? To me doing work is the whole basis of a
> meritocracy, doing work is table stakes for being on the PMC and is first
> condition at least in a meritocracy.
>
>  For growing committers, this is usually a small issue, if at all.
>
> For growing the PMC it can be quite contentious, especially when
> considering "controversial" candidates.
>
>  Discussions should be about the work that is being done on the project.
> Everything outside of that is not within the purview of the discussion. How
> can it be? It's generally looking at the contributions over the last 6
> months or a year and making a decision based on the merit of that work.
>
>  In an effort to try and harmonise the PMC, I - as one of the fence sitters
> - started this debate... In essence calling on that group that trumps the
> PMC... ie the community.
>
> John posted the proposed - remember we are CTR not RTC - addition to the
> page I started, at least as a stalking horse (or perhaps it is his
> opinion... I will leave it up to him to state his position)
>
> On Thursday, 25 July 2013, Jason van Zyl wrote:
>
>  So what's outlined in those paragraphs have counter examples at the ASF. I
> do not believe it is a bad thing to have alternative distributions or
> forks, and it doesn't matter where they are. What you are saying is that
> committers are obliged to share all their work with other committers. Which
> is more coercion than a matter of choice. For all work that happens within
> the bounds of the ASF absolutely. Core changes should not be made projects
> without discussion. That's a good rule and helps with stability. For work
> that happens outside the bounds of the ASF an author is obliged to do
> nothing of the sort and the assert as much is absurd quite honestly. What
> right does the ASF have over work that is not done at Apache?
>
> In fact there are people on the ASF Board who belong to companies that
> have long standing forks and/or alternative distributions of ASF projects.
> Look at Hadoop: there are two companies that have people on PMCs who
> maintain alternative distributions with code that does not exist in
> standard distributions. Both Cloudera and HortonWorks maintain versions of
> Hadoop that are not compatible and/or have different code than the version
> from Apache. There is selective patching and additions made to try and
> provide a better distribution of Hadoop. I don't think this is a bad thing.
> This also happens with Cassandra and the people who work at Datastax where
> an alternative distribution is made. I don't know as much about what is in
> those distributions insofar as code that doesn't exist in the standard
> Apache distribution. Again, I don't think this is a bad thing. I'm sure
> they would all tell you that they are trying to make a better version of
> said project, they work with customers, work at a different pace and hope
> to integrate their work back in later if possible.
>
> If this is a sideways attempt to address what I'm doing in Tesla, which is
> what it appears like to me, then just start a discussion on t
>
> --
> 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
>
>

-- 
Sent from my phone

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)

[Ron Wheeler <rw...@artifact-software.com>]

The last thing that you need is a bunch of smart committed people who 
talk about doing stuff the "Apache way" but don't actually write code or 
participate in supporting users.

If someone is writing code that works, faster than the rest of the team 
can read it, you are in a great position. Get more code readers!

If someone is generating more ideas for improvement than the team can 
evaluate, then add more marketing/analyst types to the committee.


Ron

On 25/07/2013 12:56 PM, Jason van Zyl wrote:
> On Jul 25, 2013, at 12:03 PM, Stephen Connolly <st...@gmail.com> wrote:
>
>> As part of trying to kick this project back to life, we need to grow both
>> committers and the PMC.
>>
> You don't need either. You need people who do work. People who do work may happen to be a committer or PMC member but you have it backward. You need a lot of people who do a lot of work to drive a project forward.
>
>> One of the issues with growing either is determining if potential
>> candidates are the "right sort of person".
>>
> People who do work. I'm not sure how you decide the "right sort of person" if it's not based in the actual contributions to the project. Not what might be contributed, but what has actually been contributed.
>
>> There is a disagreement in the PMC as to whether "dedication to the Maven
>> project community" is relevant to such discussions.
>>
> Are not people who do work dedicated? Are not people who have done the most work the most dedicated? To me doing work is the whole basis of a meritocracy, doing work is table stakes for being on the PMC and is first condition at least in a meritocracy.
>
>> For growing committers, this is usually a small issue, if at all.
>>
>> For growing the PMC it can be quite contentious, especially when
>> considering "controversial" candidates.
>>
> Discussions should be about the work that is being done on the project. Everything outside of that is not within the purview of the discussion. How can it be? It's generally looking at the contributions over the last 6 months or a year and making a decision based on the merit of that work.
>
>> In an effort to try and harmonise the PMC, I - as one of the fence sitters
>> - started this debate... In essence calling on that group that trumps the
>> PMC... ie the community.
>>
>> John posted the proposed - remember we are CTR not RTC - addition to the
>> page I started, at least as a stalking horse (or perhaps it is his
>> opinion... I will leave it up to him to state his position)
>>
>> On Thursday, 25 July 2013, Jason van Zyl wrote:
>>
>>> So what's outlined in those paragraphs have counter examples at the ASF. I
>>> do not believe it is a bad thing to have alternative distributions or
>>> forks, and it doesn't matter where they are. What you are saying is that
>>> committers are obliged to share all their work with other committers. Which
>>> is more coercion than a matter of choice. For all work that happens within
>>> the bounds of the ASF absolutely. Core changes should not be made projects
>>> without discussion. That's a good rule and helps with stability. For work
>>> that happens outside the bounds of the ASF an author is obliged to do
>>> nothing of the sort and the assert as much is absurd quite honestly. What
>>> right does the ASF have over work that is not done at Apache?
>>>
>>> In fact there are people on the ASF Board who belong to companies that
>>> have long standing forks and/or alternative distributions of ASF projects.
>>> Look at Hadoop: there are two companies that have people on PMCs who
>>> maintain alternative distributions with code that does not exist in
>>> standard distributions. Both Cloudera and HortonWorks maintain versions of
>>> Hadoop that are not compatible and/or have different code than the version
>>> from Apache. There is selective patching and additions made to try and
>>> provide a better distribution of Hadoop. I don't think this is a bad thing.
>>> This also happens with Cassandra and the people who work at Datastax where
>>> an alternative distribution is made. I don't know as much about what is in
>>> those distributions insofar as code that doesn't exist in the standard
>>> Apache distribution. Again, I don't think this is a bad thing. I'm sure
>>> they would all tell you that they are trying to make a better version of
>>> said project, they work with customers, work at a different pace and hope
>>> to integrate their work back in later if possible.
>>>
>>> If this is a sideways attempt to address what I'm doing in Tesla, which is
>>> what it appears like to me, then just start a discussion on the dev list.
>>> Happy to discuss it.
>>
>> It would be great if you could have that discussion on the dev list any
>> way... But what prompted me to prod John to commit the text and me to start
>> this discussion is a long running debate on the PMC private list as to what
>> kind of person should be on the PMC... By long running I mean that some
>> aspects of this are more than a year old and have been in mails since
>> before you started to re-engage with the project.
>>
>> That does not mean that the stuff you are doing at Tesla is not relevant or
>> a trigger for trying to sort out the disconnect between two camps in the
>> PMC... More that it is being considered in a common context of an ongoing
>> debate, and in an effort to resolve the debate we are asking those we are
>> supposed to serve for their input.
>>
>> HTH
>>
>>
>>> But if someone posits that all work related to an Apache project has to be
>>> done at Apache, then I will say that is a ridiculous supposition and you
>>> can find ten counter examples in ten minutes if you went looking.
>>>
>>> On Jul 25, 2013, at 10:31 AM, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>>> On Thursday, 25 July 2013, Curtis Rueden wrote:
>>>>
>>>>> Hi Stephen and everyone,
>>>>>
>>>>> I largely agree with Nigel, and would add that in general, bureaucratic
>>>>> rules prohibiting various (often technically and/or socially sound)
>>> actions
>>>>> such as forking are a great way to ensure that skilled people distance
>>>>> themselves from the organization (i.e., quit the PMC, decline to join,
>>>>> etc.). You will be left with only bureaucrats who can tolerate those
>>>>> restrictions, and worse, create even more of them.
>>>>>
>>>>> Of course, there should be good, publicly stated reasons for
>>> long-running
>>>>> forks.
>>>>
>>>> I will not speak for the author of the proposed revision, but my
>>>> understanding of the intent is that these forks should be hosted on ASF
>>>> hardware in public and as part of our community.
>>>>
>>>> It's not about no forking, but allowing the committers to have an ongoing
>>>> view of things in the community.
>>>>
>>>> Any committer is free to edit the wording if they want right now... The
>>> doc
>>>> is a work in progress proposal
>>>>
>>>>
>>>>> Merging to mainline is ideal but not always practical in the real
>>>>> world. Developers need the freedom to experiment, even (perhaps
>>> especially)
>>>>> when in active community positions such as the PMC.
>>>>>
>>>>> That said, it is certainly the responsibility of those on the PMC to
>>> act as
>>>>> community leaders via best practices. But enforcing that in writing, at
>>>>> least as the current proposal does, seems very counterproductive to me.
>>>>>
>>>>> Regards,
>>>>> Curtis
>>>>> On Jul 25, 2013 8:59 AM, "Nigel Magnay" <ni...@gmail.com> wrote:
>>>>>
>>>>>> That whole section I find pretty bizarre.
>>>>>>
>>>>>> - Apache is about (open-source) software.
>>>>>> - Writing code is *good*.
>>>>>> - Forks are *good*
>>>>>> *
>>>>>> *
>>>>>> I'm put in mind of Linus' talk about why git distribution is so
>>>>> important -
>>>>>> that 'if you don't think I'm doing a good job, then you can just take
>>>>> your
>>>>>> code from another maintainer. *That's* what keeps a project honest and
>>>>>> responsive to the users.
>>>>>>
>>>>>> I would have thought that the kinds of people who are interested in
>>>>> writing
>>>>>> maven-esque code would be some of the people you'd want on a PMC. If
>>> they
>>>>>> have a "long running fork" or a "reimplementation", surely they would
>>> be
>>>>>> lobbying for its integration? Merging is also good. If, despite this,
>>>>>> they're choosing to do this elsewhere, and/or are having trouble
>>> merging
>>>>>> projects in, isn't that a pretty sad indictment for the health of the
>>>>>> project? Isn't it a bit like saying "boo-hoo, those that are doing the
>>>>>> actual work might go work in their own sandpit if we won't play ball,
>>>>> let's
>>>>>> ex-communicate them" ?
>>>>>>
>>>>>> Unless (as some have suspected for a while) Apache isn't about software
>>>>>> anymore, it's about the continued existence of Apache (cfex:
>>>>> OpenOffice).-
>>>>>> a political edifice where projects go to die. That's certainly what
>>> those
>>>>>> added paragraphs say to me.
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 25, 2013 at 2:16 PM, Stephen Connolly <
>>>>>> stephen.alan.connolly@gmail.com> 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 beThanks,
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>> The modern conservative is engaged in one of man's oldest exercises in
>>> moral philosophy; that is,
>>> the search for a superior moral justification for selfishness.
>>>
>>> -- John Kenneth Galbraith
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> -- 
>> Sent from my phone
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> Simplex sigillum veri. (Simplicity is the seal of truth.)
>
>
>
>
>
>
>


-- 
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

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)

[Jason van Zyl <ja...@tesla.io>]

All what-ifs. The decisions, as I said, should be made on the typical 6-12 month period of contribution. Everything is encapsulated there: the code done, how it was introduced, how it was delivered and if there were no issues then that can be the basis to make a decision. Everything outside the bounds of that is speculation.

On Jul 25, 2013, at 1:37 PM, Stephen Connolly <st...@gmail.com> wrote:

> The Apache Foundation values Community over Code.
> 
> Merit is thus not just a question about writing "the best code" but helping
> and fostering the community around that code.
> 
> This in deciding committers we need people who are "good enough" *both*
> socially and technically. This can be a mix, eg one very good technical
> person who is poor socially can be counterweighted by a good social person
> who is (comparatively poor technically... But sufficiently socially aware
> of their technical ability)
> 
> If you don't like "community over code", then Apache may not be the place
> for you... And that's ok.
> 
> But as you step up in engagement with an Apache community, you should be at
> least ok with the ASF values.
> 
> How that impacts what it means to be on the PMC is therefore relevant.
> 
> Should it be a strong step and we only take people into the PMC that
> repeatedly demonstrate that they value the community over code (large code
> dumps from long running private forks are not community friendly to a lot
> of people's mind... Repeatedly causing conflict within the community is
> another)? Or should we say the PMC is just to perform the legal duty and
> leave the "religion" to members of the ASF?
> 
> That is what needs to be answered
> 
> On Thursday, 25 July 2013, Sankaran, Nambi wrote:
> 
>> +1
>> 
>> The candidates should be people who contribute in terms of code/patch.
>> 
>> -----Original Message-----
>> From: Jason van Zyl [mailto:jason@tesla.io]
>> Sent: Thursday, July 25, 2013 9:56 AM
>> To: Maven Users List
>> 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)
>> 
>> 
>> On Jul 25, 2013, at 12:03 PM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>> 
>>> As part of trying to kick this project back to life, we need to grow
>>> both committers and the PMC.
>>> 
>> 
>> You don't need either. You need people who do work. People who do work may
>> happen to be a committer or PMC member but you have it backward. You need a
>> lot of people who do a lot of work to drive a project forward.
>> 
>>> One of the issues with growing either is determining if potential
>>> candidates are the "right sort of person".
>>> 
>> 
>> People who do work. I'm not sure how you decide the "right sort of person"
>> if it's not based in the actual contributions to the project. Not what
>> might be contributed, but what has actually been contributed.
>> 
>>> There is a disagreement in the PMC as to whether "dedication to the
>>> Maven project community" is relevant to such discussions.
>>> 
>> 
>> Are not people who do work dedicated? Are not people who have done the
>> most work the most dedicated? To me doing work is the whole basis of a
>> meritocracy, doing work is table stakes for being on the PMC and is first
>> condition at least in a meritocracy.
>> 
>>> For growing committers, this is usually a small issue, if at all.
>>> 
>>> For growing the PMC it can be quite contentious, especially when
>>> considering "controversial" candidates.
>>> 
>> 
>> Discussions should be about the work that is being done on the project.
>> Everything outside of that is not within the purview of the discussion. How
>> can it be? It's generally looking at the contributions over the last 6
>> months or a year and making a decision based on the merit of that work.
>> 
>>> In an effort to try and harmonise the PMC, I - as one of the fence
>>> sitters
>>> - started this debate... In essence calling on that group that trumps
>>> the PMC... ie the community.
>>> 
>>> John posted the proposed - remember we are CTR not RTC - addition to
>>> the page I started, at least as a stalking horse (or perhaps it is his
>>> opinion... I will leave it up to him to state his position)
>>> 
>>> On Thursday, 25 July 2013, Jason van Zyl wrote:
>>> 
>>>> So what's outlined in those paragraphs have counter examples at the
>>>> ASF. I do not believe it is a bad thing to have alternative
>>>> distributions or forks, and it doesn't matter where they are. What
>>>> you are saying is that committers are obliged to share all their work
>>>> with other committers. Which is more coercion than a matter of
>>>> choice. For all work that happens within the bounds of the ASF
>>>> absolutely. Core changes should not be made projects without
>>>> discussion. That's a good rule and helps with stability. For work
>>>> that happens outside the bounds of the ASF an author is obliged to do
>>>> nothing of the sort and the assert as much is absurd quite honestly.
>> What right does the ASF have over work that is not done at Apache?
>>>> 
>>>> In fact there are people on the ASF Board who belong to companies
>>>> that have long standing forks and/or alternative distributions of ASF
>> projects.
>>>> Look at Hadoop: there are two companies that have people on PMCs who
>>>> maintain alternative distributions with code that does not exist in
>>>> standard distributions. Both Cloudera and HortonWorks maintain
>>>> versions of Hadoop that are not compatible and/or have different code
>>>> than the version from Apache. There is selective patching and
>>>> additions made to try and provide a better distribution of Hadoop. I
>> don't think this is a bad thing.
>>>> This also happens with Cassandra and the people who work at Datastax
>>>> where an alternative distribution is made. I don't know as much about
>>>> what is in those distributions insofar as code that doesn't exist in
>>>> the standard Apache distribution. Again, I don't think this is a bad
>>>> thing. I'm sure they would all tell you that they are trying to make
>>>> a better version of said project, they work with customers, work at a
>>>> different pace and hope to
>> in---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org <javascript:;>
>> For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
>> 
>> 
> 
> -- 
> Sent from my phone

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.

  -- Jakob Burckhardt

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)

["Sankaran, Nambi" <ns...@ebay.com>]

This community is created around maven, which is a software (code) written in java.
Lot of people use maven (including me) on a daily basis, because of the value it provides.
We use it because the code works.

Some of the users, eventually become contributors and committers.
Just like many opensource project, maven was initially created by one developer and now it has grown with many committers.
For the project to thrive, we need a strong leader in place who can take guide others, take decisions and move the project forward.
( Jenkins is a good example )

If we have group of people with great attitude, the community will a great place for discussions, but decisions will not be made and progress will not happen.
This is the reason to recruit people who can code.

Btw, it is easier to teach someone who can code to talk. 
But, it is harder to teach someone who can talk to code.

I have no desire in disrespecting anyone's opinions, though I would like maven to thrive and move forward as it did a few years ago.
If that happens by community or by coders is immaterial, however progress is important.


-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com] 
Sent: Thursday, July 25, 2013 10:37 AM
To: Maven Users List
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)

The Apache Foundation values Community over Code.

Merit is thus not just a question about writing "the best code" but helping and fostering the community around that code.

This in deciding committers we need people who are "good enough" *both* socially and technically. This can be a mix, eg one very good technical person who is poor socially can be counterweighted by a good social person who is (comparatively poor technically... But sufficiently socially aware of their technical ability)

If you don't like "community over code", then Apache may not be the place for you... And that's ok.

But as you step up in engagement with an Apache community, you should be at least ok with the ASF values.

How that impacts what it means to be on the PMC is therefore relevant.

Should it be a strong step and we only take people into the PMC that repeatedly demonstrate that they value the community over code (large code dumps from long running private forks are not community friendly to a lot of people's mind... Repeatedly causing conflict within the community is another)? Or should we say the PMC is just to perform the legal duty and leave the "religion" to members of the ASF?

That is what needs to be answered

On Thursday, 25 July 2013, Sankaran, Nambi wrote:

> +1
>
> The candidates should be people who contribute in terms of code/patch.
>
> -----Original Message-----
> From: Jason van Zyl [mailto:jason@tesla.io]
> Sent: Thursday, July 25, 2013 9:56 AM
> To: Maven Users List
> 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)
>
>
> On Jul 25, 2013, at 12:03 PM, Stephen Connolly < 
> stephen.alan.connolly@gmail.com> wrote:
>
> > As part of trying to kick this project back to life, we need to grow 
> > both committers and the PMC.
> >
>
> You don't need either. You need people who do work. People who do work 
> may happen to be a committer or PMC member but you have it backward. 
> You need a lot of people who do a lot of work to drive a project forward.
>
> > One of the issues with growing either is determining if potential 
> > candidates are the "right sort of person".
> >
>
> People who do work. I'm not sure how you decide the "right sort of person"
> if it's not based in the actual contributions to the project. Not what 
> might be contributed, but what has actually been contributed.
>
> > There is a disagreement in the PMC as to whether "dedication to the 
> > Maven project community" is relevant to such discussions.
> >
>
> Are not people who do work dedicated? Are not people who have done the 
> most work the most dedicated? To me doing work is the whole basis of a 
> meritocracy, doing work is table stakes for being on the PMC and is 
> first condition at least in a meritocracy.
>
> > For growing committers, this is usually a small issue, if at all.
> >
> > For growing the PMC it can be quite contentious, especially when 
> > considering "controversial" candidates.
> >
>
> Discussions should be about the work that is being done on the project.
> Everything outside of that is not within the purview of the 
> discussion. How can it be? It's generally looking at the contributions 
> over the last 6 months or a year and making a decision based on the merit of that work.
>
> > In an effort to try and harmonise the PMC, I - as one of the fence 
> > sitters
> > - started this debate... In essence calling on that group that 
> > trumps the PMC... ie the community.
> >
> > John posted the proposed - remember we are CTR not RTC - addition to 
> > the page I started, at least as a stalking horse (or perhaps it is 
> > his opinion... I will leave it up to him to state his position)
> >
> > On Thursday, 25 July 2013, Jason van Zyl wrote:
> >
> >> So what's outlined in those paragraphs have counter examples at the 
> >> ASF. I do not believe it is a bad thing to have alternative 
> >> distributions or forks, and it doesn't matter where they are. What 
> >> you are saying is that committers are obliged to share all their 
> >> work with other committers. Which is more coercion than a matter of 
> >> choice. For all work that happens within the bounds of the ASF 
> >> absolutely. Core changes should not be made projects without 
> >> discussion. That's a good rule and helps with stability. For work 
> >> that happens outside the bounds of the ASF an author is obliged to 
> >> do nothing of the sort and the assert as much is absurd quite honestly.
> What right does the ASF have over work that is not done at Apache?
> >>
> >> In fact there are people on the ASF Board who belong to companies 
> >> that have long standing forks and/or alternative distributions of 
> >> ASF
> projects.
> >> Look at Hadoop: there are two companies that have people on PMCs 
> >> who maintain alternative distributions with code that does not 
> >> exist in standard distributions. Both Cloudera and HortonWorks 
> >> maintain versions of Hadoop that are not compatible and/or have 
> >> different code than the version from Apache. There is selective 
> >> patching and additions made to try and provide a better 
> >> distribution of Hadoop. I
> don't think this is a bad thing.
> >> This also happens with Cassandra and the people who work at 
> >> Datastax where an alternative distribution is made. I don't know as 
> >> much about what is in those distributions insofar as code that 
> >> doesn't exist in the standard Apache distribution. Again, I don't 
> >> think this is a bad thing. I'm sure they would all tell you that 
> >> they are trying to make a better version of said project, they work 
> >> with customers, work at a different pace and hope to
> in--------------------------------------------------------------------
> - To unsubscribe, e-mail: users-unsubscribe@maven.apache.org 
> <javascript:;> For additional commands, e-mail: 
> users-help@maven.apache.org<javascript:;>
>
>

--
Sent from my phone

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

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)

[Stephen Connolly <st...@gmail.com>]

The Apache Foundation values Community over Code.

Merit is thus not just a question about writing "the best code" but helping
and fostering the community around that code.

This in deciding committers we need people who are "good enough" *both*
socially and technically. This can be a mix, eg one very good technical
person who is poor socially can be counterweighted by a good social person
who is (comparatively poor technically... But sufficiently socially aware
of their technical ability)

If you don't like "community over code", then Apache may not be the place
for you... And that's ok.

But as you step up in engagement with an Apache community, you should be at
least ok with the ASF values.

How that impacts what it means to be on the PMC is therefore relevant.

Should it be a strong step and we only take people into the PMC that
repeatedly demonstrate that they value the community over code (large code
dumps from long running private forks are not community friendly to a lot
of people's mind... Repeatedly causing conflict within the community is
another)? Or should we say the PMC is just to perform the legal duty and
leave the "religion" to members of the ASF?

That is what needs to be answered

On Thursday, 25 July 2013, Sankaran, Nambi wrote:

> +1
>
> The candidates should be people who contribute in terms of code/patch.
>
> -----Original Message-----
> From: Jason van Zyl [mailto:jason@tesla.io]
> Sent: Thursday, July 25, 2013 9:56 AM
> To: Maven Users List
> 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)
>
>
> On Jul 25, 2013, at 12:03 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > As part of trying to kick this project back to life, we need to grow
> > both committers and the PMC.
> >
>
> You don't need either. You need people who do work. People who do work may
> happen to be a committer or PMC member but you have it backward. You need a
> lot of people who do a lot of work to drive a project forward.
>
> > One of the issues with growing either is determining if potential
> > candidates are the "right sort of person".
> >
>
> People who do work. I'm not sure how you decide the "right sort of person"
> if it's not based in the actual contributions to the project. Not what
> might be contributed, but what has actually been contributed.
>
> > There is a disagreement in the PMC as to whether "dedication to the
> > Maven project community" is relevant to such discussions.
> >
>
> Are not people who do work dedicated? Are not people who have done the
> most work the most dedicated? To me doing work is the whole basis of a
> meritocracy, doing work is table stakes for being on the PMC and is first
> condition at least in a meritocracy.
>
> > For growing committers, this is usually a small issue, if at all.
> >
> > For growing the PMC it can be quite contentious, especially when
> > considering "controversial" candidates.
> >
>
> Discussions should be about the work that is being done on the project.
> Everything outside of that is not within the purview of the discussion. How
> can it be? It's generally looking at the contributions over the last 6
> months or a year and making a decision based on the merit of that work.
>
> > In an effort to try and harmonise the PMC, I - as one of the fence
> > sitters
> > - started this debate... In essence calling on that group that trumps
> > the PMC... ie the community.
> >
> > John posted the proposed - remember we are CTR not RTC - addition to
> > the page I started, at least as a stalking horse (or perhaps it is his
> > opinion... I will leave it up to him to state his position)
> >
> > On Thursday, 25 July 2013, Jason van Zyl wrote:
> >
> >> So what's outlined in those paragraphs have counter examples at the
> >> ASF. I do not believe it is a bad thing to have alternative
> >> distributions or forks, and it doesn't matter where they are. What
> >> you are saying is that committers are obliged to share all their work
> >> with other committers. Which is more coercion than a matter of
> >> choice. For all work that happens within the bounds of the ASF
> >> absolutely. Core changes should not be made projects without
> >> discussion. That's a good rule and helps with stability. For work
> >> that happens outside the bounds of the ASF an author is obliged to do
> >> nothing of the sort and the assert as much is absurd quite honestly.
> What right does the ASF have over work that is not done at Apache?
> >>
> >> In fact there are people on the ASF Board who belong to companies
> >> that have long standing forks and/or alternative distributions of ASF
> projects.
> >> Look at Hadoop: there are two companies that have people on PMCs who
> >> maintain alternative distributions with code that does not exist in
> >> standard distributions. Both Cloudera and HortonWorks maintain
> >> versions of Hadoop that are not compatible and/or have different code
> >> than the version from Apache. There is selective patching and
> >> additions made to try and provide a better distribution of Hadoop. I
> don't think this is a bad thing.
> >> This also happens with Cassandra and the people who work at Datastax
> >> where an alternative distribution is made. I don't know as much about
> >> what is in those distributions insofar as code that doesn't exist in
> >> the standard Apache distribution. Again, I don't think this is a bad
> >> thing. I'm sure they would all tell you that they are trying to make
> >> a better version of said project, they work with customers, work at a
> >> different pace and hope to
> in---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
>
>

-- 
Sent from my phone

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)

[Barrie Treloar <ba...@gmail.com>]

On 26 July 2013 03:25, Andreas Gudian <an...@gmail.com> wrote:
> I tend to agree with Jason: the PMC needs people who *do* stuff, meaning:
> * bring the project foward (with discussions like this one, or the
> JDK5/JDK6 threads).
> * keep a close eye on commits.
> * keep a very close eye on release votes.
> * continue to assure that we don't do anything that the ASFdoesn't allow,
> while making sure that we don't burden ourselfs with bulky processes to
> achieve that.

Part of this discussion is also to draw the line between PMC and committer.

All but the last point (about ASF) can be done by committers.

A PMC member is no more powerful than a committer (in terms of commit access).
It is however the PMC vote that is binding (See
http://www.apache.org/foundation/voting.html).

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

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)

[Andreas Gudian <an...@gmail.com>]

I also find it quite odd an almost offensive to the open source community
in general to state that a PMC member shall not be allowed to fork too much
around. It's not a marriage, you know ;-).

I tend to agree with Jason: the PMC needs people who *do* stuff, meaning:
* bring the project foward (with discussions like this one, or the
JDK5/JDK6 threads).
* keep a close eye on commits.
* keep a very close eye on release votes.
* continue to assure that we don't do anything that the ASFdoesn't allow,
while making sure that we don't burden ourselfs with bulky processes to
achieve that.

It's a tough responsibility and it requires some dedication to the project.

I explicitly do not think that it's the responsibility of the PMC to make
sure that the maven project will never die out. That I'd find a bit
unnatural and against any best-of-breed principles, which worked out quite
well for open source software (and especially their users) in the past.

Cheers,
Andreas


2013/7/25 Sankaran, Nambi <ns...@ebay.com>

> +1
>
> The candidates should be people who contribute in terms of code/patch.
>
> -----Original Message-----
> From: Jason van Zyl [mailto:jason@tesla.io]
> Sent: Thursday, July 25, 2013 9:56 AM
> To: Maven Users List
> 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)
>
>
> On Jul 25, 2013, at 12:03 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > As part of trying to kick this project back to life, we need to grow
> > both committers and the PMC.
> >
>
> You don't need either. You need people who do work. People who do work may
> happen to be a committer or PMC member but you have it backward. You need a
> lot of people who do a lot of work to drive a project forward.
>
> > One of the issues with growing either is determining if potential
> > candidates are the "right sort of person".
> >
>
> People who do work. I'm not sure how you decide the "right sort of person"
> if it's not based in the actual contributions to the project. Not what
> might be contributed, but what has actually been contributed.
>
> > There is a disagreement in the PMC as to whether "dedication to the
> > Maven project community" is relevant to such discussions.
> >
>
> Are not people who do work dedicated? Are not people who have done the
> most work the most dedicated? To me doing work is the whole basis of a
> meritocracy, doing work is table stakes for being on the PMC and is first
> condition at least in a meritocracy.
>
> > For growing committers, this is usually a small issue, if at all.
> >
> > For growing the PMC it can be quite contentious, especially when
> > considering "controversial" candidates.
> >
>
> Discussions should be about the work that is being done on the project.
> Everything outside of that is not within the purview of the discussion. How
> can it be? It's generally looking at the contributions over the last 6
> months or a year and making a decision based on the merit of that work.
>
> > In an effort to try and harmonise the PMC, I - as one of the fence
> > sitters
> > - started this debate... In essence calling on that group that trumps
> > the PMC... ie the community.
> >
> > John posted the proposed - remember we are CTR not RTC - addition to
> > the page I started, at least as a stalking horse (or perhaps it is his
> > opinion... I will leave it up to him to state his position)
> >
> > On Thursday, 25 July 2013, Jason van Zyl wrote:
> >
> >> So what's outlined in those paragraphs have counter examples at the
> >> ASF. I do not believe it is a bad thing to have alternative
> >> distributions or forks, and it doesn't matter where they are. What
> >> you are saying is that committers are obliged to share all their work
> >> with other committers. Which is more coercion than a matter of
> >> choice. For all work that happens within the bounds of the ASF
> >> absolutely. Core changes should not be made projects without
> >> discussion. That's a good rule and helps with stability. For work
> >> that happens outside the bounds of the ASF an author is obliged to do
> >> nothing of the sort and the assert as much is absurd quite honestly.
> What right does the ASF have over work that is not done at Apache?
> >>
> >> In fact there are people on the ASF Board who belong to companies
> >> that have long standing forks and/or alternative distributions of ASF
> projects.
> >> Look at Hadoop: there are two companies that have people on PMCs who
> >> maintain alternative distributions with code that does not exist in
> >> standard distributions. Both Cloudera and HortonWorks maintain
> >> versions of Hadoop that are not compatible and/or have different code
> >> than the version from Apache. There is selective patching and
> >> additions made to try and provide a better distribution of Hadoop. I
> don't think this is a bad thing.
> >> This also happens with Cassandra and the people who work at Datastax
> >> where an alternative distribution is made. I don't know as much about
> >> what is in those distributions insofar as code that doesn't exist in
> >> the standard Apache distribution. Again, I don't think this is a bad
> >> thing. I'm sure they would all tell you that they are trying to make
> >> a better version of said project, they work with customers, work at a
> >> different pace and hope to integrate their work back in later if
> possible.
> >>
> >> If this is a sideways attempt to address what I'm doing in Tesla,
> >> which is what it appears like to me, then just start a discussion on
> the dev list.
> >> Happy to discuss it.
> >
> >
> > It would be great if you could have that discussion on the dev list
> > any way... But what prompted me to prod John to commit the text and me
> > to start this discussion is a long running debate on the PMC private
> > list as to what kind of person should be on the PMC... By long running
> > I mean that some aspects of this are more than a year old and have
> > been in mails since before you started to re-engage with the project.
> >
> > That does not mean that the stuff you are doing at Tesla is not
> > relevant or a trigger for trying to sort out the disconnect between
> > two camps in the PMC... More that it is being considered in a common
> > context of an ongoing debate, and in an effort to resolve the debate
> > we are asking those we are supposed to serve for their input.
> >
> > HTH
> >
> >
> >>
> >> But if someone posits that all work related to an Apache project has
> >> to be done at Apache, then I will say that is a ridiculous
> >> supposition and you can find ten counter examples in ten minutes if you
> went looking.
> >>
> >> On Jul 25, 2013, at 10:31 AM, Stephen Connolly <
> >> stephen.alan.connolly@gmail.com> wrote:
> >>
> >>> On Thursday, 25 July 2013, Curtis Rueden wrote:
> >>>
> >>>> Hi Stephen and everyone,
> >>>>
> >>>> I largely agree with Nigel, and would add that in general,
> >>>> bureaucratic rules prohibiting various (often technically and/or
> >>>> socially sound)
> >> actions
> >>>> such as forking are a great way to ensure that skilled people
> >>>> distance themselves from the organization (i.e., quit the PMC,
> >>>> decline to join, etc.). You will be left with only bureaucrats who
> >>>> can tolerate those restrictions, and worse, create even more of them.
> >>>>
> >>>> Of course, there should be good, publicly stated reasons for
> >> long-running
> >>>> forks.
> >>>
> >>>
> >>> I will not speak for the author of the proposed revision, but my
> >>> understanding of the intent is that these forks should be hosted on
> >>> ASF hardware in public and as part of our community.
> >>>
> >>> It's not about no forking, but allowing the committers to have an
> >>> ongoing view of things in the community.
> >>>
> >>> Any committer is free to edit the wording if they want right now...
> >>> The
> >> doc
> >>> is a work in progress proposal
> >>>
> >>>
> >>>> Merging to mainline is ideal but not always practical in the real
> >>>> world. Developers need the freedom to experiment, even (perhaps
> >> especially)
> >>>> when in active community positions such as the PMC.
> >>>>
> >>>> That said, it is certainly the responsibility of those on the PMC
> >>>> to
> >> act as
> >>>> community leaders via best practices. But enforcing that in
> >>>> writing, at least as the current proposal does, seems very
> counterproductive to me.
> >>>>
> >>>> Regards,
> >>>> Curtis
> >>>> On Jul 25, 2013 8:59 AM, "Nigel Magnay" <ni...@gmail.com>
> wrote:
> >>>>
> >>>>> That whole section I find pretty bizarre.
> >>>>>
> >>>>> - Apache is about (open-source) software.
> >>>>> - Writing code is *good*.
> >>>>> - Forks are *good*
> >>>>> *
> >>>>> *
> >>>>> I'm put in mind of Linus' talk about why git distribution is so
> >>>> important -
> >>>>> that 'if you don't think I'm doing a good job, then you can just
> >>>>> take
> >>>> your
> >>>>> code from another maintainer. *That's* what keeps a project honest
> >>>>> and responsive to the users.
> >>>>>
> >>>>> I would have thought that the kinds of people who are interested
> >>>>> in
> >>>> writing
> >>>>> maven-esque code would be some of the people you'd want on a PMC.
> >>>>> If
> >> they
> >>>>> have a "long running fork" or a "reimplementation", surely they
> >>>>> would
> >> be
> >>>>> lobbying for its integration? Merging is also good. If, despite
> >>>>> this, they're choosing to do this elsewhere, and/or are having
> >>>>> trouble
> >> merging
> >>>>> projects in, isn't that a pretty sad indictment for the health of
> >>>>> the project? Isn't it a bit like saying "boo-hoo, those that are
> >>>>> doing the actual work might go work in their own sandpit if we
> >>>>> won't play ball,
> >>>> let's
> >>>>> ex-communicate them" ?
> >>>>>
> >>>>> Unless (as some have suspected for a while) Apache isn't about
> >>>>> software anymore, it's about the continued existence of Apache (cfex:
> >>>> OpenOffice).-
> >>>>> a political edifice where projects go to die. That's certainly
> >>>>> what
> >> those
> >>>>> added paragraphs say to me.
> >>>>>
> >>>>>
> >>>>> On Thu, Jul 25, 2013 at 2:16 PM, Stephen Connolly <
> >>>>> stephen.alan.connolly@gmail.com> 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 beThanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> ---------------------------------------------------------
> >>
> >> The modern conservative is engaged in one of man's oldest exercises
> >> in moral philosophy; that is, the search for a superior moral
> >> justification for selfishness.
> >>
> >> -- John Kenneth Galbraith
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> > --
> > Sent from my phone
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> Simplex sigillum veri. (Simplicity is the seal of truth.)
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

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)

["Sankaran, Nambi" <ns...@ebay.com>]

+1

The candidates should be people who contribute in terms of code/patch.

-----Original Message-----
From: Jason van Zyl [mailto:jason@tesla.io] 
Sent: Thursday, July 25, 2013 9:56 AM
To: Maven Users List
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)


On Jul 25, 2013, at 12:03 PM, Stephen Connolly <st...@gmail.com> wrote:

> As part of trying to kick this project back to life, we need to grow 
> both committers and the PMC.
> 

You don't need either. You need people who do work. People who do work may happen to be a committer or PMC member but you have it backward. You need a lot of people who do a lot of work to drive a project forward.

> One of the issues with growing either is determining if potential 
> candidates are the "right sort of person".
> 

People who do work. I'm not sure how you decide the "right sort of person" if it's not based in the actual contributions to the project. Not what might be contributed, but what has actually been contributed.

> There is a disagreement in the PMC as to whether "dedication to the 
> Maven project community" is relevant to such discussions.
> 

Are not people who do work dedicated? Are not people who have done the most work the most dedicated? To me doing work is the whole basis of a meritocracy, doing work is table stakes for being on the PMC and is first condition at least in a meritocracy. 

> For growing committers, this is usually a small issue, if at all.
> 
> For growing the PMC it can be quite contentious, especially when 
> considering "controversial" candidates.
> 

Discussions should be about the work that is being done on the project. Everything outside of that is not within the purview of the discussion. How can it be? It's generally looking at the contributions over the last 6 months or a year and making a decision based on the merit of that work.

> In an effort to try and harmonise the PMC, I - as one of the fence 
> sitters
> - started this debate... In essence calling on that group that trumps 
> the PMC... ie the community.
> 
> John posted the proposed - remember we are CTR not RTC - addition to 
> the page I started, at least as a stalking horse (or perhaps it is his 
> opinion... I will leave it up to him to state his position)
> 
> On Thursday, 25 July 2013, Jason van Zyl wrote:
> 
>> So what's outlined in those paragraphs have counter examples at the 
>> ASF. I do not believe it is a bad thing to have alternative 
>> distributions or forks, and it doesn't matter where they are. What 
>> you are saying is that committers are obliged to share all their work 
>> with other committers. Which is more coercion than a matter of 
>> choice. For all work that happens within the bounds of the ASF 
>> absolutely. Core changes should not be made projects without 
>> discussion. That's a good rule and helps with stability. For work 
>> that happens outside the bounds of the ASF an author is obliged to do 
>> nothing of the sort and the assert as much is absurd quite honestly. What right does the ASF have over work that is not done at Apache?
>> 
>> In fact there are people on the ASF Board who belong to companies 
>> that have long standing forks and/or alternative distributions of ASF projects.
>> Look at Hadoop: there are two companies that have people on PMCs who 
>> maintain alternative distributions with code that does not exist in 
>> standard distributions. Both Cloudera and HortonWorks maintain 
>> versions of Hadoop that are not compatible and/or have different code 
>> than the version from Apache. There is selective patching and 
>> additions made to try and provide a better distribution of Hadoop. I don't think this is a bad thing.
>> This also happens with Cassandra and the people who work at Datastax 
>> where an alternative distribution is made. I don't know as much about 
>> what is in those distributions insofar as code that doesn't exist in 
>> the standard Apache distribution. Again, I don't think this is a bad 
>> thing. I'm sure they would all tell you that they are trying to make 
>> a better version of said project, they work with customers, work at a 
>> different pace and hope to integrate their work back in later if possible.
>> 
>> If this is a sideways attempt to address what I'm doing in Tesla, 
>> which is what it appears like to me, then just start a discussion on the dev list.
>> Happy to discuss it.
> 
> 
> It would be great if you could have that discussion on the dev list 
> any way... But what prompted me to prod John to commit the text and me 
> to start this discussion is a long running debate on the PMC private 
> list as to what kind of person should be on the PMC... By long running 
> I mean that some aspects of this are more than a year old and have 
> been in mails since before you started to re-engage with the project.
> 
> That does not mean that the stuff you are doing at Tesla is not 
> relevant or a trigger for trying to sort out the disconnect between 
> two camps in the PMC... More that it is being considered in a common 
> context of an ongoing debate, and in an effort to resolve the debate 
> we are asking those we are supposed to serve for their input.
> 
> HTH
> 
> 
>> 
>> But if someone posits that all work related to an Apache project has 
>> to be done at Apache, then I will say that is a ridiculous 
>> supposition and you can find ten counter examples in ten minutes if you went looking.
>> 
>> On Jul 25, 2013, at 10:31 AM, Stephen Connolly < 
>> stephen.alan.connolly@gmail.com> wrote:
>> 
>>> On Thursday, 25 July 2013, Curtis Rueden wrote:
>>> 
>>>> Hi Stephen and everyone,
>>>> 
>>>> I largely agree with Nigel, and would add that in general, 
>>>> bureaucratic rules prohibiting various (often technically and/or 
>>>> socially sound)
>> actions
>>>> such as forking are a great way to ensure that skilled people 
>>>> distance themselves from the organization (i.e., quit the PMC, 
>>>> decline to join, etc.). You will be left with only bureaucrats who 
>>>> can tolerate those restrictions, and worse, create even more of them.
>>>> 
>>>> Of course, there should be good, publicly stated reasons for
>> long-running
>>>> forks.
>>> 
>>> 
>>> I will not speak for the author of the proposed revision, but my 
>>> understanding of the intent is that these forks should be hosted on 
>>> ASF hardware in public and as part of our community.
>>> 
>>> It's not about no forking, but allowing the committers to have an 
>>> ongoing view of things in the community.
>>> 
>>> Any committer is free to edit the wording if they want right now... 
>>> The
>> doc
>>> is a work in progress proposal
>>> 
>>> 
>>>> Merging to mainline is ideal but not always practical in the real 
>>>> world. Developers need the freedom to experiment, even (perhaps
>> especially)
>>>> when in active community positions such as the PMC.
>>>> 
>>>> That said, it is certainly the responsibility of those on the PMC 
>>>> to
>> act as
>>>> community leaders via best practices. But enforcing that in 
>>>> writing, at least as the current proposal does, seems very counterproductive to me.
>>>> 
>>>> Regards,
>>>> Curtis
>>>> On Jul 25, 2013 8:59 AM, "Nigel Magnay" <ni...@gmail.com> wrote:
>>>> 
>>>>> That whole section I find pretty bizarre.
>>>>> 
>>>>> - Apache is about (open-source) software.
>>>>> - Writing code is *good*.
>>>>> - Forks are *good*
>>>>> *
>>>>> *
>>>>> I'm put in mind of Linus' talk about why git distribution is so
>>>> important -
>>>>> that 'if you don't think I'm doing a good job, then you can just 
>>>>> take
>>>> your
>>>>> code from another maintainer. *That's* what keeps a project honest 
>>>>> and responsive to the users.
>>>>> 
>>>>> I would have thought that the kinds of people who are interested 
>>>>> in
>>>> writing
>>>>> maven-esque code would be some of the people you'd want on a PMC. 
>>>>> If
>> they
>>>>> have a "long running fork" or a "reimplementation", surely they 
>>>>> would
>> be
>>>>> lobbying for its integration? Merging is also good. If, despite 
>>>>> this, they're choosing to do this elsewhere, and/or are having 
>>>>> trouble
>> merging
>>>>> projects in, isn't that a pretty sad indictment for the health of 
>>>>> the project? Isn't it a bit like saying "boo-hoo, those that are 
>>>>> doing the actual work might go work in their own sandpit if we 
>>>>> won't play ball,
>>>> let's
>>>>> ex-communicate them" ?
>>>>> 
>>>>> Unless (as some have suspected for a while) Apache isn't about 
>>>>> software anymore, it's about the continued existence of Apache (cfex:
>>>> OpenOffice).-
>>>>> a political edifice where projects go to die. That's certainly 
>>>>> what
>> those
>>>>> added paragraphs say to me.
>>>>> 
>>>>> 
>>>>> On Thu, Jul 25, 2013 at 2:16 PM, Stephen Connolly < 
>>>>> stephen.alan.connolly@gmail.com> 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 beThanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> The modern conservative is engaged in one of man's oldest exercises 
>> in moral philosophy; that is, the search for a superior moral 
>> justification for selfishness.
>> 
>> -- John Kenneth Galbraith
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> --
> Sent from my phone

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

Simplex sigillum veri. (Simplicity is the seal of truth.)







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

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)

[Jason van Zyl <ja...@tesla.io>]

On Jul 25, 2013, at 12:03 PM, Stephen Connolly <st...@gmail.com> wrote:

> As part of trying to kick this project back to life, we need to grow both
> committers and the PMC.
> 

You don't need either. You need people who do work. People who do work may happen to be a committer or PMC member but you have it backward. You need a lot of people who do a lot of work to drive a project forward.

> One of the issues with growing either is determining if potential
> candidates are the "right sort of person".
> 

People who do work. I'm not sure how you decide the "right sort of person" if it's not based in the actual contributions to the project. Not what might be contributed, but what has actually been contributed.

> There is a disagreement in the PMC as to whether "dedication to the Maven
> project community" is relevant to such discussions.
> 

Are not people who do work dedicated? Are not people who have done the most work the most dedicated? To me doing work is the whole basis of a meritocracy, doing work is table stakes for being on the PMC and is first condition at least in a meritocracy. 

> For growing committers, this is usually a small issue, if at all.
> 
> For growing the PMC it can be quite contentious, especially when
> considering "controversial" candidates.
> 

Discussions should be about the work that is being done on the project. Everything outside of that is not within the purview of the discussion. How can it be? It's generally looking at the contributions over the last 6 months or a year and making a decision based on the merit of that work.

> In an effort to try and harmonise the PMC, I - as one of the fence sitters
> - started this debate... In essence calling on that group that trumps the
> PMC... ie the community.
> 
> John posted the proposed - remember we are CTR not RTC - addition to the
> page I started, at least as a stalking horse (or perhaps it is his
> opinion... I will leave it up to him to state his position)
> 
> On Thursday, 25 July 2013, Jason van Zyl wrote:
> 
>> So what's outlined in those paragraphs have counter examples at the ASF. I
>> do not believe it is a bad thing to have alternative distributions or
>> forks, and it doesn't matter where they are. What you are saying is that
>> committers are obliged to share all their work with other committers. Which
>> is more coercion than a matter of choice. For all work that happens within
>> the bounds of the ASF absolutely. Core changes should not be made projects
>> without discussion. That's a good rule and helps with stability. For work
>> that happens outside the bounds of the ASF an author is obliged to do
>> nothing of the sort and the assert as much is absurd quite honestly. What
>> right does the ASF have over work that is not done at Apache?
>> 
>> In fact there are people on the ASF Board who belong to companies that
>> have long standing forks and/or alternative distributions of ASF projects.
>> Look at Hadoop: there are two companies that have people on PMCs who
>> maintain alternative distributions with code that does not exist in
>> standard distributions. Both Cloudera and HortonWorks maintain versions of
>> Hadoop that are not compatible and/or have different code than the version
>> from Apache. There is selective patching and additions made to try and
>> provide a better distribution of Hadoop. I don't think this is a bad thing.
>> This also happens with Cassandra and the people who work at Datastax where
>> an alternative distribution is made. I don't know as much about what is in
>> those distributions insofar as code that doesn't exist in the standard
>> Apache distribution. Again, I don't think this is a bad thing. I'm sure
>> they would all tell you that they are trying to make a better version of
>> said project, they work with customers, work at a different pace and hope
>> to integrate their work back in later if possible.
>> 
>> If this is a sideways attempt to address what I'm doing in Tesla, which is
>> what it appears like to me, then just start a discussion on the dev list.
>> Happy to discuss it.
> 
> 
> It would be great if you could have that discussion on the dev list any
> way... But what prompted me to prod John to commit the text and me to start
> this discussion is a long running debate on the PMC private list as to what
> kind of person should be on the PMC... By long running I mean that some
> aspects of this are more than a year old and have been in mails since
> before you started to re-engage with the project.
> 
> That does not mean that the stuff you are doing at Tesla is not relevant or
> a trigger for trying to sort out the disconnect between two camps in the
> PMC... More that it is being considered in a common context of an ongoing
> debate, and in an effort to resolve the debate we are asking those we are
> supposed to serve for their input.
> 
> HTH
> 
> 
>> 
>> But if someone posits that all work related to an Apache project has to be
>> done at Apache, then I will say that is a ridiculous supposition and you
>> can find ten counter examples in ten minutes if you went looking.
>> 
>> On Jul 25, 2013, at 10:31 AM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>> 
>>> On Thursday, 25 July 2013, Curtis Rueden wrote:
>>> 
>>>> Hi Stephen and everyone,
>>>> 
>>>> I largely agree with Nigel, and would add that in general, bureaucratic
>>>> rules prohibiting various (often technically and/or socially sound)
>> actions
>>>> such as forking are a great way to ensure that skilled people distance
>>>> themselves from the organization (i.e., quit the PMC, decline to join,
>>>> etc.). You will be left with only bureaucrats who can tolerate those
>>>> restrictions, and worse, create even more of them.
>>>> 
>>>> Of course, there should be good, publicly stated reasons for
>> long-running
>>>> forks.
>>> 
>>> 
>>> I will not speak for the author of the proposed revision, but my
>>> understanding of the intent is that these forks should be hosted on ASF
>>> hardware in public and as part of our community.
>>> 
>>> It's not about no forking, but allowing the committers to have an ongoing
>>> view of things in the community.
>>> 
>>> Any committer is free to edit the wording if they want right now... The
>> doc
>>> is a work in progress proposal
>>> 
>>> 
>>>> Merging to mainline is ideal but not always practical in the real
>>>> world. Developers need the freedom to experiment, even (perhaps
>> especially)
>>>> when in active community positions such as the PMC.
>>>> 
>>>> That said, it is certainly the responsibility of those on the PMC to
>> act as
>>>> community leaders via best practices. But enforcing that in writing, at
>>>> least as the current proposal does, seems very counterproductive to me.
>>>> 
>>>> Regards,
>>>> Curtis
>>>> On Jul 25, 2013 8:59 AM, "Nigel Magnay" <ni...@gmail.com> wrote:
>>>> 
>>>>> That whole section I find pretty bizarre.
>>>>> 
>>>>> - Apache is about (open-source) software.
>>>>> - Writing code is *good*.
>>>>> - Forks are *good*
>>>>> *
>>>>> *
>>>>> I'm put in mind of Linus' talk about why git distribution is so
>>>> important -
>>>>> that 'if you don't think I'm doing a good job, then you can just take
>>>> your
>>>>> code from another maintainer. *That's* what keeps a project honest and
>>>>> responsive to the users.
>>>>> 
>>>>> I would have thought that the kinds of people who are interested in
>>>> writing
>>>>> maven-esque code would be some of the people you'd want on a PMC. If
>> they
>>>>> have a "long running fork" or a "reimplementation", surely they would
>> be
>>>>> lobbying for its integration? Merging is also good. If, despite this,
>>>>> they're choosing to do this elsewhere, and/or are having trouble
>> merging
>>>>> projects in, isn't that a pretty sad indictment for the health of the
>>>>> project? Isn't it a bit like saying "boo-hoo, those that are doing the
>>>>> actual work might go work in their own sandpit if we won't play ball,
>>>> let's
>>>>> ex-communicate them" ?
>>>>> 
>>>>> Unless (as some have suspected for a while) Apache isn't about software
>>>>> anymore, it's about the continued existence of Apache (cfex:
>>>> OpenOffice).-
>>>>> a political edifice where projects go to die. That's certainly what
>> those
>>>>> added paragraphs say to me.
>>>>> 
>>>>> 
>>>>> On Thu, Jul 25, 2013 at 2:16 PM, Stephen Connolly <
>>>>> stephen.alan.connolly@gmail.com> 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 beThanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> The modern conservative is engaged in one of man's oldest exercises in
>> moral philosophy; that is,
>> the search for a superior moral justification for selfishness.
>> 
>> -- John Kenneth Galbraith
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> -- 
> Sent from my phone

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

Simplex sigillum veri. (Simplicity is the seal of truth.)

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)

[Stephen Connolly <st...@gmail.com>]

As part of trying to kick this project back to life, we need to grow both
committers and the PMC.

One of the issues with growing either is determining if potential
candidates are the "right sort of person".

There is a disagreement in the PMC as to whether "dedication to the Maven
project community" is relevant to such discussions.

For growing committers, this is usually a small issue, if at all.

For growing the PMC it can be quite contentious, especially when
considering "controversial" candidates.

In an effort to try and harmonise the PMC, I - as one of the fence sitters
- started this debate... In essence calling on that group that trumps the
PMC... ie the community.

John posted the proposed - remember we are CTR not RTC - addition to the
page I started, at least as a stalking horse (or perhaps it is his
opinion... I will leave it up to him to state his position)

On Thursday, 25 July 2013, Jason van Zyl wrote:

> So what's outlined in those paragraphs have counter examples at the ASF. I
> do not believe it is a bad thing to have alternative distributions or
> forks, and it doesn't matter where they are. What you are saying is that
> committers are obliged to share all their work with other committers. Which
> is more coercion than a matter of choice. For all work that happens within
> the bounds of the ASF absolutely. Core changes should not be made projects
> without discussion. That's a good rule and helps with stability. For work
> that happens outside the bounds of the ASF an author is obliged to do
> nothing of the sort and the assert as much is absurd quite honestly. What
> right does the ASF have over work that is not done at Apache?
>
> In fact there are people on the ASF Board who belong to companies that
> have long standing forks and/or alternative distributions of ASF projects.
> Look at Hadoop: there are two companies that have people on PMCs who
> maintain alternative distributions with code that does not exist in
> standard distributions. Both Cloudera and HortonWorks maintain versions of
> Hadoop that are not compatible and/or have different code than the version
> from Apache. There is selective patching and additions made to try and
> provide a better distribution of Hadoop. I don't think this is a bad thing.
> This also happens with Cassandra and the people who work at Datastax where
> an alternative distribution is made. I don't know as much about what is in
> those distributions insofar as code that doesn't exist in the standard
> Apache distribution. Again, I don't think this is a bad thing. I'm sure
> they would all tell you that they are trying to make a better version of
> said project, they work with customers, work at a different pace and hope
> to integrate their work back in later if possible.
>
> If this is a sideways attempt to address what I'm doing in Tesla, which is
> what it appears like to me, then just start a discussion on the dev list.
> Happy to discuss it.


It would be great if you could have that discussion on the dev list any
way... But what prompted me to prod John to commit the text and me to start
this discussion is a long running debate on the PMC private list as to what
kind of person should be on the PMC... By long running I mean that some
aspects of this are more than a year old and have been in mails since
before you started to re-engage with the project.

That does not mean that the stuff you are doing at Tesla is not relevant or
a trigger for trying to sort out the disconnect between two camps in the
PMC... More that it is being considered in a common context of an ongoing
debate, and in an effort to resolve the debate we are asking those we are
supposed to serve for their input.

HTH


>
> But if someone posits that all work related to an Apache project has to be
> done at Apache, then I will say that is a ridiculous supposition and you
> can find ten counter examples in ten minutes if you went looking.
>
> On Jul 25, 2013, at 10:31 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > On Thursday, 25 July 2013, Curtis Rueden wrote:
> >
> >> Hi Stephen and everyone,
> >>
> >> I largely agree with Nigel, and would add that in general, bureaucratic
> >> rules prohibiting various (often technically and/or socially sound)
> actions
> >> such as forking are a great way to ensure that skilled people distance
> >> themselves from the organization (i.e., quit the PMC, decline to join,
> >> etc.). You will be left with only bureaucrats who can tolerate those
> >> restrictions, and worse, create even more of them.
> >>
> >> Of course, there should be good, publicly stated reasons for
> long-running
> >> forks.
> >
> >
> > I will not speak for the author of the proposed revision, but my
> > understanding of the intent is that these forks should be hosted on ASF
> > hardware in public and as part of our community.
> >
> > It's not about no forking, but allowing the committers to have an ongoing
> > view of things in the community.
> >
> > Any committer is free to edit the wording if they want right now... The
> doc
> > is a work in progress proposal
> >
> >
> >> Merging to mainline is ideal but not always practical in the real
> >> world. Developers need the freedom to experiment, even (perhaps
> especially)
> >> when in active community positions such as the PMC.
> >>
> >> That said, it is certainly the responsibility of those on the PMC to
> act as
> >> community leaders via best practices. But enforcing that in writing, at
> >> least as the current proposal does, seems very counterproductive to me.
> >>
> >> Regards,
> >> Curtis
> >> On Jul 25, 2013 8:59 AM, "Nigel Magnay" <ni...@gmail.com> wrote:
> >>
> >>> That whole section I find pretty bizarre.
> >>>
> >>> - Apache is about (open-source) software.
> >>> - Writing code is *good*.
> >>> - Forks are *good*
> >>> *
> >>> *
> >>> I'm put in mind of Linus' talk about why git distribution is so
> >> important -
> >>> that 'if you don't think I'm doing a good job, then you can just take
> >> your
> >>> code from another maintainer. *That's* what keeps a project honest and
> >>> responsive to the users.
> >>>
> >>> I would have thought that the kinds of people who are interested in
> >> writing
> >>> maven-esque code would be some of the people you'd want on a PMC. If
> they
> >>> have a "long running fork" or a "reimplementation", surely they would
> be
> >>> lobbying for its integration? Merging is also good. If, despite this,
> >>> they're choosing to do this elsewhere, and/or are having trouble
> merging
> >>> projects in, isn't that a pretty sad indictment for the health of the
> >>> project? Isn't it a bit like saying "boo-hoo, those that are doing the
> >>> actual work might go work in their own sandpit if we won't play ball,
> >> let's
> >>> ex-communicate them" ?
> >>>
> >>> Unless (as some have suspected for a while) Apache isn't about software
> >>> anymore, it's about the continued existence of Apache (cfex:
> >> OpenOffice).-
> >>> a political edifice where projects go to die. That's certainly what
> those
> >>> added paragraphs say to me.
> >>>
> >>>
> >>> On Thu, Jul 25, 2013 at 2:16 PM, Stephen Connolly <
> >>> stephen.alan.connolly@gmail.com> 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 beThanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> The modern conservative is engaged in one of man's oldest exercises in
> moral philosophy; that is,
> the search for a superior moral justification for selfishness.
>
>  -- John Kenneth Galbraith
>
>
>
>
>
>
>

-- 
Sent from my phone

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)

[Jason van Zyl <ja...@tesla.io>]

So what's outlined in those paragraphs have counter examples at the ASF. I do not believe it is a bad thing to have alternative distributions or forks, and it doesn't matter where they are. What you are saying is that committers are obliged to share all their work with other committers. Which is more coercion than a matter of choice. For all work that happens within the bounds of the ASF absolutely. Core changes should not be made projects without discussion. That's a good rule and helps with stability. For work that happens outside the bounds of the ASF an author is obliged to do nothing of the sort and the assert as much is absurd quite honestly. What right does the ASF have over work that is not done at Apache?

In fact there are people on the ASF Board who belong to companies that have long standing forks and/or alternative distributions of ASF projects. Look at Hadoop: there are two companies that have people on PMCs who maintain alternative distributions with code that does not exist in standard distributions. Both Cloudera and HortonWorks maintain versions of Hadoop that are not compatible and/or have different code than the version from Apache. There is selective patching and additions made to try and provide a better distribution of Hadoop. I don't think this is a bad thing. This also happens with Cassandra and the people who work at Datastax where an alternative distribution is made. I don't know as much about what is in those distributions insofar as code that doesn't exist in the standard Apache distribution. Again, I don't think this is a bad thing. I'm sure they would all tell you that they are trying to make a better version of said project, they work with customers, work at a different pace and hope to integrate their work back in later if possible.

If this is a sideways attempt to address what I'm doing in Tesla, which is what it appears like to me, then just start a discussion on the dev list. Happy to discuss it.

But if someone posits that all work related to an Apache project has to be done at Apache, then I will say that is a ridiculous supposition and you can find ten counter examples in ten minutes if you went looking.

On Jul 25, 2013, at 10:31 AM, Stephen Connolly <st...@gmail.com> wrote:

> On Thursday, 25 July 2013, Curtis Rueden wrote:
> 
>> Hi Stephen and everyone,
>> 
>> I largely agree with Nigel, and would add that in general, bureaucratic
>> rules prohibiting various (often technically and/or socially sound) actions
>> such as forking are a great way to ensure that skilled people distance
>> themselves from the organization (i.e., quit the PMC, decline to join,
>> etc.). You will be left with only bureaucrats who can tolerate those
>> restrictions, and worse, create even more of them.
>> 
>> Of course, there should be good, publicly stated reasons for long-running
>> forks.
> 
> 
> I will not speak for the author of the proposed revision, but my
> understanding of the intent is that these forks should be hosted on ASF
> hardware in public and as part of our community.
> 
> It's not about no forking, but allowing the committers to have an ongoing
> view of things in the community.
> 
> Any committer is free to edit the wording if they want right now... The doc
> is a work in progress proposal
> 
> 
>> Merging to mainline is ideal but not always practical in the real
>> world. Developers need the freedom to experiment, even (perhaps especially)
>> when in active community positions such as the PMC.
>> 
>> That said, it is certainly the responsibility of those on the PMC to act as
>> community leaders via best practices. But enforcing that in writing, at
>> least as the current proposal does, seems very counterproductive to me.
>> 
>> Regards,
>> Curtis
>> On Jul 25, 2013 8:59 AM, "Nigel Magnay" <ni...@gmail.com> wrote:
>> 
>>> That whole section I find pretty bizarre.
>>> 
>>> - Apache is about (open-source) software.
>>> - Writing code is *good*.
>>> - Forks are *good*
>>> *
>>> *
>>> I'm put in mind of Linus' talk about why git distribution is so
>> important -
>>> that 'if you don't think I'm doing a good job, then you can just take
>> your
>>> code from another maintainer. *That's* what keeps a project honest and
>>> responsive to the users.
>>> 
>>> I would have thought that the kinds of people who are interested in
>> writing
>>> maven-esque code would be some of the people you'd want on a PMC. If they
>>> have a "long running fork" or a "reimplementation", surely they would be
>>> lobbying for its integration? Merging is also good. If, despite this,
>>> they're choosing to do this elsewhere, and/or are having trouble merging
>>> projects in, isn't that a pretty sad indictment for the health of the
>>> project? Isn't it a bit like saying "boo-hoo, those that are doing the
>>> actual work might go work in their own sandpit if we won't play ball,
>> let's
>>> ex-communicate them" ?
>>> 
>>> Unless (as some have suspected for a while) Apache isn't about software
>>> anymore, it's about the continued existence of Apache (cfex:
>> OpenOffice).-
>>> a political edifice where projects go to die. That's certainly what those
>>> added paragraphs say to me.
>>> 
>>> 
>>> On Thu, Jul 25, 2013 at 2:16 PM, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> 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
>>>>> +
>>> 
> 
> 
> 
> -- 
> Sent from my phone

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, 
the search for a superior moral justification for selfishness.

 -- John Kenneth Galbraith

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)

[Stephen Connolly <st...@gmail.com>]

On Thursday, 25 July 2013, Curtis Rueden wrote:

> Hi Stephen and everyone,
>
> I largely agree with Nigel, and would add that in general, bureaucratic
> rules prohibiting various (often technically and/or socially sound) actions
> such as forking are a great way to ensure that skilled people distance
> themselves from the organization (i.e., quit the PMC, decline to join,
> etc.). You will be left with only bureaucrats who can tolerate those
> restrictions, and worse, create even more of them.
>
> Of course, there should be good, publicly stated reasons for long-running
> forks.


I will not speak for the author of the proposed revision, but my
understanding of the intent is that these forks should be hosted on ASF
hardware in public and as part of our community.

It's not about no forking, but allowing the committers to have an ongoing
view of things in the community.

Any committer is free to edit the wording if they want right now... The doc
is a work in progress proposal


> Merging to mainline is ideal but not always practical in the real
> world. Developers need the freedom to experiment, even (perhaps especially)
> when in active community positions such as the PMC.
>
> That said, it is certainly the responsibility of those on the PMC to act as
> community leaders via best practices. But enforcing that in writing, at
> least as the current proposal does, seems very counterproductive to me.
>
> Regards,
> Curtis
> On Jul 25, 2013 8:59 AM, "Nigel Magnay" <ni...@gmail.com> wrote:
>
> > That whole section I find pretty bizarre.
> >
> > - Apache is about (open-source) software.
> > - Writing code is *good*.
> > - Forks are *good*
> > *
> > *
> > I'm put in mind of Linus' talk about why git distribution is so
> important -
> > that 'if you don't think I'm doing a good job, then you can just take
> your
> > code from another maintainer. *That's* what keeps a project honest and
> > responsive to the users.
> >
> > I would have thought that the kinds of people who are interested in
> writing
> > maven-esque code would be some of the people you'd want on a PMC. If they
> > have a "long running fork" or a "reimplementation", surely they would be
> > lobbying for its integration? Merging is also good. If, despite this,
> > they're choosing to do this elsewhere, and/or are having trouble merging
> > projects in, isn't that a pretty sad indictment for the health of the
> > project? Isn't it a bit like saying "boo-hoo, those that are doing the
> > actual work might go work in their own sandpit if we won't play ball,
> let's
> > ex-communicate them" ?
> >
> > Unless (as some have suspected for a while) Apache isn't about software
> > anymore, it's about the continued existence of Apache (cfex:
> OpenOffice).-
> > a political edifice where projects go to die. That's certainly what those
> > added paragraphs say to me.
> >
> >
> > On Thu, Jul 25, 2013 at 2:16 PM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> 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
> > > > +
> >



-- 
Sent from my phone

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)

[Curtis Rueden <ct...@wisc.edu>]

Hi Stephen and everyone,

I largely agree with Nigel, and would add that in general, bureaucratic
rules prohibiting various (often technically and/or socially sound) actions
such as forking are a great way to ensure that skilled people distance
themselves from the organization (i.e., quit the PMC, decline to join,
etc.). You will be left with only bureaucrats who can tolerate those
restrictions, and worse, create even more of them.

Of course, there should be good, publicly stated reasons for long-running
forks. Merging to mainline is ideal but not always practical in the real
world. Developers need the freedom to experiment, even (perhaps especially)
when in active community positions such as the PMC.

That said, it is certainly the responsibility of those on the PMC to act as
community leaders via best practices. But enforcing that in writing, at
least as the current proposal does, seems very counterproductive to me.

Regards,
Curtis
On Jul 25, 2013 8:59 AM, "Nigel Magnay" <ni...@gmail.com> wrote:

> That whole section I find pretty bizarre.
>
> - Apache is about (open-source) software.
> - Writing code is *good*.
> - Forks are *good*
> *
> *
> I'm put in mind of Linus' talk about why git distribution is so important -
> that 'if you don't think I'm doing a good job, then you can just take your
> code from another maintainer. *That's* what keeps a project honest and
> responsive to the users.
>
> I would have thought that the kinds of people who are interested in writing
> maven-esque code would be some of the people you'd want on a PMC. If they
> have a "long running fork" or a "reimplementation", surely they would be
> lobbying for its integration? Merging is also good. If, despite this,
> they're choosing to do this elsewhere, and/or are having trouble merging
> projects in, isn't that a pretty sad indictment for the health of the
> project? Isn't it a bit like saying "boo-hoo, those that are doing the
> actual work might go work in their own sandpit if we won't play ball, let's
> ex-communicate them" ?
>
> Unless (as some have suspected for a while) Apache isn't about software
> anymore, it's about the continued existence of Apache (cfex: OpenOffice).-
> a political edifice where projects go to die. That's certainly what those
> added paragraphs say to me.
>
>
> On Thu, Jul 25, 2013 at 2:16 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> 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
> > >
> > >
> > >
> >
> > --
> > Sent from my phone
> >
>

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)

[Nigel Magnay <ni...@gmail.com>]

That whole section I find pretty bizarre.

- Apache is about (open-source) software.
- Writing code is *good*.
- Forks are *good*
*
*
I'm put in mind of Linus' talk about why git distribution is so important -
that 'if you don't think I'm doing a good job, then you can just take your
code from another maintainer. *That's* what keeps a project honest and
responsive to the users.

I would have thought that the kinds of people who are interested in writing
maven-esque code would be some of the people you'd want on a PMC. If they
have a "long running fork" or a "reimplementation", surely they would be
lobbying for its integration? Merging is also good. If, despite this,
they're choosing to do this elsewhere, and/or are having trouble merging
projects in, isn't that a pretty sad indictment for the health of the
project? Isn't it a bit like saying "boo-hoo, those that are doing the
actual work might go work in their own sandpit if we won't play ball, let's
ex-communicate them" ?

Unless (as some have suspected for a while) Apache isn't about software
anymore, it's about the continued existence of Apache (cfex: OpenOffice).-
a political edifice where projects go to die. That's certainly what those
added paragraphs say to me.


On Thu, Jul 25, 2013 at 2:16 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> 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
> >
> >
> >
>
> --
> Sent from my phone
>

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)

[Stephen Colebourne <sc...@joda.org>]

The section that was added below has nothing to do with the rest of
the document. It should be reverted, as it is basically nonsense as
Jason has just pointed out.

Maven has lots of other problems. This really doesn't seem like one
anyone should be spending any time or energy on.

Stephen



On 25 July 2013 14:16, Stephen Connolly <st...@gmail.com> 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
>>
>>
>>
>
> --
> Sent from my phone

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

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)

[Baptiste MATHUS <ml...@batmat.net>]

Hi,
I think the point is quite simple.
I agree with Jason that work should be the main criteria if not the only
one.
But as Stephen reminds, we should define "work" in a larger general sense
than just code. Working for the community as worshipped by the ASF can be
pushing code, sure, but also helping people in many manners : docs, ml, etc.

Cheers
Le 25 juil. 2013 22:32, "Paul Benedict" <pb...@apache.org> a écrit :

> I don't think it is possible to force volunteer efforts and/or limit
> development elsewhere. The idea of supporting a project is a vague notion.
> I have my opinions too but this language is clearly unenforceable and
> impractical.
>
> Cheers,
> Paul
>
>
> On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
>
> > As a Maven user I think that everybody who is working on a project should
> > behave the same. Hence, I would say, PMC members should rather certainly
> > demonstrate how to live the community rules.
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> > Gesendet: Donnerstag, 25. Juli 2013 15:16
> > An: Maven Users List; Maven Developers List
> > Betreff: [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)
> >
> > 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
> > >
> > >
> > >
> >
> > --
> > Sent from my phone
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> Cheers,
> Paul
>

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)

[Hervé BOUTEMY <he...@free.fr>]

Le jeudi 25 juillet 2013 19:17:08 Brian Fox a écrit :
> > There is at least one Maven Committer who has been maintaining a fork of
> > Maven for perhaps the greater part of a year.
> 
> Is it really a fork? Or is it a superset? I think people throw around
> fork but is that really true?
without:
- explanations of what is different (I mean a diff or something sufficiently 
precise)
- early work with the community on how to merge (to avoid the "huge commit at 
the end" effect, or even no merge at all)
it's a personal branch that will likely become a real fork

Notice that personal branches on non ASF git are a necessity for non-
committers, but in the case of a Maven committer (even more for PMC member), 
not doing a personal branch in ASF git is a poor choice because Maven it makes 
Maven committers harder to follow the changes.

I'm of course talking about branch of components existing in ASF: for real 
extensions, written from scratch, doing it outside ASF is another story. We 
can't force people to write everything Maven related in ASF: freedom, but it's 
sad if doing Maven OSS code outside ASF is found better. And for a PMC member, 
IMHO, it's more than "sad": it makes me wonder why being PMC member if not 
happy with the project?

Last precision: I'm talking here about extensions, not rewrite from scratch of 
existing component.


Regards,

Hervé

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

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

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)

[Martin Gainty <mg...@hotmail.com>]

 


 
> Date: Sat, 27 Jul 2013 10:53:09 +0200
> 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)
> From: fred.cooke@gmail.com
> To: dev@maven.apache.org
> 
> I have a bunch of IRL stuff to deal with at the moment, and can't even work
> on my own FOSS or proprietary code, so don't expect a "fork" soon.
> 
> When I say "broken", don't be offended, few codebases aren't broken in some
> way :-)
> 
> One example of "broken" is my SCM url being munged from this:
> 
> scm:git:git:${project.groupId}/${project.artifactId}.git
> 
> To this:
> 
> scm:git:git:${project.groupId}/${project.artifactId}.git/${project.artifactId}
MG>set up a link#!/bin/sh
if test "${SCM}x" = "x"; then
    SCM="LN -s scm:git:git:${project.groupId}/${project.artifactId}.git/${project.artifactId} scm:git:git:${project.groupId}/${project.artifactId}.git"
    if test -x ${SCM}; then
		     export SCM
    else
		      echo "Error:  Set the SCM environment variable."
		    exit
	   fi
fiifndef SCM
     SCM=${SCM}
endif

MG>then reference SCM in your maven pom.xml
> 
> And all I have to say to that, other than the pain it caused me, is LOL!
> :-p OK, I can add one more thing: F*** SVN. OK, now I'm done. :-)
> 
> Then there's the issue where my .ssh/config file was totally ignored unless
> I used the external provider, and so on and so forth.MG>export SSH="ssh -s -F /home/fcooke/.ssh/config $1"
> 
> Reality check: It's a lot easier and quicker to hack in a fix for me that
> breaks everyone else, than it is to agree on and implement a solution that
> works for everyone in a backward compatible way. Hence fork. Make what I
> need happen now and not sit around waiting for agreement on how to progress
> "properly".
> 
> Other than a fork of my very own, I'd be VERY hesitant to trust anyone
> else's forks. For example, I don't trust Debian Maven nor Fedora Maven out
> of unjustified and paranoid fear that their patches to "just use what the
> distro has" for deps might be active when they shouldn't be, etc. Forks
> rarely gain traction, unless the base project is severely lacking in some
> way.
MG>specific examples?
> Fred.MG>Martin
> 
> On Sat, Jul 27, 2013 at 9:56 AM, Hervé BOUTEMY <he...@free.fr>wrote:
> 
> > Le vendredi 26 juillet 2013 01:05:44 Fred Cooke a écrit :
> > > About the fork, though, I'm interested. I'm interested in why it's
> > > maintained and how it differs. I'm interested because I intend to fork it
> > > myself to fix things which would break others which I know won't change
> > > upstream (site and release stuff). Perhaps someone already fixed what I
> > > consider broken and others, perhaps, do not consider broken. Email me
> > > privately if need be.
> > >
> > > If the fork is just a branch (or set thereof), and not promoted as a fork
> > > (in a social sense), then is there really any harm? Is it being viewed
> > as a
> > > loss of potential work done? Open source is open for a reason.
> > +1
> >
> > in your case for example:
> >
> > if you make a fork to site plugin to fix it in a personal way, please don't
> > hide it but show us where you fork/branch and explain how you change the
> > code
> > (in a Jira issue?): I'm interested to see your work and understand what
> > you're
> > doing, since I definitely don't understand how you find the plugin broken
> > (and
> > to be honest, every time I read this "broken" sentence, I feel aggressed).
> >
> > IMHO, a personal branch can be an excellent way of working with the
> > community:
> > I'm really interested to see you fix what I can't do because I really don't
> > understand what is "broken".
> >
> > Of course, if the difference between your branch and trunk gets big, it'll
> > be
> > harder to find how to converge later: but we'll see. Explaned with the
> > community from start, and used to interact with the community to show how
> > it
> > can evolve, we can understand and define with consensus that this can be a
> > real
> > friendly fork = a different choice on some fundamental point. Or perhaps it
> > will be the start og m-site-p 4: who knows?
> >
> > Regards,
> >
> > Hervé
> >
> > >
> > > Fred.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
 		 	   		  

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)

[Fred Cooke <fr...@gmail.com>]

I have a bunch of IRL stuff to deal with at the moment, and can't even work
on my own FOSS or proprietary code, so don't expect a "fork" soon.

When I say "broken", don't be offended, few codebases aren't broken in some
way :-)

One example of "broken" is my SCM url being munged from this:

scm:git:git:${project.groupId}/${project.artifactId}.git

To this:

scm:git:git:${project.groupId}/${project.artifactId}.git/${project.artifactId}

And all I have to say to that, other than the pain it caused me, is LOL!
:-p OK, I can add one more thing: F*** SVN. OK, now I'm done. :-)

Then there's the issue where my .ssh/config file was totally ignored unless
I used the external provider, and so on and so forth.

Reality check: It's a lot easier and quicker to hack in a fix for me that
breaks everyone else, than it is to agree on and implement a solution that
works for everyone in a backward compatible way. Hence fork. Make what I
need happen now and not sit around waiting for agreement on how to progress
"properly".

Other than a fork of my very own, I'd be VERY hesitant to trust anyone
else's forks. For example, I don't trust Debian Maven nor Fedora Maven out
of unjustified and paranoid fear that their patches to "just use what the
distro has" for deps might be active when they shouldn't be, etc. Forks
rarely gain traction, unless the base project is severely lacking in some
way.

Fred.

On Sat, Jul 27, 2013 at 9:56 AM, Hervé BOUTEMY <he...@free.fr>wrote:

> Le vendredi 26 juillet 2013 01:05:44 Fred Cooke a écrit :
> > About the fork, though, I'm interested. I'm interested in why it's
> > maintained and how it differs. I'm interested because I intend to fork it
> > myself to fix things which would break others which I know won't change
> > upstream (site and release stuff). Perhaps someone already fixed what I
> > consider broken and others, perhaps, do not consider broken. Email me
> > privately if need be.
> >
> > If the fork is just a branch (or set thereof), and not promoted as a fork
> > (in a social sense), then is there really any harm? Is it being viewed
> as a
> > loss of potential work done? Open source is open for a reason.
> +1
>
> in your case for example:
>
> if you make a fork to site plugin to fix it in a personal way, please don't
> hide it but show us where you fork/branch and explain how you change the
> code
> (in a Jira issue?): I'm interested to see your work and understand what
> you're
> doing, since I definitely don't understand how you find the plugin broken
> (and
> to be honest, every time I read this "broken" sentence, I feel aggressed).
>
> IMHO, a personal branch can be an excellent way of working with the
> community:
> I'm really interested to see you fix what I can't do because I really don't
> understand what is "broken".
>
> Of course, if the difference between your branch and trunk gets big, it'll
> be
> harder to find how to converge later: but we'll see. Explaned with the
> community from start, and used to interact with the community to show how
> it
> can evolve, we can understand and define with consensus that this can be a
> real
> friendly fork = a different choice on some fundamental point. Or perhaps it
> will be the start og m-site-p 4: who knows?
>
> Regards,
>
> Hervé
>
> >
> > Fred.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

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)

[Hervé BOUTEMY <he...@free.fr>]

Le vendredi 26 juillet 2013 01:05:44 Fred Cooke a écrit :
> About the fork, though, I'm interested. I'm interested in why it's
> maintained and how it differs. I'm interested because I intend to fork it
> myself to fix things which would break others which I know won't change
> upstream (site and release stuff). Perhaps someone already fixed what I
> consider broken and others, perhaps, do not consider broken. Email me
> privately if need be.
> 
> If the fork is just a branch (or set thereof), and not promoted as a fork
> (in a social sense), then is there really any harm? Is it being viewed as a
> loss of potential work done? Open source is open for a reason.
+1

in your case for example:

if you make a fork to site plugin to fix it in a personal way, please don't 
hide it but show us where you fork/branch and explain how you change the code 
(in a Jira issue?): I'm interested to see your work and understand what you're 
doing, since I definitely don't understand how you find the plugin broken (and 
to be honest, every time I read this "broken" sentence, I feel aggressed).

IMHO, a personal branch can be an excellent way of working with the community: 
I'm really interested to see you fix what I can't do because I really don't 
understand what is "broken".

Of course, if the difference between your branch and trunk gets big, it'll be 
harder to find how to converge later: but we'll see. Explaned with the 
community from start, and used to interact with the community to show how it 
can evolve, we can understand and define with consensus that this can be a real 
friendly fork = a different choice on some fundamental point. Or perhaps it 
will be the start og m-site-p 4: who knows?

Regards,

Hervé

> 
> Fred.


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

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)

[Brian Fox <br...@infinity.nu>]

>
> There is at least one Maven Committer who has been maintaining a fork of
> Maven for perhaps the greater part of a year.

Is it really a fork? Or is it a superset? I think people throw around
fork but is that really true?

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

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)

[Fred Cooke <fr...@gmail.com>]

It would appear to me to be an evolution from the implicit nature of this
conversation thus far, but whatever, I couldn't care less. I just find
talking about it without talking about it in poor taste.

About the fork, though, I'm interested. I'm interested in why it's
maintained and how it differs. I'm interested because I intend to fork it
myself to fix things which would break others which I know won't change
upstream (site and release stuff). Perhaps someone already fixed what I
consider broken and others, perhaps, do not consider broken. Email me
privately if need be.

If the fork is just a branch (or set thereof), and not promoted as a fork
(in a social sense), then is there really any harm? Is it being viewed as a
loss of potential work done? Open source is open for a reason.

Fred.

On Fri, Jul 26, 2013 at 12:28 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> On 25 July 2013 23:15, Fred Cooke <fr...@gmail.com> wrote:
>
> > So much in-crowd politics and unspoken but apparently well-known
> material.
> >
> > Who is the person, who if they were to come across this, would obviously
> > know they were being talked about anyway?
> >
>
> I would rather we not focus on specific people. This should be a question
> that is isolated from any specific person. Often times when there is a
> specific person in mind people can have biases both for that person or
> against that person which can colour their views of the question at hand.
>
>
> >
> > Where is the, almost certainly short lived, fork of Maven located? A
> quick
> > search failed to reveal this.
> >
>
> There is at least one Maven Committer who has been maintaining a fork of
> Maven for perhaps the greater part of a year. There is nothing wrong with
> committers maintaining their own private forks. If they intend on bringing
> the work back to the Maven project, then the best way to achieve that is in
> smaller parts and not as one big code drop at the end.
>
> The question is whether the community sees this as against the spirit of
> what it means to be part of the PMC.
>
> We could pick one specific individual as a "test case" but I don't think
> that would be productive. Any such individual is likely to bring a lot of
> other baggage with them and could therefore confuse the results of such a
> "test case"
>
>
> > Such material is best on the table.
> >
>
> I hope we don't have to devolve to specifics about specific individuals.
>
>
> >
> > Fred.
> >
> > On Fri, Jul 26, 2013 at 12:07 AM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> > > On 25 July 2013 22:34, Nigel Magnay <ni...@gmail.com> wrote:
> > >
> > > > >
> > > > >
> > > > > Should the PMC encourage people experimenting on new improvements
> to
> > > > Maven
> > > > > to do that work at the ASF? And if so, should they then practice
> what
> > > > they
> > > > > preach, and ensure that any experiments with Maven take place on
> the
> > > ASF
> > > > > SCM servers (at least once such experiments become semi-serious or
> > > > progress
> > > > > enough not to cause egg-on-face syndrome)?
> > > > >
> > > > >
> > > > That feels to me like swimming entirely against the tide, and a
> recipe
> > > for
> > > > irrelevance.
> > > >
> > > > Who, in 2013, *cares* about Apache's SCM? OSS, for just about
> everyone
> > I
> > > > speak to these days runs thus:
> > > >
> > > > 1) Is it on Github?
> > > > 2) If no, fork onto GIthub.
> > > >
> > > > ASF might indeed value "community over code", but that doesn't seem
> to
> > > be a
> > > > winning strategy any longer, and those changes seem to be trying to
> > > > double-down on that strategy.
> > > >
> > >
> > > There is nothing preventing the project from being mirrored onto
> GitHub,
> > > and in fact the Maven project is mirrored there.
> > >
> > > We *legally* need to have the code end up back at ASF if we are to
> > release
> > > it under the legal protections that the ASF provides.
> > >
> > > We *legally* are supposed to review aspects of the provenance of the
> code
> > > that gets released. The more code development that takes place on non
> ASF
> > > servers, the less we can be sure of.
> > >
> > > By having commits and forks at ASF, then each non-ASF set of commits
> will
> > > be smaller and more likely from a single author which means less work
> for
> > > reviewing.
> > >
> > > Code dumps from a long running fork are thus incompatible with
> releasing
> > > from the ASF
> > >
> > > If you are a YOLO developer, perhaps you don't care about the legal
> > > stuff... your prerogative... I think it is a mistake though.
> > >
> > >
> > > >
> > > > Perhaps Maven should extricate itself from the ASF. Maybe that's what
> > > long
> > > > standing forks will do.
> > > >
> > >
> > > Perhaps. Perhaps not. This is a different question... and one that also
> > > begs an answer to a different question: what value do users of Maven
> > place
> > > on the legal protections that being released from the ASF provide.
> There
> > is
> > > also the question of whether the developers value the legal
> protections.
> > >
> > > But at the end of they day there seems to be quite a large cohort of
> OSS
> > > developers who take a YOLO attitude towards legal stuff[1]... who knows
> > > what experiences they will encounter in the next few years and whether
> > they
> > > will change their opinions in the light of their experiences and
> whether
> > > they will then see relevance in the ASF.
> > >
> > > [1]: There are lots of projects on GitHub that don't even bother to
> have
> > a
> > > license
> > >
> >
>

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)

[Stephen Connolly <st...@gmail.com>]

On 25 July 2013 23:15, Fred Cooke <fr...@gmail.com> wrote:

> So much in-crowd politics and unspoken but apparently well-known material.
>
> Who is the person, who if they were to come across this, would obviously
> know they were being talked about anyway?
>

I would rather we not focus on specific people. This should be a question
that is isolated from any specific person. Often times when there is a
specific person in mind people can have biases both for that person or
against that person which can colour their views of the question at hand.


>
> Where is the, almost certainly short lived, fork of Maven located? A quick
> search failed to reveal this.
>

There is at least one Maven Committer who has been maintaining a fork of
Maven for perhaps the greater part of a year. There is nothing wrong with
committers maintaining their own private forks. If they intend on bringing
the work back to the Maven project, then the best way to achieve that is in
smaller parts and not as one big code drop at the end.

The question is whether the community sees this as against the spirit of
what it means to be part of the PMC.

We could pick one specific individual as a "test case" but I don't think
that would be productive. Any such individual is likely to bring a lot of
other baggage with them and could therefore confuse the results of such a
"test case"


> Such material is best on the table.
>

I hope we don't have to devolve to specifics about specific individuals.


>
> Fred.
>
> On Fri, Jul 26, 2013 at 12:07 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > On 25 July 2013 22:34, Nigel Magnay <ni...@gmail.com> wrote:
> >
> > > >
> > > >
> > > > Should the PMC encourage people experimenting on new improvements to
> > > Maven
> > > > to do that work at the ASF? And if so, should they then practice what
> > > they
> > > > preach, and ensure that any experiments with Maven take place on the
> > ASF
> > > > SCM servers (at least once such experiments become semi-serious or
> > > progress
> > > > enough not to cause egg-on-face syndrome)?
> > > >
> > > >
> > > That feels to me like swimming entirely against the tide, and a recipe
> > for
> > > irrelevance.
> > >
> > > Who, in 2013, *cares* about Apache's SCM? OSS, for just about everyone
> I
> > > speak to these days runs thus:
> > >
> > > 1) Is it on Github?
> > > 2) If no, fork onto GIthub.
> > >
> > > ASF might indeed value "community over code", but that doesn't seem to
> > be a
> > > winning strategy any longer, and those changes seem to be trying to
> > > double-down on that strategy.
> > >
> >
> > There is nothing preventing the project from being mirrored onto GitHub,
> > and in fact the Maven project is mirrored there.
> >
> > We *legally* need to have the code end up back at ASF if we are to
> release
> > it under the legal protections that the ASF provides.
> >
> > We *legally* are supposed to review aspects of the provenance of the code
> > that gets released. The more code development that takes place on non ASF
> > servers, the less we can be sure of.
> >
> > By having commits and forks at ASF, then each non-ASF set of commits will
> > be smaller and more likely from a single author which means less work for
> > reviewing.
> >
> > Code dumps from a long running fork are thus incompatible with releasing
> > from the ASF
> >
> > If you are a YOLO developer, perhaps you don't care about the legal
> > stuff... your prerogative... I think it is a mistake though.
> >
> >
> > >
> > > Perhaps Maven should extricate itself from the ASF. Maybe that's what
> > long
> > > standing forks will do.
> > >
> >
> > Perhaps. Perhaps not. This is a different question... and one that also
> > begs an answer to a different question: what value do users of Maven
> place
> > on the legal protections that being released from the ASF provide. There
> is
> > also the question of whether the developers value the legal protections.
> >
> > But at the end of they day there seems to be quite a large cohort of OSS
> > developers who take a YOLO attitude towards legal stuff[1]... who knows
> > what experiences they will encounter in the next few years and whether
> they
> > will change their opinions in the light of their experiences and whether
> > they will then see relevance in the ASF.
> >
> > [1]: There are lots of projects on GitHub that don't even bother to have
> a
> > license
> >
>

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)

[Fred Cooke <fr...@gmail.com>]

So much in-crowd politics and unspoken but apparently well-known material.

Who is the person, who if they were to come across this, would obviously
know they were being talked about anyway?

Where is the, almost certainly short lived, fork of Maven located? A quick
search failed to reveal this.

Such material is best on the table.

Fred.

On Fri, Jul 26, 2013 at 12:07 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> On 25 July 2013 22:34, Nigel Magnay <ni...@gmail.com> wrote:
>
> > >
> > >
> > > Should the PMC encourage people experimenting on new improvements to
> > Maven
> > > to do that work at the ASF? And if so, should they then practice what
> > they
> > > preach, and ensure that any experiments with Maven take place on the
> ASF
> > > SCM servers (at least once such experiments become semi-serious or
> > progress
> > > enough not to cause egg-on-face syndrome)?
> > >
> > >
> > That feels to me like swimming entirely against the tide, and a recipe
> for
> > irrelevance.
> >
> > Who, in 2013, *cares* about Apache's SCM? OSS, for just about everyone I
> > speak to these days runs thus:
> >
> > 1) Is it on Github?
> > 2) If no, fork onto GIthub.
> >
> > ASF might indeed value "community over code", but that doesn't seem to
> be a
> > winning strategy any longer, and those changes seem to be trying to
> > double-down on that strategy.
> >
>
> There is nothing preventing the project from being mirrored onto GitHub,
> and in fact the Maven project is mirrored there.
>
> We *legally* need to have the code end up back at ASF if we are to release
> it under the legal protections that the ASF provides.
>
> We *legally* are supposed to review aspects of the provenance of the code
> that gets released. The more code development that takes place on non ASF
> servers, the less we can be sure of.
>
> By having commits and forks at ASF, then each non-ASF set of commits will
> be smaller and more likely from a single author which means less work for
> reviewing.
>
> Code dumps from a long running fork are thus incompatible with releasing
> from the ASF
>
> If you are a YOLO developer, perhaps you don't care about the legal
> stuff... your prerogative... I think it is a mistake though.
>
>
> >
> > Perhaps Maven should extricate itself from the ASF. Maybe that's what
> long
> > standing forks will do.
> >
>
> Perhaps. Perhaps not. This is a different question... and one that also
> begs an answer to a different question: what value do users of Maven place
> on the legal protections that being released from the ASF provide. There is
> also the question of whether the developers value the legal protections.
>
> But at the end of they day there seems to be quite a large cohort of OSS
> developers who take a YOLO attitude towards legal stuff[1]... who knows
> what experiences they will encounter in the next few years and whether they
> will change their opinions in the light of their experiences and whether
> they will then see relevance in the ASF.
>
> [1]: There are lots of projects on GitHub that don't even bother to have a
> license
>

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)

[Stephen Connolly <st...@gmail.com>]

On 25 July 2013 22:34, Nigel Magnay <ni...@gmail.com> wrote:

> >
> >
> > Should the PMC encourage people experimenting on new improvements to
> Maven
> > to do that work at the ASF? And if so, should they then practice what
> they
> > preach, and ensure that any experiments with Maven take place on the ASF
> > SCM servers (at least once such experiments become semi-serious or
> progress
> > enough not to cause egg-on-face syndrome)?
> >
> >
> That feels to me like swimming entirely against the tide, and a recipe for
> irrelevance.
>
> Who, in 2013, *cares* about Apache's SCM? OSS, for just about everyone I
> speak to these days runs thus:
>
> 1) Is it on Github?
> 2) If no, fork onto GIthub.
>
> ASF might indeed value "community over code", but that doesn't seem to be a
> winning strategy any longer, and those changes seem to be trying to
> double-down on that strategy.
>

There is nothing preventing the project from being mirrored onto GitHub,
and in fact the Maven project is mirrored there.

We *legally* need to have the code end up back at ASF if we are to release
it under the legal protections that the ASF provides.

We *legally* are supposed to review aspects of the provenance of the code
that gets released. The more code development that takes place on non ASF
servers, the less we can be sure of.

By having commits and forks at ASF, then each non-ASF set of commits will
be smaller and more likely from a single author which means less work for
reviewing.

Code dumps from a long running fork are thus incompatible with releasing
from the ASF

If you are a YOLO developer, perhaps you don't care about the legal
stuff... your prerogative... I think it is a mistake though.


>
> Perhaps Maven should extricate itself from the ASF. Maybe that's what long
> standing forks will do.
>

Perhaps. Perhaps not. This is a different question... and one that also
begs an answer to a different question: what value do users of Maven place
on the legal protections that being released from the ASF provide. There is
also the question of whether the developers value the legal protections.

But at the end of they day there seems to be quite a large cohort of OSS
developers who take a YOLO attitude towards legal stuff[1]... who knows
what experiences they will encounter in the next few years and whether they
will change their opinions in the light of their experiences and whether
they will then see relevance in the ASF.

[1]: There are lots of projects on GitHub that don't even bother to have a
license

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)

[Nigel Magnay <ni...@gmail.com>]

>
>
> Should the PMC encourage people experimenting on new improvements to Maven
> to do that work at the ASF? And if so, should they then practice what they
> preach, and ensure that any experiments with Maven take place on the ASF
> SCM servers (at least once such experiments become semi-serious or progress
> enough not to cause egg-on-face syndrome)?
>
>
That feels to me like swimming entirely against the tide, and a recipe for
irrelevance.

Who, in 2013, *cares* about Apache's SCM? OSS, for just about everyone I
speak to these days runs thus:

1) Is it on Github?
2) If no, fork onto GIthub.

ASF might indeed value "community over code", but that doesn't seem to be a
winning strategy any longer, and those changes seem to be trying to
double-down on that strategy.

Perhaps Maven should extricate itself from the ASF. Maybe that's what long
standing forks will do.

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)

[Ron Wheeler <rw...@artifact-software.com>]

On 26/07/2013 10:26 PM, Richard Sand wrote:
> "Sometimes groupthink does not reach the best conclusion and an individual effort may be required to move the state of the art.
> OTOH, the majority should not be held up by a person with ideas that the majority does not want to pursue. "
>
> So what you're saying is, the needs of the many outweigh the needs of the few. Or the one?
>
> Sorry couldn't resist...!

One or the other depending on the circumstance.

Freedom comes in many ways and sometimes letting go gives more freedom 
to the one doing the releasing than to the one being "freed".



>
> -----Original Message-----
> From: Ron Wheeler [mailto:rwheeler@artifact-software.com]
> Sent: Friday, July 26, 2013 9:45 PM
> To: users@maven.apache.org
> 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)
>
>
> On 26/07/2013 11:35 AM, Baptiste MATHUS wrote:
>> Le 25 juil. 2013 23:05, "Stephen Connolly"
>> <st...@gmail.com> a écrit :
>>> Perhaps we could reframe the question a little then (as people seem
>>> to be testing hung up on the committed wording)...
>>>
>>> Should the PMC encourage people experimenting on new improvements to
>>> Maven to do that work at the ASF?
>> Sure. I don't see how one could disagree with the statement.
> Encourage or force! Big difference.
>
> Sometimes groupthink does not reach the best conclusion and an individual effort may be required to move the state of the art.
> OTOH, the majority should not be held up by a person with ideas that the majority does not want to pursue. Both sides can benefit from a fork.
>
>
>>> And if so, should they then practice what they preach, and ensure
>>> that any experiments with Maven take place on the ASF SCM servers (at
>>> least once such experiments become semi-serious or
>> progress
>>> enough not to cause egg-on-face syndrome)?
>> Re-reading it with *PMC member* in mind, it also makes sense.
>> The difficulty is actually defining what is semi-serious, but anyway
>> not sure I'd see the goal for a *pmc member* to commit his WIP outside the asf.
>> Sure there's github's facilities to help contribution but there's
>> already an automatic asf->github mirroring, right?
>>
>>> Shoud the PMC promote other Apache projects, or moving non-Apache
>>> projects to Apache? (Right now, to work on an issue in core and
>>> effect the change yourself you may need to establish merit with:
>>> Apache Maven, Eclipse Sisu, Eclipse Aether, Plexus, Apache Commons,
>>> Classworlds, etc. Now it may be fine with half of these at Eclipse
>>> and the ther half here... Or maybe not... But that is a lot of
>>> projects where you need to establish merit and perhaps maintain merit
>>> just to be able to commit directly (which sometimes is the only way
>>> to effect the type of cross system changes that some of
>> our
>>> more obscure bugs may require... GIT makes this less of a
>>> requirement, as patches on SVN are a PITA, though) )
>> Not sure how this one could get handled in practice. I suppose this is
>> better to try and keep them at Apache, but using a myriad of different
>> libs is a reality in a majority if not all java projects.
>> To handle code issues, I think this might suffice to check the license
>> allows a local versions be used (as Jenkins does) to be sure Maven
>> does not get stuck because of one of those deps.
>> I think apache projects should be preferred when there's a real
>> equivalence between two choices. But again defining/agreeing on this
>> can be hard. On the log4j2/logback side for example, even if I
>> personally use logback on a daily-basis I'd understand log4j2 be
>> chosen as a default provider because it's a apache project and the
>> equivalence seems to be more and more a reality.
> As a consumer of Apache products, I certainly appreciate the importance of reducing the number of licenses schemes in a dependency.
> This means that I would prefer log4j over a marginally better logging framework that came with another license even if the terms of the license are acceptable.
> I simply prefer to work with a license that I already have invested time in understanding and trust rather than a license that I have to research.
>
> Ron
>
>
>> Cheers
>>
>> -- Baptiste
>>
>


-- 
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

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)

[Richard Sand <rs...@idfconnect.com>]

"Sometimes groupthink does not reach the best conclusion and an individual effort may be required to move the state of the art.
OTOH, the majority should not be held up by a person with ideas that the majority does not want to pursue. "

So what you're saying is, the needs of the many outweigh the needs of the few. Or the one?

Sorry couldn't resist...!

-----Original Message-----
From: Ron Wheeler [mailto:rwheeler@artifact-software.com] 
Sent: Friday, July 26, 2013 9:45 PM
To: users@maven.apache.org
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)


On 26/07/2013 11:35 AM, Baptiste MATHUS wrote:
> Le 25 juil. 2013 23:05, "Stephen Connolly" 
> <st...@gmail.com> a écrit :
>> Perhaps we could reframe the question a little then (as people seem 
>> to be testing hung up on the committed wording)...
>>
>> Should the PMC encourage people experimenting on new improvements to 
>> Maven to do that work at the ASF?
> Sure. I don't see how one could disagree with the statement.

Encourage or force! Big difference.

Sometimes groupthink does not reach the best conclusion and an individual effort may be required to move the state of the art.
OTOH, the majority should not be held up by a person with ideas that the majority does not want to pursue. Both sides can benefit from a fork.


>
>> And if so, should they then practice what they preach, and ensure 
>> that any experiments with Maven take place on the ASF SCM servers (at 
>> least once such experiments become semi-serious or
> progress
>> enough not to cause egg-on-face syndrome)?
> Re-reading it with *PMC member* in mind, it also makes sense.
> The difficulty is actually defining what is semi-serious, but anyway 
> not sure I'd see the goal for a *pmc member* to commit his WIP outside the asf.
> Sure there's github's facilities to help contribution but there's 
> already an automatic asf->github mirroring, right?
>
>> Shoud the PMC promote other Apache projects, or moving non-Apache 
>> projects to Apache? (Right now, to work on an issue in core and 
>> effect the change yourself you may need to establish merit with: 
>> Apache Maven, Eclipse Sisu, Eclipse Aether, Plexus, Apache Commons, 
>> Classworlds, etc. Now it may be fine with half of these at Eclipse 
>> and the ther half here... Or maybe not... But that is a lot of 
>> projects where you need to establish merit and perhaps maintain merit 
>> just to be able to commit directly (which sometimes is the only way 
>> to effect the type of cross system changes that some of
> our
>> more obscure bugs may require... GIT makes this less of a 
>> requirement, as patches on SVN are a PITA, though) )
> Not sure how this one could get handled in practice. I suppose this is 
> better to try and keep them at Apache, but using a myriad of different 
> libs is a reality in a majority if not all java projects.
> To handle code issues, I think this might suffice to check the license 
> allows a local versions be used (as Jenkins does) to be sure Maven 
> does not get stuck because of one of those deps.
> I think apache projects should be preferred when there's a real 
> equivalence between two choices. But again defining/agreeing on this 
> can be hard. On the log4j2/logback side for example, even if I 
> personally use logback on a daily-basis I'd understand log4j2 be 
> chosen as a default provider because it's a apache project and the 
> equivalence seems to be more and more a reality.
As a consumer of Apache products, I certainly appreciate the importance of reducing the number of licenses schemes in a dependency.
This means that I would prefer log4j over a marginally better logging framework that came with another license even if the terms of the license are acceptable.
I simply prefer to work with a license that I already have invested time in understanding and trust rather than a license that I have to research.

Ron


> Cheers
>
> -- Baptiste
>


-- 
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




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

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)

[Ron Wheeler <rw...@artifact-software.com>]

On 26/07/2013 11:35 AM, Baptiste MATHUS wrote:
> Le 25 juil. 2013 23:05, "Stephen Connolly" <st...@gmail.com>
> a écrit :
>> Perhaps we could reframe the question a little then (as people seem to be
>> testing hung up on the committed wording)...
>>
>> Should the PMC encourage people experimenting on new improvements to Maven
>> to do that work at the ASF?
> Sure. I don't see how one could disagree with the statement.

Encourage or force! Big difference.

Sometimes groupthink does not reach the best conclusion and an 
individual effort may be required to move the state of the art.
OTOH, the majority should not be held up by a person with ideas that the 
majority does not want to pursue. Both sides can benefit from a fork.


>
>> And if so, should they then practice what they
>> preach, and ensure that any experiments with Maven take place on the ASF
>> SCM servers (at least once such experiments become semi-serious or
> progress
>> enough not to cause egg-on-face syndrome)?
> Re-reading it with *PMC member* in mind, it also makes sense.
> The difficulty is actually defining what is semi-serious, but anyway not
> sure I'd see the goal for a *pmc member* to commit his WIP outside the asf.
> Sure there's github's facilities to help contribution but there's already
> an automatic asf->github mirroring, right?
>
>> Shoud the PMC promote other Apache projects, or moving non-Apache projects
>> to Apache? (Right now, to work on an issue in core and effect the change
>> yourself you may need to establish merit with: Apache Maven, Eclipse Sisu,
>> Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
>> fine with half of these at Eclipse and the ther half here... Or maybe
>> not... But that is a lot of projects where you need to establish merit and
>> perhaps maintain merit just to be able to commit directly (which sometimes
>> is the only way to effect the type of cross system changes that some of
> our
>> more obscure bugs may require... GIT makes this less of a requirement, as
>> patches on SVN are a PITA, though) )
> Not sure how this one could get handled in practice. I suppose this is
> better to try and keep them at Apache, but using a myriad of different libs
> is a reality in a majority if not all java projects.
> To handle code issues, I think this might suffice to check the license
> allows a local versions be used (as Jenkins does) to be sure Maven does not
> get stuck because of one of those deps.
> I think apache projects should be preferred when there's a real equivalence
> between two choices. But again defining/agreeing on this can be hard. On
> the log4j2/logback side for example, even if I personally use logback on a
> daily-basis I'd understand log4j2 be chosen as a default provider because
> it's a apache project and the equivalence seems to be more and more a
> reality.
As a consumer of Apache products, I certainly appreciate the importance 
of reducing the number of licenses schemes in a dependency.
This means that I would prefer log4j over a marginally better logging 
framework that came with another license even if the terms of the 
license are acceptable.
I simply prefer to work with a license that I already have invested time 
in understanding and trust rather than a license that I have to research.

Ron


> Cheers
>
> -- Baptiste
>


-- 
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

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)

[Baptiste MATHUS <ml...@batmat.net>]

Le 25 juil. 2013 23:05, "Stephen Connolly" <st...@gmail.com>
a écrit :
>
> Perhaps we could reframe the question a little then (as people seem to be
> testing hung up on the committed wording)...
>
> Should the PMC encourage people experimenting on new improvements to Maven
> to do that work at the ASF?

Sure. I don't see how one could disagree with the statement.

> And if so, should they then practice what they
> preach, and ensure that any experiments with Maven take place on the ASF
> SCM servers (at least once such experiments become semi-serious or
progress
> enough not to cause egg-on-face syndrome)?

Re-reading it with *PMC member* in mind, it also makes sense.
The difficulty is actually defining what is semi-serious, but anyway not
sure I'd see the goal for a *pmc member* to commit his WIP outside the asf.
Sure there's github's facilities to help contribution but there's already
an automatic asf->github mirroring, right?

>
> Shoud the PMC promote other Apache projects, or moving non-Apache projects
> to Apache? (Right now, to work on an issue in core and effect the change
> yourself you may need to establish merit with: Apache Maven, Eclipse Sisu,
> Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
> fine with half of these at Eclipse and the ther half here... Or maybe
> not... But that is a lot of projects where you need to establish merit and
> perhaps maintain merit just to be able to commit directly (which sometimes
> is the only way to effect the type of cross system changes that some of
our
> more obscure bugs may require... GIT makes this less of a requirement, as
> patches on SVN are a PITA, though) )

Not sure how this one could get handled in practice. I suppose this is
better to try and keep them at Apache, but using a myriad of different libs
is a reality in a majority if not all java projects.
To handle code issues, I think this might suffice to check the license
allows a local versions be used (as Jenkins does) to be sure Maven does not
get stuck because of one of those deps.
I think apache projects should be preferred when there's a real equivalence
between two choices. But again defining/agreeing on this can be hard. On
the log4j2/logback side for example, even if I personally use logback on a
daily-basis I'd understand log4j2 be chosen as a default provider because
it's a apache project and the equivalence seems to be more and more a
reality.

Cheers

-- Baptiste

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)

[Jason van Zyl <ja...@tesla.io>]

On Jul 25, 2013, at 5:05 PM, Stephen Connolly <st...@gmail.com> wrote:

> Perhaps we could reframe the question a little then (as people seem to be
> testing hung up on the committed wording)...
> 
> Should the PMC encourage people experimenting on new improvements to Maven
> to do that work at the ASF? And if so, should they then practice what they
> preach, and ensure that any experiments with Maven take place on the ASF
> SCM servers (at least once such experiments become semi-serious or progress
> enough not to cause egg-on-face syndrome)?

If members of the Apache Board are leading by example then the answer to your questions are clearly no. Cloudera makes a distribution of Hadoop. It definitely contains features and code that don't exist in the standard Apache distribution and this all doesn't get developed at Apache. They have to as that's one of their differentiators. I don't think this is a bad thing, I think this is a good thing. A company who has customers, who pay for Cloudera employees to work on Hadoop and I'm sure some of that work finds its way back into Hadoop. That's how healthy ecosystems work. And if you look at many of the PMCs they also have members that work at commercial companies you will also find more examples of no to both of your questions.

> 
> Shoud the PMC promote other Apache projects,

Blindly? With the criterion being "eat your own dogfood"? That, to me, would be ridiculous. Use the best library you can find regardless of where it comes from provided the license is appropriate.

> or moving non-Apache projects
> to Apache? (Right now, to work on an issue in core and effect the change
> yourself you may need to establish merit with: Apache Maven, Eclipse Sisu,
> Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
> fine with half of these at Eclipse and the ther half here... Or maybe
> not... But that is a lot of projects where you need to establish merit and
> perhaps maintain merit just to be able to commit directly (which sometimes
> is the only way to effect the type of cross system changes that some of our
> more obscure bugs may require... GIT makes this less of a requirement, as
> patches on SVN are a PITA, though) )

Nonsense. I just got two pull requests for Polyglot Tesla in the last two days from people who are interested. If they are good patches I'll take them. Do you really think that a project is presented with a good patch the project is going to say no? Everyone talks about this mythical barrier and that it's so much work to do something not at Apache. Has anyone ever stopped you from contributing to any of the projects above? I've seen more content in the form of  email about the potential of not being able to commit to these projects than code contributions actually presented to these projects. I think if someone actually tried contributing, instead of imagining why it's hard, you'd find that it's not hard. Thinking that everything has to be here to work on it is a rather provincial point of view. It doesn't mean I don't care about what I work on here, but I acknowledge that there is work outside of Apache that's useful and interesting.

Anyone who actually fixes cross project issues just fixes cross project issues. Stuart is not even a committer and fixes more cross project issues than most committers here and you don't see him bemoaning the fact he doesn't have commit access. So I think that whole notion that everything has to be here in order for their to be an effective way to work on issues is complete bunk.

> 
> These types of questions need resolution as they will, further down the
> road, rise up again and cause wounds... Eg logback vs log4j2 is one that
> simmers at the edge (any time anyone mentioned coloured loggers)
> 
> -Stephen
> 
> On Thursday, 25 July 2013, Paul Benedict wrote:
> 
>> I don't think it is possible to force volunteer efforts and/or limit
>> development elsewhere. The idea of supporting a project is a vague notion.
>> I have my opinions too but this language is clearly unenforceable and
>> impractical.
>> 
>> Cheers,
>> Paul
>> 
>> 
>> On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
>> 
>>> As a Maven user I think that everybody who is working on a project should
>>> behave the same. Hence, I would say, PMC members should rather certainly
>>> demonstrate how to live the community rules.
>>> 
>>> -----Ursprüngliche Nachricht-----
>>> Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>>> Gesendet: Donnerstag, 25. Juli 2013 15:16
>>> An: Maven Users List; Maven Developers List
>>> Betreff: [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)
>>> 
>>> 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 he> To unsubscribe, e-mail:
>> dev-unsubscribe@maven.apache.org <javascript:;>
>>> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
>>> 
>>> 
>> 
>> 
>> --
>> Cheers,
>> Paul
>> 
> 
> 
> -- 
> Sent from my phone

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of 
dogmas or goals, it's always because these dogmas or
goals are in doubt.

  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

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)

[Ron Wheeler <rw...@artifact-software.com>]

On 25/07/2013 5:05 PM, Stephen Connolly wrote:
> Perhaps we could reframe the question a little then (as people seem to be
> testing hung up on the committed wording)...
>
> Should the PMC encourage people experimenting on new improvements to Maven
> to do that work at the ASF? And if so, should they then practice what they
> preach, and ensure that any experiments with Maven take place on the ASF
> SCM servers (at least once such experiments become semi-serious or progress
> enough not to cause egg-on-face syndrome)?
No.
> Shoud the PMC promote other Apache projects, or moving non-Apache projects
> to Apache? (Right now, to work on an issue in core and effect the change
> yourself you may need to establish merit with: Apache Maven, Eclipse Sisu,
> Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
> fine with half of these at Eclipse and the ther half here... Or maybe
> not... But that is a lot of projects where you need to establish merit and
> perhaps maintain merit just to be able to commit directly (which sometimes
> is the only way to effect the type of cross system changes that some of our
> more obscure bugs may require... GIT makes this less of a requirement, as
> patches on SVN are a PITA, though) )
Don't see this as helping the community.
> These types of questions need resolution as they will, further down the
> road, rise up again and cause wounds... Eg logback vs log4j2 is one that
> simmers at the edge (any time anyone mentioned coloured loggers)

Some of these can be discussed in the user community if there is not an 
obvious answer.

> -Stephen
>
> On Thursday, 25 July 2013, Paul Benedict wrote:
>
>> I don't think it is possible to force volunteer efforts and/or limit
>> development elsewhere. The idea of supporting a project is a vague notion.
>> I have my opinions too but this language is clearly unenforceable and
>> impractical.
>>
>> Cheers,
>> Paul
>>
>>
>> On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
>>
>>> As a Maven user I think that everybody who is working on a project should
>>> behave the same. Hence, I would say, PMC members should rather certainly
>>> demonstrate how to live the community rules.
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>>> Gesendet: Donnerstag, 25. Juli 2013 15:16
>>> An: Maven Users List; Maven Developers List
>>> Betreff: [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)
>>>
>>> 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 he> To unsubscribe, e-mail:
>> dev-unsubscribe@maven.apache.org <javascript:;>
>>> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
>>>
>>>
>>
>> --
>> Cheers,
>> Paul
>>
>


-- 
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

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)

[Ron Wheeler <rw...@artifact-software.com>]

On 25/07/2013 5:32 PM, Stephen Connolly wrote:
> On 25 July 2013 22:17, Paul Benedict <pb...@apache.org> wrote:
>
>> Stephen, those are great questions. Yet, I think these questions are riding
>> an assumption that PMC members are solely volunteering at Apache, because
>> the emphasis (as I interpret your words) is to place the Apache project
>> first/above other external contributions. Isn't that the heart of this
>> debate? A person who solely contributes to Apache and no other OS
>> organizations has no divided loyalties -- they do all their work here. But
>> what happens when contributions are here and elsewhere?
>
> If they feel they cannot resolve any conflict between their role on the PMC
> and any responsibilities the Maven community decide are part and parcel of
> that role with their roles in other projects, then quite simply they can
> just step down from the PMC and remain a committer. There is no shame in so
> doing.
>
> Which brings us back to what does the community expect from its PMC?
>
I can only speak for me.
I expect the committee to:
- Maintain a coherent roadmap that makes sense to the majority of the 
community
- To communicate the roadmap to the community and listen to the feedback
- To ensure that the releases are complete - code tested and 
documentation updated
- To coordinate the activities of the committers to ensure that they are 
meeting the technical standards and completing the release functionality 
and docs according to the agreed schedule.
- To ensure that the project committers are enjoying working together 
and that disagreements are worked on in a professional way.

Ron

>> I ask rhetorically,
>> to solicit answers, of course... and I see where this is going and what
>> historical processes within Maven are being addressed.
>>
>>
>> On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>>> Perhaps we could reframe the question a little then (as people seem to be
>>> testing hung up on the committed wording)...
>>>
>>> Should the PMC encourage people experimenting on new improvements to
>> Maven
>>> to do that work at the ASF? And if so, should they then practice what
>> they
>>> preach, and ensure that any experiments with Maven take place on the ASF
>>> SCM servers (at least once such experiments become semi-serious or
>> progress
>>> enough not to cause egg-on-face syndrome)?
>>>
>>> Shoud the PMC promote other Apache projects, or moving non-Apache
>> projects
>>> to Apache? (Right now, to work on an issue in core and effect the change
>>> yourself you may need to establish merit with: Apache Maven, Eclipse
>> Sisu,
>>> Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
>>> fine with half of these at Eclipse and the ther half here... Or maybe
>>> not... But that is a lot of projects where you need to establish merit
>> and
>>> perhaps maintain merit just to be able to commit directly (which
>> sometimes
>>> is the only way to effect the type of cross system changes that some of
>> our
>>> more obscure bugs may require... GIT makes this less of a requirement, as
>>> patches on SVN are a PITA, though) )
>>>
>>> These types of questions need resolution as they will, further down the
>>> road, rise up again and cause wounds... Eg logback vs log4j2 is one that
>>> simmers at the edge (any time anyone mentioned coloured loggers)
>>>
>>> -Stephen
>>>
>>> On Thursday, 25 July 2013, Paul Benedict wrote:
>>>
>>>> I don't think it is possible to force volunteer efforts and/or limit
>>>> development elsewhere. The idea of supporting a project is a vague
>>> notion.
>>>> I have my opinions too but this language is clearly unenforceable and
>>>> impractical.
>>>>
>>>> Cheers,
>>>> Paul
>>>>
>>>>
>>>> On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
>>>>
>>>>> As a Maven user I think that everybody who is working on a project
>>> should
>>>>> behave the same. Hence, I would say, PMC members should rather
>>> certainly
>>>>> demonstrate how to live the community rules.
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>>>>> Gesendet: Donnerstag, 25. Juli 2013 15:16
>>>>> An: Maven Users List; Maven Developers List
>>>>> Betreff: [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)
>>>>>
>>>>> 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 he> To unsubscribe, e-mail:
>>>> dev-unsubscribe@maven.apache.org <javascript:;>


-- 
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

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)

[Stephen Connolly <st...@gmail.com>]

On 25 July 2013 22:17, Paul Benedict <pb...@apache.org> wrote:

> Stephen, those are great questions. Yet, I think these questions are riding
> an assumption that PMC members are solely volunteering at Apache, because
> the emphasis (as I interpret your words) is to place the Apache project
> first/above other external contributions. Isn't that the heart of this
> debate? A person who solely contributes to Apache and no other OS
> organizations has no divided loyalties -- they do all their work here. But
> what happens when contributions are here and elsewhere?


If they feel they cannot resolve any conflict between their role on the PMC
and any responsibilities the Maven community decide are part and parcel of
that role with their roles in other projects, then quite simply they can
just step down from the PMC and remain a committer. There is no shame in so
doing.

Which brings us back to what does the community expect from its PMC?


> I ask rhetorically,
> to solicit answers, of course... and I see where this is going and what
> historical processes within Maven are being addressed.
>
>
> On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > Perhaps we could reframe the question a little then (as people seem to be
> > testing hung up on the committed wording)...
> >
> > Should the PMC encourage people experimenting on new improvements to
> Maven
> > to do that work at the ASF? And if so, should they then practice what
> they
> > preach, and ensure that any experiments with Maven take place on the ASF
> > SCM servers (at least once such experiments become semi-serious or
> progress
> > enough not to cause egg-on-face syndrome)?
> >
> > Shoud the PMC promote other Apache projects, or moving non-Apache
> projects
> > to Apache? (Right now, to work on an issue in core and effect the change
> > yourself you may need to establish merit with: Apache Maven, Eclipse
> Sisu,
> > Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
> > fine with half of these at Eclipse and the ther half here... Or maybe
> > not... But that is a lot of projects where you need to establish merit
> and
> > perhaps maintain merit just to be able to commit directly (which
> sometimes
> > is the only way to effect the type of cross system changes that some of
> our
> > more obscure bugs may require... GIT makes this less of a requirement, as
> > patches on SVN are a PITA, though) )
> >
> > These types of questions need resolution as they will, further down the
> > road, rise up again and cause wounds... Eg logback vs log4j2 is one that
> > simmers at the edge (any time anyone mentioned coloured loggers)
> >
> > -Stephen
> >
> > On Thursday, 25 July 2013, Paul Benedict wrote:
> >
> > > I don't think it is possible to force volunteer efforts and/or limit
> > > development elsewhere. The idea of supporting a project is a vague
> > notion.
> > > I have my opinions too but this language is clearly unenforceable and
> > > impractical.
> > >
> > > Cheers,
> > > Paul
> > >
> > >
> > > On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
> > >
> > > > As a Maven user I think that everybody who is working on a project
> > should
> > > > behave the same. Hence, I would say, PMC members should rather
> > certainly
> > > > demonstrate how to live the community rules.
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> > > > Gesendet: Donnerstag, 25. Juli 2013 15:16
> > > > An: Maven Users List; Maven Developers List
> > > > Betreff: [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)
> > > >
> > > > 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 he> To unsubscribe, e-mail:
> > > dev-unsubscribe@maven.apache.org <javascript:;>
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > <javascript:;>
> > > >
> > > >
> > >
> > >
> > > --
> > > Cheers,
> > > Paul
> > >
> >
> >
> > --
> > Sent from my phone
> >
>
>
>
> --
> Cheers,
> Paul
>

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)

[Stephen Connolly <st...@gmail.com>]

On 25 July 2013 22:17, Paul Benedict <pb...@apache.org> wrote:

> Stephen, those are great questions. Yet, I think these questions are riding
> an assumption that PMC members are solely volunteering at Apache, because
> the emphasis (as I interpret your words) is to place the Apache project
> first/above other external contributions. Isn't that the heart of this
> debate? A person who solely contributes to Apache and no other OS
> organizations has no divided loyalties -- they do all their work here. But
> what happens when contributions are here and elsewhere?


If they feel they cannot resolve any conflict between their role on the PMC
and any responsibilities the Maven community decide are part and parcel of
that role with their roles in other projects, then quite simply they can
just step down from the PMC and remain a committer. There is no shame in so
doing.

Which brings us back to what does the community expect from its PMC?


> I ask rhetorically,
> to solicit answers, of course... and I see where this is going and what
> historical processes within Maven are being addressed.
>
>
> On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > Perhaps we could reframe the question a little then (as people seem to be
> > testing hung up on the committed wording)...
> >
> > Should the PMC encourage people experimenting on new improvements to
> Maven
> > to do that work at the ASF? And if so, should they then practice what
> they
> > preach, and ensure that any experiments with Maven take place on the ASF
> > SCM servers (at least once such experiments become semi-serious or
> progress
> > enough not to cause egg-on-face syndrome)?
> >
> > Shoud the PMC promote other Apache projects, or moving non-Apache
> projects
> > to Apache? (Right now, to work on an issue in core and effect the change
> > yourself you may need to establish merit with: Apache Maven, Eclipse
> Sisu,
> > Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
> > fine with half of these at Eclipse and the ther half here... Or maybe
> > not... But that is a lot of projects where you need to establish merit
> and
> > perhaps maintain merit just to be able to commit directly (which
> sometimes
> > is the only way to effect the type of cross system changes that some of
> our
> > more obscure bugs may require... GIT makes this less of a requirement, as
> > patches on SVN are a PITA, though) )
> >
> > These types of questions need resolution as they will, further down the
> > road, rise up again and cause wounds... Eg logback vs log4j2 is one that
> > simmers at the edge (any time anyone mentioned coloured loggers)
> >
> > -Stephen
> >
> > On Thursday, 25 July 2013, Paul Benedict wrote:
> >
> > > I don't think it is possible to force volunteer efforts and/or limit
> > > development elsewhere. The idea of supporting a project is a vague
> > notion.
> > > I have my opinions too but this language is clearly unenforceable and
> > > impractical.
> > >
> > > Cheers,
> > > Paul
> > >
> > >
> > > On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
> > >
> > > > As a Maven user I think that everybody who is working on a project
> > should
> > > > behave the same. Hence, I would say, PMC members should rather
> > certainly
> > > > demonstrate how to live the community rules.
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> > > > Gesendet: Donnerstag, 25. Juli 2013 15:16
> > > > An: Maven Users List; Maven Developers List
> > > > Betreff: [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)
> > > >
> > > > 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 he> To unsubscribe, e-mail:
> > > dev-unsubscribe@maven.apache.org <javascript:;>
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > <javascript:;>
> > > >
> > > >
> > >
> > >
> > > --
> > > Cheers,
> > > Paul
> > >
> >
> >
> > --
> > Sent from my phone
> >
>
>
>
> --
> Cheers,
> Paul
>

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)

[Barrie Treloar <ba...@gmail.com>]

>>  About growing the PMC, I suppose we're looping here ;-). IIUC, again, I
>> think the point is precisely to define those values/rules to be able to
>> induct more serenely new PMC members while asking them to adhere to those
>> definitions.
>>
>
> I think that, so far, this idea has not found much favour with the broader
> community.
> I am not sure how you get someone to promise not to undertake enhancements
> that result in too much code or add too much functionality.
>
> The actual wording of the proposed litmus test only indirectly addressed
> this and seemed to be an attempt to codify a personality conflict with rules
> that would hurt the long-term viability of the project by replacing
> innovation with the group-think of an inner clique.
> It also seemed to go against the principle of open source.
> At least, that was the way it appeared to me as a community member outside
> the PMC.

At the moment, the words themselves are meaningless (as they are still
up for debate - and why this thread was created, so that they could be
crafted by the community).

Once there is some consensus they will be used in the future.

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

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)

[Ron Wheeler <rw...@artifact-software.com>]

On 02/08/2013 12:56 AM, Baptiste MATHUS wrote:
>
> 2013/8/2 Ron Wheeler <rwheeler@artifact-software.com 
> <ma...@artifact-software.com>>
>
>     On 01/08/2013 5:55 PM, Jonathan Sharp wrote:
>
>         I think John C raises an interesting case here, where the
>         voting process
>         can fall down.
>
>         A large code dump like that can hurt the quality of
>         documentation and
>         support (in addition to team morale).
>
>     It depends on how good the code and documentation is!
>     If the PMC can not deal with the amount of code being proposed,
>     they need to increase the PMC.
>     In the meantime, they can always defer the acceptance.
>
>     I would love to have the problem of my team producing too much
>     tested code and documentation for me to read!!!
>
>
> That's the point, not really talking of "your team" here. The (somehow 
> a bit hypothetic, granted) point raised here is where you would find 
> yourself in front of say one year of coding being proposed. And IIUC, 
> we're only talking about *PMC members* and values here. Sure, one 
> company/individual could work on his fork and propose a lot of changes 
> later when he finally wants/is allowed to, and btw he hasn't any 
> direct commit access to the project and so on.

It will be harder to say yes to the new code and the coder may find that 
he/she has to do a lot of rework to resynchronize with the current base 
but you are still getting enhancements that otherwise would not be done.
The coder is always free to make a fork and continue with a "better" 
product if the work submitted is not acceptable to the PMC or the PMC 
becomes moribund.
I think that this is the normal way to handle this.
Obviously, if the PMC can not keep up with a group of coders that are 
pursuing an aggressive vision of Maven enhancements, this may cause the 
PMC to become an unacceptable bottleneck and the fork will become the 
most active version and may start to attract more of the community.

>
>  About growing the PMC, I suppose we're looping here ;-). IIUC, again, 
> I think the point is precisely to define those values/rules to be able 
> to induct more serenely new PMC members while asking them to adhere to 
> those definitions.
>

I think that, so far, this idea has not found much favour with the 
broader community.
I am not sure how you get someone to promise not to undertake 
enhancements that result in too much code or add too much functionality.

The actual wording of the proposed litmus test only indirectly addressed 
this and seemed to be an attempt to codify a personality conflict with 
rules that would hurt the long-term viability of the project by 
replacing innovation with the group-think of an inner clique.
It also seemed to go against the principle of open source.
At least, that was the way it appeared to me as a community member 
outside the PMC.


Ron

> Cheers


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

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)

[Baptiste MATHUS <ml...@batmat.net>]

2013/8/2 Ron Wheeler <rw...@artifact-software.com>

> On 01/08/2013 5:55 PM, Jonathan Sharp wrote:
>
>> I think John C raises an interesting case here, where the voting process
>> can fall down.
>>
>> A large code dump like that can hurt the quality of documentation and
>> support (in addition to team morale).
>>
> It depends on how good the code and documentation is!
> If the PMC can not deal with the amount of code being proposed, they need
> to increase the PMC.
> In the meantime, they can always defer the acceptance.
>
> I would love to have the problem of my team producing too much tested code
> and documentation for me to read!!!


That's the point, not really talking of "your team" here. The (somehow a
bit hypothetic, granted) point raised here is where you would find yourself
in front of say one year of coding being proposed. And IIUC, we're only
talking about *PMC members* and values here. Sure, one company/individual
could work on his fork and propose a lot of changes later when he finally
wants/is allowed to, and btw he hasn't any direct commit access to the
project and so on.

 About growing the PMC, I suppose we're looping here ;-). IIUC, again, I
think the point is precisely to define those values/rules to be able to
induct more serenely new PMC members while asking them to adhere to those
definitions.

Cheers

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)

[Ron Wheeler <rw...@artifact-software.com>]

On 01/08/2013 5:55 PM, Jonathan Sharp wrote:
> I think John C raises an interesting case here, where the voting process
> can fall down.
>
> A large code dump like that can hurt the quality of documentation and
> support (in addition to team morale).
It depends on how good the code and documentation is!
If the PMC can not deal with the amount of code being proposed, they 
need to increase the PMC.
In the meantime, they can always defer the acceptance.

I would love to have the problem of my team producing too much tested 
code and documentation for me to read!!!

Ron

>
> My $.02
>
> Jon
>
> On Thu, Jul 25, 2013 at 2:36 PM, John Casey <jd...@commonjava.org> wrote:
>
>> It's about whether you expect to do a ton of work outside the community
>> here, outside the commit logs and the review, in order to avoid the
>> discussion and potential for veto.
>>
>> Working in this way opens the possibility for changing the rules for who
>> gets to contribute, especially when code diverges for long periods then
>> gets reconciled with a massive rebase.
>>
>> ASF is supposed to be about more than code. We're supposed to be working
>> together on this project. I feel like the above hamstrings that whole
>> process.
>>
>>


-- 
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

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)

[Jonathan Sharp <fo...@gmail.com>]

I think John C raises an interesting case here, where the voting process
can fall down.

A large code dump like that can hurt the quality of documentation and
support (in addition to team morale).

My $.02

Jon

On Thu, Jul 25, 2013 at 2:36 PM, John Casey <jd...@commonjava.org> wrote:

>
> It's about whether you expect to do a ton of work outside the community
> here, outside the commit logs and the review, in order to avoid the
> discussion and potential for veto.
>
> Working in this way opens the possibility for changing the rules for who
> gets to contribute, especially when code diverges for long periods then
> gets reconciled with a massive rebase.
>
> ASF is supposed to be about more than code. We're supposed to be working
> together on this project. I feel like the above hamstrings that whole
> process.
>
>

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)

[Ron Wheeler <rw...@artifact-software.com>]

Maven is open source and anyone can do whatever they want with it.
That is the whole point of the Apache license.

If the code splits off and a new open source product emerges that is 
better than Maven, then we all win.
To prevent this, the Maven PMC has to make the right choices about the 
Maven roadmap and make sure that the committers see a vision that they 
regard as worth devoting time to.

If the code splits off and a commercial product emerges, how does that 
affect Maven? Why would it be better if the person was not on the PMC?

If the code splits and the PMC was right about the proper strategy, the 
fork will die a natural death or become a niche solution which may take 
pressure of the Maven PMC to handle special cases that are not important 
to the main user community.

The people who want to pursue a fork will do that anyway so whether they 
stay in the PMC or do not, makes no difference to the Maven team.

The wider community will go with the better package so the Maven PMC has 
to make good choices.

Ron


On 25/07/2013 5:55 PM, Paul Benedict wrote:
> Agreed. I'll tip my hand and give my opinion: PMC members should have an
> "Apache first" mentality. They are gatekeepers and guardians of their
> project. Spinning off critical code to other OSS organizations should be
> frowned upon -- it splits the development and wider community into smaller
> pieces.
>
> NB: My original response was just criticism of the commitment wording. It's
> nice to say what commitments PMC members should have, but if there's no way
> to enforce it, it puts into question why the commitments are even expected.
> AFAIK, merit at Apache is forever -- you can't have it undone. If someone
> loses their "Apache first" spirit and begins critical development
> elsewhere, what can be done about it? Are there any practical recourses? I
> don't think there is which is why Maven development has that problem today.
>
>
>
> On Thu, Jul 25, 2013 at 4:36 PM, John Casey <jd...@commonjava.org> wrote:
>
>> On 7/25/13 4:17 PM, Paul Benedict wrote:
>>
>>> Stephen, those are great questions. Yet, I think these questions are
>>> riding
>>> an assumption that PMC members are solely volunteering at Apache, because
>>> the emphasis (as I interpret your words) is to place the Apache project
>>> first/above other external contributions. Isn't that the heart of this
>>> debate? A person who solely contributes to Apache and no other OS
>>> organizations has no divided loyalties -- they do all their work here. But
>>> what happens when contributions are here and elsewhere? I ask
>>> rhetorically,
>>> to solicit answers, of course... and I see where this is going and what
>>> historical processes within Maven are being addressed.
>>>
>>
>> I don't think it's about whether you contribute elsewhere or not. It's
>> about whether you expect to do a ton of work outside the community here,
>> outside the commit logs and the review, in order to avoid the discussion
>> and potential for veto.
>>
>> Working in this way opens the possibility for changing the rules for who
>> gets to contribute, especially when code diverges for long periods then
>> gets reconciled with a massive rebase.
>>
>> ASF is supposed to be about more than code. We're supposed to be working
>> together on this project. I feel like the above hamstrings that whole
>> process.
>>
>> And note: I'm only suggesting that the PMC - who is supposed to have the
>> long-term interests of *this* project at heart - be held to a higher
>> standard, to provide an example for the rest of the project. This is not
>> saying you're stuck working solely within Maven just because you're on the
>> PMC; it's saying that you should promote the health of the community by
>> making sure the processes in place work as well as possible.
>>
>> ASF membership is supposed to be reserved for those who "get" the Apache
>> Way, and I've heard it said that PMC membership should imply ASF
>> membership. IMO, working for extended periods outside of the venues for our
>> community is not consistent with having the best interests of this project
>> in mind.
>>
>>
>>
>>> On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly <
>>> stephen.alan.connolly@gmail.**com <st...@gmail.com>>
>>> wrote:
>>>
>>>   Perhaps we could reframe the question a little then (as people seem to be
>>>> testing hung up on the committed wording)...
>>>>
>>>> Should the PMC encourage people experimenting on new improvements to
>>>> Maven
>>>> to do that work at the ASF? And if so, should they then practice what
>>>> they
>>>> preach, and ensure that any experiments with Maven take place on the ASF
>>>> SCM servers (at least once such experiments become semi-serious or
>>>> progress
>>>> enough not to cause egg-on-face syndrome)?
>>>>
>>>> Shoud the PMC promote other Apache projects, or moving non-Apache
>>>> projects
>>>> to Apache? (Right now, to work on an issue in core and effect the change
>>>> yourself you may need to establish merit with: Apache Maven, Eclipse
>>>> Sisu,
>>>> Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
>>>> fine with half of these at Eclipse and the ther half here... Or maybe
>>>> not... But that is a lot of projects where you need to establish merit
>>>> and
>>>> perhaps maintain merit just to be able to commit directly (which
>>>> sometimes
>>>> is the only way to effect the type of cross system changes that some of
>>>> our
>>>> more obscure bugs may require... GIT makes this less of a requirement, as
>>>> patches on SVN are a PITA, though) )
>>>>
>>>> These types of questions need resolution as they will, further down the
>>>> road, rise up again and cause wounds... Eg logback vs log4j2 is one that
>>>> simmers at the edge (any time anyone mentioned coloured loggers)
>>>>
>>>> -Stephen
>>>>
>>>> On Thursday, 25 July 2013, Paul Benedict wrote:
>>>>
>>>>   I don't think it is possible to force volunteer efforts and/or limit
>>>>> development elsewhere. The idea of supporting a project is a vague
>>>>>
>>>> notion.
>>>>
>>>>> I have my opinions too but this language is clearly unenforceable and
>>>>> impractical.
>>>>>
>>>>> Cheers,
>>>>> Paul
>>>>>
>>>>>
>>>>> On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
>>>>>
>>>>>   As a Maven user I think that everybody who is working on a project
>>>>> should
>>>>> behave the same. Hence, I would say, PMC members should rather
>>>>> certainly
>>>>> demonstrate how to live the community rules.
>>>>>> -----Ursprüngliche Nachricht-----
>>>>>> Von: Stephen Connolly [mailto:stephen.alan.connolly@**gmail.com<st...@gmail.com>
>>>>>> ]
>>>>>> Gesendet: Donnerstag, 25. Juli 2013 15:16
>>>>>> An: Maven Users List; Maven Developers List
>>>>>> Betreff: [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)
>>>>>>
>>>>>> 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<http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project>
>>>>
>>>>> -roles.md?rev=1506778&r1=**1506777&r2=1506778&view=diff<http://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 he> To unsubscribe, e-mail:
>>>>>>>
>>>>>> dev-unsubscribe@maven.apache.**org <de...@maven.apache.org><javascript:;>
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>> <javascript:;>
>>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Paul
>>>>>
>>>>>
>>>> --
>>>> Sent from my phone
>>>>
>>>>
>>>
>>>
>> --
>> John Casey
>> GitHub - http://github.com/jdcasey
>>
>
>


-- 
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

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)

[Paul Benedict <pb...@apache.org>]

Wayne, that is true. Personally, I am only aware of one guy who ever got
booted. His problem was using the ASF trademark in his own services and
refusing to back down. Because it was a trademark issue, the ASF Board
stepped in and did its thing. The Maven project doesn't have any egregious
issues like that. As it is, the Board doesn't get involved in project
politics so there's really no recourse to reign in undesirable community
choices by PMC members. The project has to solve those issues through their
own deliberations.

Paul


On Thu, Jul 25, 2013 at 7:12 PM, Wayne Fay <wa...@gmail.com> wrote:

> >> AFAIK, merit at Apache is forever -- you can't have it undone. If
> someone
> >> loses their "Apache first" spirit and begins critical development
> >> elsewhere, what can be done about it? Are there any practical
> recourses? I
> >> don't think there is which is why Maven development has that problem
> today.
> >
> > Surely the PMC can vote to remove individuals from the PMC if necessary?
>
> They *can* but it rarely occurs for a whole host of reasons...
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
Cheers,
Paul

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)

[Wayne Fay <wa...@gmail.com>]

>> AFAIK, merit at Apache is forever -- you can't have it undone. If someone
>> loses their "Apache first" spirit and begins critical development
>> elsewhere, what can be done about it? Are there any practical recourses? I
>> don't think there is which is why Maven development has that problem today.
>
> Surely the PMC can vote to remove individuals from the PMC if necessary?

They *can* but it rarely occurs for a whole host of reasons...

Wayne

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

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)

[sebb <se...@gmail.com>]

On 25 July 2013 22:55, Paul Benedict <pb...@apache.org> wrote:
> Agreed. I'll tip my hand and give my opinion: PMC members should have an
> "Apache first" mentality. They are gatekeepers and guardians of their
> project. Spinning off critical code to other OSS organizations should be
> frowned upon -- it splits the development and wider community into smaller
> pieces.

+1

> NB: My original response was just criticism of the commitment wording. It's
> nice to say what commitments PMC members should have, but if there's no way
> to enforce it, it puts into question why the commitments are even expected.
> AFAIK, merit at Apache is forever -- you can't have it undone. If someone
> loses their "Apache first" spirit and begins critical development
> elsewhere, what can be done about it? Are there any practical recourses? I
> don't think there is which is why Maven development has that problem today.

Surely the PMC can vote to remove individuals from the PMC if necessary?

If the PMC as a whole agrees to a particular code of conduct, then
anyone who does not conform should be politely reminded (on the
private@ list) of their responsibilities. Only if the non-conforming
behaviour persists should further action be taken.

>
>
> On Thu, Jul 25, 2013 at 4:36 PM, John Casey <jd...@commonjava.org> wrote:
>
>> On 7/25/13 4:17 PM, Paul Benedict wrote:
>>
>>> Stephen, those are great questions. Yet, I think these questions are
>>> riding
>>> an assumption that PMC members are solely volunteering at Apache, because
>>> the emphasis (as I interpret your words) is to place the Apache project
>>> first/above other external contributions. Isn't that the heart of this
>>> debate? A person who solely contributes to Apache and no other OS
>>> organizations has no divided loyalties -- they do all their work here. But
>>> what happens when contributions are here and elsewhere? I ask
>>> rhetorically,
>>> to solicit answers, of course... and I see where this is going and what
>>> historical processes within Maven are being addressed.
>>>
>>
>>
>> I don't think it's about whether you contribute elsewhere or not. It's
>> about whether you expect to do a ton of work outside the community here,
>> outside the commit logs and the review, in order to avoid the discussion
>> and potential for veto.
>>
>> Working in this way opens the possibility for changing the rules for who
>> gets to contribute, especially when code diverges for long periods then
>> gets reconciled with a massive rebase.
>>
>> ASF is supposed to be about more than code. We're supposed to be working
>> together on this project. I feel like the above hamstrings that whole
>> process.
>>
>> And note: I'm only suggesting that the PMC - who is supposed to have the
>> long-term interests of *this* project at heart - be held to a higher
>> standard, to provide an example for the rest of the project. This is not
>> saying you're stuck working solely within Maven just because you're on the
>> PMC; it's saying that you should promote the health of the community by
>> making sure the processes in place work as well as possible.
>>
>> ASF membership is supposed to be reserved for those who "get" the Apache
>> Way, and I've heard it said that PMC membership should imply ASF
>> membership. IMO, working for extended periods outside of the venues for our
>> community is not consistent with having the best interests of this project
>> in mind.
>>
>>
>>
>>>
>>> On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly <
>>> stephen.alan.connolly@gmail.**com <st...@gmail.com>>
>>> wrote:
>>>
>>>  Perhaps we could reframe the question a little then (as people seem to be
>>>> testing hung up on the committed wording)...
>>>>
>>>> Should the PMC encourage people experimenting on new improvements to
>>>> Maven
>>>> to do that work at the ASF? And if so, should they then practice what
>>>> they
>>>> preach, and ensure that any experiments with Maven take place on the ASF
>>>> SCM servers (at least once such experiments become semi-serious or
>>>> progress
>>>> enough not to cause egg-on-face syndrome)?
>>>>
>>>> Shoud the PMC promote other Apache projects, or moving non-Apache
>>>> projects
>>>> to Apache? (Right now, to work on an issue in core and effect the change
>>>> yourself you may need to establish merit with: Apache Maven, Eclipse
>>>> Sisu,
>>>> Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
>>>> fine with half of these at Eclipse and the ther half here... Or maybe
>>>> not... But that is a lot of projects where you need to establish merit
>>>> and
>>>> perhaps maintain merit just to be able to commit directly (which
>>>> sometimes
>>>> is the only way to effect the type of cross system changes that some of
>>>> our
>>>> more obscure bugs may require... GIT makes this less of a requirement, as
>>>> patches on SVN are a PITA, though) )
>>>>
>>>> These types of questions need resolution as they will, further down the
>>>> road, rise up again and cause wounds... Eg logback vs log4j2 is one that
>>>> simmers at the edge (any time anyone mentioned coloured loggers)
>>>>
>>>> -Stephen
>>>>
>>>> On Thursday, 25 July 2013, Paul Benedict wrote:
>>>>
>>>>  I don't think it is possible to force volunteer efforts and/or limit
>>>>> development elsewhere. The idea of supporting a project is a vague
>>>>>
>>>> notion.
>>>>
>>>>> I have my opinions too but this language is clearly unenforceable and
>>>>> impractical.
>>>>>
>>>>> Cheers,
>>>>> Paul
>>>>>
>>>>>
>>>>> On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
>>>>>
>>>>>  As a Maven user I think that everybody who is working on a project
>>>>>>
>>>>> should
>>>>
>>>>> behave the same. Hence, I would say, PMC members should rather
>>>>>>
>>>>> certainly
>>>>
>>>>> demonstrate how to live the community rules.
>>>>>>
>>>>>> -----Ursprüngliche Nachricht-----
>>>>>> Von: Stephen Connolly [mailto:stephen.alan.connolly@**gmail.com<st...@gmail.com>
>>>>>> ]
>>>>>> Gesendet: Donnerstag, 25. Juli 2013 15:16
>>>>>> An: Maven Users List; Maven Developers List
>>>>>> Betreff: [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)
>>>>>>
>>>>>> 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<http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project>
>>>>
>>>>> -roles.md?rev=1506778&r1=**1506777&r2=1506778&view=diff<http://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 he> To unsubscribe, e-mail:
>>>>>>>
>>>>>> dev-unsubscribe@maven.apache.**org <de...@maven.apache.org><javascript:;>
>>>>>
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>> <javascript:;>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Paul
>>>>>
>>>>>
>>>>
>>>> --
>>>> Sent from my phone
>>>>
>>>>
>>>
>>>
>>>
>>
>> --
>> John Casey
>> GitHub - http://github.com/jdcasey
>>
>
>
>
> --
> Cheers,
> Paul

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

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)

[Martin Gainty <mg...@hotmail.com>]

Private Sector Usage of Apache code:
Sonatype is the second organization (that I know of) to leverage existing ASF code to engage Paying Customers
In last 10 years Paul F (dba WS02) leveraged the entire axis project for "Customised SAAS Solutions for HealthCare as well as Financial Services" 
WS02's contributions of features and functions  were merged back in to axis code base..
Also WS02 employees constituted +50% effort for re-architecture from Axis1 to Axis2
(quite similar to the way Sonatype contributes Architecture, Doc and code back to Maven)

Subsidising ASF volunteer efforts:
As some of us age and when (and if) the government pittance starts to kick in (hopefully BEFORE Govt pittance money runs out)
I would expect even greater Apache participation by those committers on bugfixes, support, documentation as well as fix and testing new features and functions
 
Social Media:
Someone mentioned the freshest maven committers *should*  maintain feeds to/from Social Media 
I could see support updates to twitter (with some manner of RSS feed?)
not sure if support feeds are happening now to Twitter or another provider ?

Architecture changes should be contributed to existing arch doc .
Resulting architecture doc updates to Social Media avenues *could* possibly be somehow uploaded to Facebook
 
Does Maven have a facebook account?
 
My 2 cents,
Martin 
______________________________________________ 



 
> Date: Thu, 25 Jul 2013 16:55:39 -0500
> 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)
> From: pbenedict@apache.org
> To: jdcasey@commonjava.org; stephen.alan.connolly@gmail.com
> CC: dev@maven.apache.org; users@maven.apache.org
> 
> Agreed. I'll tip my hand and give my opinion: PMC members should have an
> "Apache first" mentality. They are gatekeepers and guardians of their
> project. Spinning off critical code to other OSS organizations should be
> frowned upon -- it splits the development and wider community into smaller
> pieces.
> 
> NB: My original response was just criticism of the commitment wording. It's
> nice to say what commitments PMC members should have, but if there's no way
> to enforce it, it puts into question why the commitments are even expected.
> AFAIK, merit at Apache is forever -- you can't have it undone. If someone
> loses their "Apache first" spirit and begins critical development
> elsewhere, what can be done about it? Are there any practical recourses? I
> don't think there is which is why Maven development has that problem today.
> 
> 
> 
> On Thu, Jul 25, 2013 at 4:36 PM, John Casey <jd...@commonjava.org> wrote:
> 
> > On 7/25/13 4:17 PM, Paul Benedict wrote:
> >
> >> Stephen, those are great questions. Yet, I think these questions are
> >> riding
> >> an assumption that PMC members are solely volunteering at Apache, because
> >> the emphasis (as I interpret your words) is to place the Apache project
> >> first/above other external contributions. Isn't that the heart of this
> >> debate? A person who solely contributes to Apache and no other OS
> >> organizations has no divided loyalties -- they do all their work here. But
> >> what happens when contributions are here and elsewhere? I ask
> >> rhetorically,
> >> to solicit answers, of course... and I see where this is going and what
> >> historical processes within Maven are being addressed.
> >>
> >
> >
> > I don't think it's about whether you contribute elsewhere or not. It's
> > about whether you expect to do a ton of work outside the community here,
> > outside the commit logs and the review, in order to avoid the discussion
> > and potential for veto.
> >
> > Working in this way opens the possibility for changing the rules for who
> > gets to contribute, especially when code diverges for long periods then
> > gets reconciled with a massive rebase.
> >
> > ASF is supposed to be about more than code. We're supposed to be working
> > together on this project. I feel like the above hamstrings that whole
> > process.
> >
> > And note: I'm only suggesting that the PMC - who is supposed to have the
> > long-term interests of *this* project at heart - be held to a higher
> > standard, to provide an example for the rest of the project. This is not
> > saying you're stuck working solely within Maven just because you're on the
> > PMC; it's saying that you should promote the health of the community by
> > making sure the processes in place work as well as possible.
> >
> > ASF membership is supposed to be reserved for those who "get" the Apache
> > Way, and I've heard it said that PMC membership should imply ASF
> > membership. IMO, working for extended periods outside of the venues for our
> > community is not consistent with having the best interests of this project
> > in mind.
> >
> >
> >
> >>
> >> On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly <
> >> stephen.alan.connolly@gmail.**com <st...@gmail.com>>
> >> wrote:
> >>
> >>  Perhaps we could reframe the question a little then (as people seem to be
> >>> testing hung up on the committed wording)...
> >>>
> >>> Should the PMC encourage people experimenting on new improvements to
> >>> Maven
> >>> to do that work at the ASF? And if so, should they then practice what
> >>> they
> >>> preach, and ensure that any experiments with Maven take place on the ASF
> >>> SCM servers (at least once such experiments become semi-serious or
> >>> progress
> >>> enough not to cause egg-on-face syndrome)?
> >>>
> >>> Shoud the PMC promote other Apache projects, or moving non-Apache
> >>> projects
> >>> to Apache? (Right now, to work on an issue in core and effect the change
> >>> yourself you may need to establish merit with: Apache Maven, Eclipse
> >>> Sisu,
> >>> Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
> >>> fine with half of these at Eclipse and the ther half here... Or maybe
> >>> not... But that is a lot of projects where you need to establish merit
> >>> and
> >>> perhaps maintain merit just to be able to commit directly (which
> >>> sometimes
> >>> is the only way to effect the type of cross system changes that some of
> >>> our
> >>> more obscure bugs may require... GIT makes this less of a requirement, as
> >>> patches on SVN are a PITA, though) )
> >>>
> >>> These types of questions need resolution as they will, further down the
> >>> road, rise up again and cause wounds... Eg logback vs log4j2 is one that
> >>> simmers at the edge (any time anyone mentioned coloured loggers)
> >>>
> >>> -Stephen
> >>>
> >>> On Thursday, 25 July 2013, Paul Benedict wrote:
> >>>
> >>>  I don't think it is possible to force volunteer efforts and/or limit
> >>>> development elsewhere. The idea of supporting a project is a vague
> >>>>
> >>> notion.
> >>>
> >>>> I have my opinions too but this language is clearly unenforceable and
> >>>> impractical.
> >>>>
> >>>> Cheers,
> >>>> Paul
> >>>>
> >>>>
> >>>> On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
> >>>>
> >>>>  As a Maven user I think that everybody who is working on a project
> >>>>>
> >>>> should
> >>>
> >>>> behave the same. Hence, I would say, PMC members should rather
> >>>>>
> >>>> certainly
> >>>
> >>>> demonstrate how to live the community rules.
> >>>>>
> >>>>> -----Ursprüngliche Nachricht-----
> >>>>> Von: Stephen Connolly [mailto:stephen.alan.connolly@**gmail.com<st...@gmail.com>
> >>>>> ]
> >>>>> Gesendet: Donnerstag, 25. Juli 2013 15:16
> >>>>> An: Maven Users List; Maven Developers List
> >>>>> Betreff: [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)
> >>>>>
> >>>>> 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<http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project>
> >>>
> >>>> -roles.md?rev=1506778&r1=**1506777&r2=1506778&view=diff<http://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 he> To unsubscribe, e-mail:
> >>>>>>
> >>>>> dev-unsubscribe@maven.apache.**org <de...@maven.apache.org><javascript:;>
> >>>>
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>> <javascript:;>
> >>>
> >>>>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Cheers,
> >>>> Paul
> >>>>
> >>>>
> >>>
> >>> --
> >>> Sent from my phone
> >>>
> >>>
> >>
> >>
> >>
> >
> > --
> > John Casey
> > GitHub - http://github.com/jdcasey
> >
> 
> 
> 
> -- 
> Cheers,
> Paul
 		 	   		  

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)

[Paul Benedict <pb...@apache.org>]

Agreed. I'll tip my hand and give my opinion: PMC members should have an
"Apache first" mentality. They are gatekeepers and guardians of their
project. Spinning off critical code to other OSS organizations should be
frowned upon -- it splits the development and wider community into smaller
pieces.

NB: My original response was just criticism of the commitment wording. It's
nice to say what commitments PMC members should have, but if there's no way
to enforce it, it puts into question why the commitments are even expected.
AFAIK, merit at Apache is forever -- you can't have it undone. If someone
loses their "Apache first" spirit and begins critical development
elsewhere, what can be done about it? Are there any practical recourses? I
don't think there is which is why Maven development has that problem today.



On Thu, Jul 25, 2013 at 4:36 PM, John Casey <jd...@commonjava.org> wrote:

> On 7/25/13 4:17 PM, Paul Benedict wrote:
>
>> Stephen, those are great questions. Yet, I think these questions are
>> riding
>> an assumption that PMC members are solely volunteering at Apache, because
>> the emphasis (as I interpret your words) is to place the Apache project
>> first/above other external contributions. Isn't that the heart of this
>> debate? A person who solely contributes to Apache and no other OS
>> organizations has no divided loyalties -- they do all their work here. But
>> what happens when contributions are here and elsewhere? I ask
>> rhetorically,
>> to solicit answers, of course... and I see where this is going and what
>> historical processes within Maven are being addressed.
>>
>
>
> I don't think it's about whether you contribute elsewhere or not. It's
> about whether you expect to do a ton of work outside the community here,
> outside the commit logs and the review, in order to avoid the discussion
> and potential for veto.
>
> Working in this way opens the possibility for changing the rules for who
> gets to contribute, especially when code diverges for long periods then
> gets reconciled with a massive rebase.
>
> ASF is supposed to be about more than code. We're supposed to be working
> together on this project. I feel like the above hamstrings that whole
> process.
>
> And note: I'm only suggesting that the PMC - who is supposed to have the
> long-term interests of *this* project at heart - be held to a higher
> standard, to provide an example for the rest of the project. This is not
> saying you're stuck working solely within Maven just because you're on the
> PMC; it's saying that you should promote the health of the community by
> making sure the processes in place work as well as possible.
>
> ASF membership is supposed to be reserved for those who "get" the Apache
> Way, and I've heard it said that PMC membership should imply ASF
> membership. IMO, working for extended periods outside of the venues for our
> community is not consistent with having the best interests of this project
> in mind.
>
>
>
>>
>> On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly <
>> stephen.alan.connolly@gmail.**com <st...@gmail.com>>
>> wrote:
>>
>>  Perhaps we could reframe the question a little then (as people seem to be
>>> testing hung up on the committed wording)...
>>>
>>> Should the PMC encourage people experimenting on new improvements to
>>> Maven
>>> to do that work at the ASF? And if so, should they then practice what
>>> they
>>> preach, and ensure that any experiments with Maven take place on the ASF
>>> SCM servers (at least once such experiments become semi-serious or
>>> progress
>>> enough not to cause egg-on-face syndrome)?
>>>
>>> Shoud the PMC promote other Apache projects, or moving non-Apache
>>> projects
>>> to Apache? (Right now, to work on an issue in core and effect the change
>>> yourself you may need to establish merit with: Apache Maven, Eclipse
>>> Sisu,
>>> Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
>>> fine with half of these at Eclipse and the ther half here... Or maybe
>>> not... But that is a lot of projects where you need to establish merit
>>> and
>>> perhaps maintain merit just to be able to commit directly (which
>>> sometimes
>>> is the only way to effect the type of cross system changes that some of
>>> our
>>> more obscure bugs may require... GIT makes this less of a requirement, as
>>> patches on SVN are a PITA, though) )
>>>
>>> These types of questions need resolution as they will, further down the
>>> road, rise up again and cause wounds... Eg logback vs log4j2 is one that
>>> simmers at the edge (any time anyone mentioned coloured loggers)
>>>
>>> -Stephen
>>>
>>> On Thursday, 25 July 2013, Paul Benedict wrote:
>>>
>>>  I don't think it is possible to force volunteer efforts and/or limit
>>>> development elsewhere. The idea of supporting a project is a vague
>>>>
>>> notion.
>>>
>>>> I have my opinions too but this language is clearly unenforceable and
>>>> impractical.
>>>>
>>>> Cheers,
>>>> Paul
>>>>
>>>>
>>>> On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
>>>>
>>>>  As a Maven user I think that everybody who is working on a project
>>>>>
>>>> should
>>>
>>>> behave the same. Hence, I would say, PMC members should rather
>>>>>
>>>> certainly
>>>
>>>> demonstrate how to live the community rules.
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> Von: Stephen Connolly [mailto:stephen.alan.connolly@**gmail.com<st...@gmail.com>
>>>>> ]
>>>>> Gesendet: Donnerstag, 25. Juli 2013 15:16
>>>>> An: Maven Users List; Maven Developers List
>>>>> Betreff: [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)
>>>>>
>>>>> 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<http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project>
>>>
>>>> -roles.md?rev=1506778&r1=**1506777&r2=1506778&view=diff<http://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 he> To unsubscribe, e-mail:
>>>>>>
>>>>> dev-unsubscribe@maven.apache.**org <de...@maven.apache.org><javascript:;>
>>>>
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>> <javascript:;>
>>>
>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Paul
>>>>
>>>>
>>>
>>> --
>>> Sent from my phone
>>>
>>>
>>
>>
>>
>
> --
> John Casey
> GitHub - http://github.com/jdcasey
>



-- 
Cheers,
Paul

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)

[Paul Benedict <pb...@apache.org>]

Agreed. I'll tip my hand and give my opinion: PMC members should have an
"Apache first" mentality. They are gatekeepers and guardians of their
project. Spinning off critical code to other OSS organizations should be
frowned upon -- it splits the development and wider community into smaller
pieces.

NB: My original response was just criticism of the commitment wording. It's
nice to say what commitments PMC members should have, but if there's no way
to enforce it, it puts into question why the commitments are even expected.
AFAIK, merit at Apache is forever -- you can't have it undone. If someone
loses their "Apache first" spirit and begins critical development
elsewhere, what can be done about it? Are there any practical recourses? I
don't think there is which is why Maven development has that problem today.



On Thu, Jul 25, 2013 at 4:36 PM, John Casey <jd...@commonjava.org> wrote:

> On 7/25/13 4:17 PM, Paul Benedict wrote:
>
>> Stephen, those are great questions. Yet, I think these questions are
>> riding
>> an assumption that PMC members are solely volunteering at Apache, because
>> the emphasis (as I interpret your words) is to place the Apache project
>> first/above other external contributions. Isn't that the heart of this
>> debate? A person who solely contributes to Apache and no other OS
>> organizations has no divided loyalties -- they do all their work here. But
>> what happens when contributions are here and elsewhere? I ask
>> rhetorically,
>> to solicit answers, of course... and I see where this is going and what
>> historical processes within Maven are being addressed.
>>
>
>
> I don't think it's about whether you contribute elsewhere or not. It's
> about whether you expect to do a ton of work outside the community here,
> outside the commit logs and the review, in order to avoid the discussion
> and potential for veto.
>
> Working in this way opens the possibility for changing the rules for who
> gets to contribute, especially when code diverges for long periods then
> gets reconciled with a massive rebase.
>
> ASF is supposed to be about more than code. We're supposed to be working
> together on this project. I feel like the above hamstrings that whole
> process.
>
> And note: I'm only suggesting that the PMC - who is supposed to have the
> long-term interests of *this* project at heart - be held to a higher
> standard, to provide an example for the rest of the project. This is not
> saying you're stuck working solely within Maven just because you're on the
> PMC; it's saying that you should promote the health of the community by
> making sure the processes in place work as well as possible.
>
> ASF membership is supposed to be reserved for those who "get" the Apache
> Way, and I've heard it said that PMC membership should imply ASF
> membership. IMO, working for extended periods outside of the venues for our
> community is not consistent with having the best interests of this project
> in mind.
>
>
>
>>
>> On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly <
>> stephen.alan.connolly@gmail.**com <st...@gmail.com>>
>> wrote:
>>
>>  Perhaps we could reframe the question a little then (as people seem to be
>>> testing hung up on the committed wording)...
>>>
>>> Should the PMC encourage people experimenting on new improvements to
>>> Maven
>>> to do that work at the ASF? And if so, should they then practice what
>>> they
>>> preach, and ensure that any experiments with Maven take place on the ASF
>>> SCM servers (at least once such experiments become semi-serious or
>>> progress
>>> enough not to cause egg-on-face syndrome)?
>>>
>>> Shoud the PMC promote other Apache projects, or moving non-Apache
>>> projects
>>> to Apache? (Right now, to work on an issue in core and effect the change
>>> yourself you may need to establish merit with: Apache Maven, Eclipse
>>> Sisu,
>>> Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
>>> fine with half of these at Eclipse and the ther half here... Or maybe
>>> not... But that is a lot of projects where you need to establish merit
>>> and
>>> perhaps maintain merit just to be able to commit directly (which
>>> sometimes
>>> is the only way to effect the type of cross system changes that some of
>>> our
>>> more obscure bugs may require... GIT makes this less of a requirement, as
>>> patches on SVN are a PITA, though) )
>>>
>>> These types of questions need resolution as they will, further down the
>>> road, rise up again and cause wounds... Eg logback vs log4j2 is one that
>>> simmers at the edge (any time anyone mentioned coloured loggers)
>>>
>>> -Stephen
>>>
>>> On Thursday, 25 July 2013, Paul Benedict wrote:
>>>
>>>  I don't think it is possible to force volunteer efforts and/or limit
>>>> development elsewhere. The idea of supporting a project is a vague
>>>>
>>> notion.
>>>
>>>> I have my opinions too but this language is clearly unenforceable and
>>>> impractical.
>>>>
>>>> Cheers,
>>>> Paul
>>>>
>>>>
>>>> On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
>>>>
>>>>  As a Maven user I think that everybody who is working on a project
>>>>>
>>>> should
>>>
>>>> behave the same. Hence, I would say, PMC members should rather
>>>>>
>>>> certainly
>>>
>>>> demonstrate how to live the community rules.
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> Von: Stephen Connolly [mailto:stephen.alan.connolly@**gmail.com<st...@gmail.com>
>>>>> ]
>>>>> Gesendet: Donnerstag, 25. Juli 2013 15:16
>>>>> An: Maven Users List; Maven Developers List
>>>>> Betreff: [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)
>>>>>
>>>>> 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<http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project>
>>>
>>>> -roles.md?rev=1506778&r1=**1506777&r2=1506778&view=diff<http://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 he> To unsubscribe, e-mail:
>>>>>>
>>>>> dev-unsubscribe@maven.apache.**org <de...@maven.apache.org><javascript:;>
>>>>
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>> <javascript:;>
>>>
>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Paul
>>>>
>>>>
>>>
>>> --
>>> Sent from my phone
>>>
>>>
>>
>>
>>
>
> --
> John Casey
> GitHub - http://github.com/jdcasey
>



-- 
Cheers,
Paul

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)

[John Casey <jd...@commonjava.org>]

On 7/25/13 4:17 PM, Paul Benedict wrote:
> Stephen, those are great questions. Yet, I think these questions are riding
> an assumption that PMC members are solely volunteering at Apache, because
> the emphasis (as I interpret your words) is to place the Apache project
> first/above other external contributions. Isn't that the heart of this
> debate? A person who solely contributes to Apache and no other OS
> organizations has no divided loyalties -- they do all their work here. But
> what happens when contributions are here and elsewhere? I ask rhetorically,
> to solicit answers, of course... and I see where this is going and what
> historical processes within Maven are being addressed.


I don't think it's about whether you contribute elsewhere or not. It's 
about whether you expect to do a ton of work outside the community here, 
outside the commit logs and the review, in order to avoid the discussion 
and potential for veto.

Working in this way opens the possibility for changing the rules for who 
gets to contribute, especially when code diverges for long periods then 
gets reconciled with a massive rebase.

ASF is supposed to be about more than code. We're supposed to be working 
together on this project. I feel like the above hamstrings that whole 
process.

And note: I'm only suggesting that the PMC - who is supposed to have the 
long-term interests of *this* project at heart - be held to a higher 
standard, to provide an example for the rest of the project. This is not 
saying you're stuck working solely within Maven just because you're on 
the PMC; it's saying that you should promote the health of the community 
by making sure the processes in place work as well as possible.

ASF membership is supposed to be reserved for those who "get" the Apache 
Way, and I've heard it said that PMC membership should imply ASF 
membership. IMO, working for extended periods outside of the venues for 
our community is not consistent with having the best interests of this 
project in mind.

>
>
> On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> Perhaps we could reframe the question a little then (as people seem to be
>> testing hung up on the committed wording)...
>>
>> Should the PMC encourage people experimenting on new improvements to Maven
>> to do that work at the ASF? And if so, should they then practice what they
>> preach, and ensure that any experiments with Maven take place on the ASF
>> SCM servers (at least once such experiments become semi-serious or progress
>> enough not to cause egg-on-face syndrome)?
>>
>> Shoud the PMC promote other Apache projects, or moving non-Apache projects
>> to Apache? (Right now, to work on an issue in core and effect the change
>> yourself you may need to establish merit with: Apache Maven, Eclipse Sisu,
>> Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
>> fine with half of these at Eclipse and the ther half here... Or maybe
>> not... But that is a lot of projects where you need to establish merit and
>> perhaps maintain merit just to be able to commit directly (which sometimes
>> is the only way to effect the type of cross system changes that some of our
>> more obscure bugs may require... GIT makes this less of a requirement, as
>> patches on SVN are a PITA, though) )
>>
>> These types of questions need resolution as they will, further down the
>> road, rise up again and cause wounds... Eg logback vs log4j2 is one that
>> simmers at the edge (any time anyone mentioned coloured loggers)
>>
>> -Stephen
>>
>> On Thursday, 25 July 2013, Paul Benedict wrote:
>>
>>> I don't think it is possible to force volunteer efforts and/or limit
>>> development elsewhere. The idea of supporting a project is a vague
>> notion.
>>> I have my opinions too but this language is clearly unenforceable and
>>> impractical.
>>>
>>> Cheers,
>>> Paul
>>>
>>>
>>> On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
>>>
>>>> As a Maven user I think that everybody who is working on a project
>> should
>>>> behave the same. Hence, I would say, PMC members should rather
>> certainly
>>>> demonstrate how to live the community rules.
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>>>> Gesendet: Donnerstag, 25. Juli 2013 15:16
>>>> An: Maven Users List; Maven Developers List
>>>> Betreff: [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)
>>>>
>>>> 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 he> To unsubscribe, e-mail:
>>> dev-unsubscribe@maven.apache.org <javascript:;>
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> <javascript:;>
>>>>
>>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Paul
>>>
>>
>>
>> --
>> Sent from my phone
>>
>
>
>


-- 
John Casey
GitHub - http://github.com/jdcasey

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

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)

[John Casey <jd...@commonjava.org>]

On 7/25/13 4:17 PM, Paul Benedict wrote:
> Stephen, those are great questions. Yet, I think these questions are riding
> an assumption that PMC members are solely volunteering at Apache, because
> the emphasis (as I interpret your words) is to place the Apache project
> first/above other external contributions. Isn't that the heart of this
> debate? A person who solely contributes to Apache and no other OS
> organizations has no divided loyalties -- they do all their work here. But
> what happens when contributions are here and elsewhere? I ask rhetorically,
> to solicit answers, of course... and I see where this is going and what
> historical processes within Maven are being addressed.


I don't think it's about whether you contribute elsewhere or not. It's 
about whether you expect to do a ton of work outside the community here, 
outside the commit logs and the review, in order to avoid the discussion 
and potential for veto.

Working in this way opens the possibility for changing the rules for who 
gets to contribute, especially when code diverges for long periods then 
gets reconciled with a massive rebase.

ASF is supposed to be about more than code. We're supposed to be working 
together on this project. I feel like the above hamstrings that whole 
process.

And note: I'm only suggesting that the PMC - who is supposed to have the 
long-term interests of *this* project at heart - be held to a higher 
standard, to provide an example for the rest of the project. This is not 
saying you're stuck working solely within Maven just because you're on 
the PMC; it's saying that you should promote the health of the community 
by making sure the processes in place work as well as possible.

ASF membership is supposed to be reserved for those who "get" the Apache 
Way, and I've heard it said that PMC membership should imply ASF 
membership. IMO, working for extended periods outside of the venues for 
our community is not consistent with having the best interests of this 
project in mind.

>
>
> On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> Perhaps we could reframe the question a little then (as people seem to be
>> testing hung up on the committed wording)...
>>
>> Should the PMC encourage people experimenting on new improvements to Maven
>> to do that work at the ASF? And if so, should they then practice what they
>> preach, and ensure that any experiments with Maven take place on the ASF
>> SCM servers (at least once such experiments become semi-serious or progress
>> enough not to cause egg-on-face syndrome)?
>>
>> Shoud the PMC promote other Apache projects, or moving non-Apache projects
>> to Apache? (Right now, to work on an issue in core and effect the change
>> yourself you may need to establish merit with: Apache Maven, Eclipse Sisu,
>> Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
>> fine with half of these at Eclipse and the ther half here... Or maybe
>> not... But that is a lot of projects where you need to establish merit and
>> perhaps maintain merit just to be able to commit directly (which sometimes
>> is the only way to effect the type of cross system changes that some of our
>> more obscure bugs may require... GIT makes this less of a requirement, as
>> patches on SVN are a PITA, though) )
>>
>> These types of questions need resolution as they will, further down the
>> road, rise up again and cause wounds... Eg logback vs log4j2 is one that
>> simmers at the edge (any time anyone mentioned coloured loggers)
>>
>> -Stephen
>>
>> On Thursday, 25 July 2013, Paul Benedict wrote:
>>
>>> I don't think it is possible to force volunteer efforts and/or limit
>>> development elsewhere. The idea of supporting a project is a vague
>> notion.
>>> I have my opinions too but this language is clearly unenforceable and
>>> impractical.
>>>
>>> Cheers,
>>> Paul
>>>
>>>
>>> On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
>>>
>>>> As a Maven user I think that everybody who is working on a project
>> should
>>>> behave the same. Hence, I would say, PMC members should rather
>> certainly
>>>> demonstrate how to live the community rules.
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>>>> Gesendet: Donnerstag, 25. Juli 2013 15:16
>>>> An: Maven Users List; Maven Developers List
>>>> Betreff: [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)
>>>>
>>>> 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 he> To unsubscribe, e-mail:
>>> dev-unsubscribe@maven.apache.org <javascript:;>
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> <javascript:;>
>>>>
>>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Paul
>>>
>>
>>
>> --
>> Sent from my phone
>>
>
>
>


-- 
John Casey
GitHub - http://github.com/jdcasey

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

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)

[Paul Benedict <pb...@apache.org>]

Stephen, those are great questions. Yet, I think these questions are riding
an assumption that PMC members are solely volunteering at Apache, because
the emphasis (as I interpret your words) is to place the Apache project
first/above other external contributions. Isn't that the heart of this
debate? A person who solely contributes to Apache and no other OS
organizations has no divided loyalties -- they do all their work here. But
what happens when contributions are here and elsewhere? I ask rhetorically,
to solicit answers, of course... and I see where this is going and what
historical processes within Maven are being addressed.


On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> Perhaps we could reframe the question a little then (as people seem to be
> testing hung up on the committed wording)...
>
> Should the PMC encourage people experimenting on new improvements to Maven
> to do that work at the ASF? And if so, should they then practice what they
> preach, and ensure that any experiments with Maven take place on the ASF
> SCM servers (at least once such experiments become semi-serious or progress
> enough not to cause egg-on-face syndrome)?
>
> Shoud the PMC promote other Apache projects, or moving non-Apache projects
> to Apache? (Right now, to work on an issue in core and effect the change
> yourself you may need to establish merit with: Apache Maven, Eclipse Sisu,
> Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
> fine with half of these at Eclipse and the ther half here... Or maybe
> not... But that is a lot of projects where you need to establish merit and
> perhaps maintain merit just to be able to commit directly (which sometimes
> is the only way to effect the type of cross system changes that some of our
> more obscure bugs may require... GIT makes this less of a requirement, as
> patches on SVN are a PITA, though) )
>
> These types of questions need resolution as they will, further down the
> road, rise up again and cause wounds... Eg logback vs log4j2 is one that
> simmers at the edge (any time anyone mentioned coloured loggers)
>
> -Stephen
>
> On Thursday, 25 July 2013, Paul Benedict wrote:
>
> > I don't think it is possible to force volunteer efforts and/or limit
> > development elsewhere. The idea of supporting a project is a vague
> notion.
> > I have my opinions too but this language is clearly unenforceable and
> > impractical.
> >
> > Cheers,
> > Paul
> >
> >
> > On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
> >
> > > As a Maven user I think that everybody who is working on a project
> should
> > > behave the same. Hence, I would say, PMC members should rather
> certainly
> > > demonstrate how to live the community rules.
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> > > Gesendet: Donnerstag, 25. Juli 2013 15:16
> > > An: Maven Users List; Maven Developers List
> > > Betreff: [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)
> > >
> > > 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 he> To unsubscribe, e-mail:
> > dev-unsubscribe@maven.apache.org <javascript:;>
> > > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> > >
> > >
> >
> >
> > --
> > Cheers,
> > Paul
> >
>
>
> --
> Sent from my phone
>



-- 
Cheers,
Paul

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)

[Baptiste MATHUS <ml...@batmat.net>]

Le 25 juil. 2013 23:05, "Stephen Connolly" <st...@gmail.com>
a écrit :
>
> Perhaps we could reframe the question a little then (as people seem to be
> testing hung up on the committed wording)...
>
> Should the PMC encourage people experimenting on new improvements to Maven
> to do that work at the ASF?

Sure. I don't see how one could disagree with the statement.

> And if so, should they then practice what they
> preach, and ensure that any experiments with Maven take place on the ASF
> SCM servers (at least once such experiments become semi-serious or
progress
> enough not to cause egg-on-face syndrome)?

Re-reading it with *PMC member* in mind, it also makes sense.
The difficulty is actually defining what is semi-serious, but anyway not
sure I'd see the goal for a *pmc member* to commit his WIP outside the asf.
Sure there's github's facilities to help contribution but there's already
an automatic asf->github mirroring, right?

>
> Shoud the PMC promote other Apache projects, or moving non-Apache projects
> to Apache? (Right now, to work on an issue in core and effect the change
> yourself you may need to establish merit with: Apache Maven, Eclipse Sisu,
> Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
> fine with half of these at Eclipse and the ther half here... Or maybe
> not... But that is a lot of projects where you need to establish merit and
> perhaps maintain merit just to be able to commit directly (which sometimes
> is the only way to effect the type of cross system changes that some of
our
> more obscure bugs may require... GIT makes this less of a requirement, as
> patches on SVN are a PITA, though) )

Not sure how this one could get handled in practice. I suppose this is
better to try and keep them at Apache, but using a myriad of different libs
is a reality in a majority if not all java projects.
To handle code issues, I think this might suffice to check the license
allows a local versions be used (as Jenkins does) to be sure Maven does not
get stuck because of one of those deps.
I think apache projects should be preferred when there's a real equivalence
between two choices. But again defining/agreeing on this can be hard. On
the log4j2/logback side for example, even if I personally use logback on a
daily-basis I'd understand log4j2 be chosen as a default provider because
it's a apache project and the equivalence seems to be more and more a
reality.

Cheers

-- Baptiste

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)

[Paul Benedict <pb...@apache.org>]

Stephen, those are great questions. Yet, I think these questions are riding
an assumption that PMC members are solely volunteering at Apache, because
the emphasis (as I interpret your words) is to place the Apache project
first/above other external contributions. Isn't that the heart of this
debate? A person who solely contributes to Apache and no other OS
organizations has no divided loyalties -- they do all their work here. But
what happens when contributions are here and elsewhere? I ask rhetorically,
to solicit answers, of course... and I see where this is going and what
historical processes within Maven are being addressed.


On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> Perhaps we could reframe the question a little then (as people seem to be
> testing hung up on the committed wording)...
>
> Should the PMC encourage people experimenting on new improvements to Maven
> to do that work at the ASF? And if so, should they then practice what they
> preach, and ensure that any experiments with Maven take place on the ASF
> SCM servers (at least once such experiments become semi-serious or progress
> enough not to cause egg-on-face syndrome)?
>
> Shoud the PMC promote other Apache projects, or moving non-Apache projects
> to Apache? (Right now, to work on an issue in core and effect the change
> yourself you may need to establish merit with: Apache Maven, Eclipse Sisu,
> Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
> fine with half of these at Eclipse and the ther half here... Or maybe
> not... But that is a lot of projects where you need to establish merit and
> perhaps maintain merit just to be able to commit directly (which sometimes
> is the only way to effect the type of cross system changes that some of our
> more obscure bugs may require... GIT makes this less of a requirement, as
> patches on SVN are a PITA, though) )
>
> These types of questions need resolution as they will, further down the
> road, rise up again and cause wounds... Eg logback vs log4j2 is one that
> simmers at the edge (any time anyone mentioned coloured loggers)
>
> -Stephen
>
> On Thursday, 25 July 2013, Paul Benedict wrote:
>
> > I don't think it is possible to force volunteer efforts and/or limit
> > development elsewhere. The idea of supporting a project is a vague
> notion.
> > I have my opinions too but this language is clearly unenforceable and
> > impractical.
> >
> > Cheers,
> > Paul
> >
> >
> > On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
> >
> > > As a Maven user I think that everybody who is working on a project
> should
> > > behave the same. Hence, I would say, PMC members should rather
> certainly
> > > demonstrate how to live the community rules.
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> > > Gesendet: Donnerstag, 25. Juli 2013 15:16
> > > An: Maven Users List; Maven Developers List
> > > Betreff: [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)
> > >
> > > 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 he> To unsubscribe, e-mail:
> > dev-unsubscribe@maven.apache.org <javascript:;>
> > > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> > >
> > >
> >
> >
> > --
> > Cheers,
> > Paul
> >
>
>
> --
> Sent from my phone
>



-- 
Cheers,
Paul

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)

[Stephen Connolly <st...@gmail.com>]

Perhaps we could reframe the question a little then (as people seem to be
testing hung up on the committed wording)...

Should the PMC encourage people experimenting on new improvements to Maven
to do that work at the ASF? And if so, should they then practice what they
preach, and ensure that any experiments with Maven take place on the ASF
SCM servers (at least once such experiments become semi-serious or progress
enough not to cause egg-on-face syndrome)?

Shoud the PMC promote other Apache projects, or moving non-Apache projects
to Apache? (Right now, to work on an issue in core and effect the change
yourself you may need to establish merit with: Apache Maven, Eclipse Sisu,
Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
fine with half of these at Eclipse and the ther half here... Or maybe
not... But that is a lot of projects where you need to establish merit and
perhaps maintain merit just to be able to commit directly (which sometimes
is the only way to effect the type of cross system changes that some of our
more obscure bugs may require... GIT makes this less of a requirement, as
patches on SVN are a PITA, though) )

These types of questions need resolution as they will, further down the
road, rise up again and cause wounds... Eg logback vs log4j2 is one that
simmers at the edge (any time anyone mentioned coloured loggers)

-Stephen

On Thursday, 25 July 2013, Paul Benedict wrote:

> I don't think it is possible to force volunteer efforts and/or limit
> development elsewhere. The idea of supporting a project is a vague notion.
> I have my opinions too but this language is clearly unenforceable and
> impractical.
>
> Cheers,
> Paul
>
>
> On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
>
> > As a Maven user I think that everybody who is working on a project should
> > behave the same. Hence, I would say, PMC members should rather certainly
> > demonstrate how to live the community rules.
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> > Gesendet: Donnerstag, 25. Juli 2013 15:16
> > An: Maven Users List; Maven Developers List
> > Betreff: [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)
> >
> > 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 he> To unsubscribe, e-mail:
> dev-unsubscribe@maven.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
> >
> >
>
>
> --
> Cheers,
> Paul
>


-- 
Sent from my phone

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)

[Stephen Connolly <st...@gmail.com>]

Perhaps we could reframe the question a little then (as people seem to be
testing hung up on the committed wording)...

Should the PMC encourage people experimenting on new improvements to Maven
to do that work at the ASF? And if so, should they then practice what they
preach, and ensure that any experiments with Maven take place on the ASF
SCM servers (at least once such experiments become semi-serious or progress
enough not to cause egg-on-face syndrome)?

Shoud the PMC promote other Apache projects, or moving non-Apache projects
to Apache? (Right now, to work on an issue in core and effect the change
yourself you may need to establish merit with: Apache Maven, Eclipse Sisu,
Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
fine with half of these at Eclipse and the ther half here... Or maybe
not... But that is a lot of projects where you need to establish merit and
perhaps maintain merit just to be able to commit directly (which sometimes
is the only way to effect the type of cross system changes that some of our
more obscure bugs may require... GIT makes this less of a requirement, as
patches on SVN are a PITA, though) )

These types of questions need resolution as they will, further down the
road, rise up again and cause wounds... Eg logback vs log4j2 is one that
simmers at the edge (any time anyone mentioned coloured loggers)

-Stephen

On Thursday, 25 July 2013, Paul Benedict wrote:

> I don't think it is possible to force volunteer efforts and/or limit
> development elsewhere. The idea of supporting a project is a vague notion.
> I have my opinions too but this language is clearly unenforceable and
> impractical.
>
> Cheers,
> Paul
>
>
> On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
>
> > As a Maven user I think that everybody who is working on a project should
> > behave the same. Hence, I would say, PMC members should rather certainly
> > demonstrate how to live the community rules.
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> > Gesendet: Donnerstag, 25. Juli 2013 15:16
> > An: Maven Users List; Maven Developers List
> > Betreff: [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)
> >
> > 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 he> To unsubscribe, e-mail:
> dev-unsubscribe@maven.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
> >
> >
>
>
> --
> Cheers,
> Paul
>


-- 
Sent from my phone

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)

[Baptiste MATHUS <ml...@batmat.net>]

Hi,
I think the point is quite simple.
I agree with Jason that work should be the main criteria if not the only
one.
But as Stephen reminds, we should define "work" in a larger general sense
than just code. Working for the community as worshipped by the ASF can be
pushing code, sure, but also helping people in many manners : docs, ml, etc.

Cheers
Le 25 juil. 2013 22:32, "Paul Benedict" <pb...@apache.org> a écrit :

> I don't think it is possible to force volunteer efforts and/or limit
> development elsewhere. The idea of supporting a project is a vague notion.
> I have my opinions too but this language is clearly unenforceable and
> impractical.
>
> Cheers,
> Paul
>
>
> On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:
>
> > As a Maven user I think that everybody who is working on a project should
> > behave the same. Hence, I would say, PMC members should rather certainly
> > demonstrate how to live the community rules.
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> > Gesendet: Donnerstag, 25. Juli 2013 15:16
> > An: Maven Users List; Maven Developers List
> > Betreff: [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)
> >
> > 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
> > >
> > >
> > >
> >
> > --
> > Sent from my phone
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> Cheers,
> Paul
>

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)

[Paul Benedict <pb...@apache.org>]

I don't think it is possible to force volunteer efforts and/or limit
development elsewhere. The idea of supporting a project is a vague notion.
I have my opinions too but this language is clearly unenforceable and
impractical.

Cheers,
Paul


On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg <ka...@quipsy.de> wrote:

> As a Maven user I think that everybody who is working on a project should
> behave the same. Hence, I would say, PMC members should rather certainly
> demonstrate how to live the community rules.
>
> -----Ursprüngliche Nachricht-----
> Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Gesendet: Donnerstag, 25. Juli 2013 15:16
> An: Maven Users List; Maven Developers List
> Betreff: [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)
>
> 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
> >
> >
> >
>
> --
> Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
Cheers,
Paul

AW: [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)

[Markus Karg <ka...@quipsy.de>]

As a Maven user I think that everybody who is working on a project should behave the same. Hence, I would say, PMC members should rather certainly demonstrate how to live the community rules.

-----Ursprüngliche Nachricht-----
Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com] 
Gesendet: Donnerstag, 25. Juli 2013 15:16
An: Maven Users List; Maven Developers List
Betreff: [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)

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
>
>
>

--
Sent from my phone

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

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)

[Chris Graham <ch...@gmail.com>]

On Thu, Jul 25, 2013 at 11:16 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> There are two schools of thought amongst the current members of this
> projects PMC.
>
>
Are they mutually exclusive?

>From my (limited [so I could be way off here]) understanding of Apache,
don't you only get to be on the PMC for having demonstrated the correct
community spirit and sufficient commitment 'to the cause' (as it were)?

And like many real world jobs, when you 'step up' you often gain/get
thrusted upon you more responsibility; it's just a part of the job.

I understand why the Apache Foundation has the legal requirements that it
does. It also needs people to monitor implement them. That appears to fall
upon the PMC.

It seems to me that for someone to get to be on the PMC to start with they
have demonstrated sufficient community spirit and commitment to the project.

So as you said, it's not black and white. :-) I'm happy to see it as both.

Personally, I prefer to lead by example. But you can still do that whilst
maintining the legal requirements.

-Chris





> 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
> >
> >
> >
>
> --
> Sent from my phone
>

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)

[Thomas Broyer <t....@gmail.com>]

I think I'm with Ron Wheeler here.

I'd add though: are you a “Project Manager” if you don't contribute to
the project the changes you're doing in a fork? My gut feeling would
be “no”, but that'd be ignoring the amount of contributions to the
project itself (I know who you're talking about, but I have no idea
what his implication in Maven proper is).

Also, AFAICT, the "long running fork" (at least 2 years) is not open
source (parts of it are, not everything) so it's hard to know what
will come out of it and when, and how much implication the PMC member
has in each project.

Also, the fork website says there's no intent in forking Maven (but
rather build upon it).
Or am I wrong about what's and who's being pointed at under cover?

I can hardly comment more than that, being ignorant of what happens on
the Maven Dev list. If the PMC member being pointed at here is who I
think he is, then I have no other problem with his work than not being
open source (and apparently not a proprietary non-free product
either), and creating dissension in the PMC.

That being said, the more I use Maven, the more I think it's “broken
by design”, and there's unfortunately nothing better out there with a
big-enough community to compete.
http://blog.ltgt.net/in-quest-of-the-ultimate-build-tool
I wouldn't really mind if Maven collapsed like others here “predict”,
I'd just switch to another contender (Gradle probably) that's just
different more than being better.
So in the end, don't give too much weight to my opinion here ;-)

On Thu, Jul 25, 2013 at 3:16 PM, Stephen Connolly
<st...@gmail.com> 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
>>
>>
>>
>
> --
> Sent from my phone



-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

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

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)

[Ron Wheeler <rw...@artifact-software.com>]

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

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)

[Thomas Broyer <t....@gmail.com>]

I think I'm with Ron Wheeler here.

I'd add though: are you a “Project Manager” if you don't contribute to
the project the changes you're doing in a fork? My gut feeling would
be “no”, but that'd be ignoring the amount of contributions to the
project itself (I know who you're talking about, but I have no idea
what his implication in Maven proper is).

Also, AFAICT, the "long running fork" (at least 2 years) is not open
source (parts of it are, not everything) so it's hard to know what
will come out of it and when, and how much implication the PMC member
has in each project.

Also, the fork website says there's no intent in forking Maven (but
rather build upon it).
Or am I wrong about what's and who's being pointed at under cover?

I can hardly comment more than that, being ignorant of what happens on
the Maven Dev list. If the PMC member being pointed at here is who I
think he is, then I have no other problem with his work than not being
open source (and apparently not a proprietary non-free product
either), and creating dissension in the PMC.

That being said, the more I use Maven, the more I think it's “broken
by design”, and there's unfortunately nothing better out there with a
big-enough community to compete.
http://blog.ltgt.net/in-quest-of-the-ultimate-build-tool
I wouldn't really mind if Maven collapsed like others here “predict”,
I'd just switch to another contender (Gradle probably) that's just
different more than being better.
So in the end, don't give too much weight to my opinion here ;-)

On Thu, Jul 25, 2013 at 3:16 PM, Stephen Connolly
<st...@gmail.com> 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
>>
>>
>>
>
> --
> Sent from my phone



-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

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

AW: [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)

[Markus Karg <ka...@quipsy.de>]

As a Maven user I think that everybody who is working on a project should behave the same. Hence, I would say, PMC members should rather certainly demonstrate how to live the community rules.

-----Ursprüngliche Nachricht-----
Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com] 
Gesendet: Donnerstag, 25. Juli 2013 15:16
An: Maven Users List; Maven Developers List
Betreff: [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)

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
>
>
>

--
Sent from my phone

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

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)

[Stephen Colebourne <sc...@joda.org>]

The section that was added below has nothing to do with the rest of
the document. It should be reverted, as it is basically nonsense as
Jason has just pointed out.

Maven has lots of other problems. This really doesn't seem like one
anyone should be spending any time or energy on.

Stephen



On 25 July 2013 14:16, Stephen Connolly <st...@gmail.com> 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
>>
>>
>>
>
> --
> Sent from my phone

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

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)

[Fred Cooke <fr...@gmail.com>]

I really appreciate your regularly inserted pieces of Irish humour and
often chuckle at them! Keep that up! :-)

What matters most to me is not the Apache legal stuff, nor good
behaviour/political correctness, rather it's technical excellence and
honesty in achieving it, even if at the expense of hurting someone's
feelings. They should be adults, after all, and not subject to hurt via
technical correction and discussion, even if firey.

My 2c, but you already know how little I care about stepping on toes,
especially when it comes to release semantics :-)

Fred.

On Thu, Jul 25, 2013 at 3:16 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> 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
> >
> >
> >
>
> --
> Sent from my phone
>