incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: my pTLP view
Date Sat, 24 Jan 2015 01:10:07 GMT
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

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

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

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


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