maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <>
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/
Date Thu, 25 Jul 2013 17:37:04 GMT
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 []
> 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/
> On Jul 25, 2013, at 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.
> >
> 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: <javascript:;>
> For additional commands, e-mail:<javascript:;>

Sent from my phone

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message