incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <>
Subject Re: my pTLP view
Date Sat, 24 Jan 2015 01:42:14 GMT
I find the direction this discussion has gone personally disappointing, but
I might be missing understanding of some crucial point.

> 2. the initial PMC is comprised of only ASF Members. committers can be
​> ​
chosen however the community decides. but the *project* is reviewed by
​> people with (hopefully/theoretically) experience with the Foundation and
> its views on communities

So should I take my successful project and community to Apache, the first
thing that happens is the foundation creates a Project Management Committee
out of the membership, not the incoming community. This might be fine for
new projects made up of familiar faces, but not where there is new blood.
Those of us in such a new incoming community might get the commit bit but
can't vote on adding committers, or making releases. We don't have a
binding vote on our own committership / fate / ability to manage our own
sources. This situation is primed for mistrust, conflict, and heartache the
second the members and the incoming community disagree about some
substantial aspect of the project direction. The incoming community is
disempowered and has no recourse but to go along with the outcome of Apache
politics or abandon the project. As a responsible steward of my community,
I would never consider bringing my project to Apache under these

This may also increase the risk a project is coming here due to an
excessive fascination with the Apache brand, because otherwise the bargain
seems poor (in my view).

On Fri, Jan 23, 2015 at 5:10 PM, Greg Stein <> wrote:

> On Fri, Jan 23, 2015 at 6:18 PM, jan i <> wrote:
> > On Saturday, January 24, 2015, Ross Gardler (MS OPEN TECH) <
> >
> > <javascript:_e(%7B%7D,'cvml','');>> wrote:
> >
> > > No, the PMC is *not* the driving force. The project community is, even
> > > where the PMC is a subset of the committers. Since it is the set of
> > active
> > > *contributors* that are important, they are the ones doing the work.
> >
> > I totally agree, but pTLC calls for a PMC that can be 0% subset of the
> > community, how can the PMC in this situation reflect the community?
> >
> Because the Board chose to put people onto the PMC that understand: *guide*
> the community. Not *rule* the community.
> Even better is when the ASF/PMC members are *part* of the community, rather
> than just being present to assist with that guidance.
> In the current Incubator model, a "Champion" is chosen. That is usually a
> person who has some self-interest in the project, and becomes *part* of the
> community. So you already have some overlap there.
> >
> > Remember we talk rules here, and rules should be made so the reflect what
> > we want, and I believe it is important that the community is represented
> in
> > the PMC, not 100% but also not 0%.
> >
> No. We DON'T talk about rules here. I said "create a PMC with a couple
> requirements". Then the project does what works best for their community,
> within the overall view of what the ASF believes makes a great project.
> Rules exist to provide guidance when consensus does not exist. That is all
> a rule is good for. A project with a strong consensus model doesn't need
> rules.
> > > I don't understand your argument about releases. Nothing changes under
> > > under the pTLP proposal with respect to how a release is made. In any
> > > project the full community votes for a release if they want to. Only
> the
> > > PMC have binding votes, but they should listen to the community in
> casting
> > > those votes (same is true for podlings where the podling community
> votes on
> > > a release but it needs to be formalized by the IPMC via its mentors).
> > I read the rules instead of believing in "should". If a PMC does not like
> a
> > technical direction, they can block it totally within the rules, even if
> > all non-PMC prefers it.
> Sure... they *could*. How long do you honestly believe the Board would
> allow that to continue? Seriously.
> You propose a situation that just won't ever happen.
> > I think my problem is that I agree with both you and Roman, The PMC
> should
> > leave technical matters including releases to the total community. But
> > alone by talking about "binding" and "non-binding" votes creates two
> > levels, and if the PMC does not include the incoming community the
> > disconnect gets bigger.
> There *are* two different levels. That is how it works. Always has. Always
> will. Accept that.
> But that doesn't mean those with binding votes should (or WOULD!!) ignore
> those without. I don't see that happen. Do you? I would guess not. So it
> isn't something to worry about.
> I also specifically said "ASF Members" because I believe *they* know how to
> run a community. Not to use the ASF legal structure against it, but to help
> the community work *within* the structure. As Ross said: to empower the
> community.
> > With pTLC I fear that the incoming community will feel empowered,  the
> [ I'm assuming you meant: "not feel empowered" ]
> > community does not (according to the rules) need to vote, just let the
> > members do the work. With PPMC the podling must make a vote otherwise a
> > release will never happen.
> That won't happen. The community will do the work. If not, then there
> wasn't a community.
> You are looking at an extreme failure mode "according to what is possible
> in the rules". I am telling you: that won't happen. We don't allow our
> communities to do that, and we won't create a PMC that allows that to
> happen. And the Board will be reviewing the project to *ensure* it doesn't
> happen.
> > Again please remember I read the suggested rules and see what could go
> > wrong, in a perfect world we would not have wars and every project would
> > function perfect.
> Your pessimism is unwarranted.
> -g

Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

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