maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curtis Rueden <ctrue...@wisc.edu>
Subject Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)
Date Thu, 25 Jul 2013 14:18:09 GMT
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" <nigel.magnay@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
> >
>

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