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.conno...@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 <k...@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.conno...@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-unsubscr...@maven.apache.org <javascript:;>
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> <javascript:;>
> > >
> > >
> >
> >
> > --
> > Cheers,
> > Paul
> >
>
>
> --
> Sent from my phone
>



-- 
Cheers,
Paul

Reply via email to