incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: overzealous bureaucracy (was: [VOTE] Zipkin leave incubator, return back to OpenZipkin)
Date Wed, 19 Jun 2019 20:29:14 GMT
On Wed, Jun 19, 2019 at 12:14 PM Ted Dunning <> wrote:

> On Wed, Jun 19, 2019 at 12:17 AM Greg Stein <> wrote:
> > On Wed, Jun 19, 2019 at 1:48 AM Justin Mclean <>
> > wrote:
> >
> > > Hi,
> > >
> > > > The VOTE was ridiculous. It can only come out "Yes", so why?
> > >
> > > Which is the outcome of most votes, they confirm consensus.
> >
> >
> > A vote has two outcomes. This kind of vote should never have a "no"
> > outcome. Thus, it is specious on its face.
> >
> Not so much. Votes at Apache are often used to memorialized consensus in a
> highly searchable fashion. It helps to make sure that people are on the
> same page.

The podling community's archives have that. general@incubator would have an
[EXIT] or [RETIRE] or [NOTICE] email sent to it.

If the community consensus is to leave, then the IPMC has no further say.

Note that I said consensus.

Any -1s here would be a major surprise, but, precisely because they would
> be a surprise, it would be important to make sure that there is a moment
> that they could be brought out.
> You are right that a vote that has consensus already established should
> have the expected outcome, unless the consensus was, say, the result of
> loud voices drowning out shy voices.

The Foundation does not police loud/shy voices in consensus. We don't
police it all, but presume it is occurring. (and await escalation reports
of failure to follow consensus)

> > But to be more specific in this case, to give a clear searchable record
> in
> > > the mail archives that this wasn’t a fork or other adverse situation.
> >
> > That was already established and recorded in the Zipkin community, with
> > their vote to depart.
> That established half of the consensus. The IPMC documented the other half.

The IPMC is not part of the community. It has no vote.

> > > Others might have other reasons for thinking it was needed. Also, a
> > mentor
> > > called the vote and I respect their decision to do so.
> >
> > Which mentor? Sheng Wu? Bullied into holding a vote?
> I was watching and I didn't see any bullying. Did you? Were you even
> watching the process in detail?

Sheng called the vote, but clearly did not feel it was needed. "Bully"
might be too strong a word, but "obligating" somebody to run a vote pretty
well fits the same bill.

I read Justin's email as ambiguous on whether he meant the concrete call to
vote (Sheng and the email thread), or the "decision" to have Sheng run a
vote, per my comment next para:

> Or maybe from the private@incubator list, the one who said "I would say we
> > should take a discuss/vote in general@incubator to retire the podling".
> > That is simply participating in IPMC overreach. It is a sign of
> disrespect
> > for the Zipkin community, that the IPMC has "final say" and requires a
> vote
> > to (ahem) "allow them to leave". The IPMC is NOT in control of
> communities.
> > It is foolish to believe so, and to construct "procedures" and "policy"
> and
> > "bureaucracy" to pretend so.
> No, that isn't what this vote is saying. This vote is *confirming* that
> nobody has objections (of any form) to Zipkin leaving and control of the
> git repos being transferred.

Why should the IPMC have any say in a community that has refused to further
participate in Apache? That is nonsensical.

Why do they ask at weddings if there is anybody who might bring any reason
> for the wedding to not go forward?

Not at my wedding! :p

> It isn't that they *expect* anybody to
> bring something up. Instead, the tradition is there to record community
> consensus. It used to have a very serious importance when communities were
> smaller like Apache is now.

I reject the notion that the IPMC has any say in a community's decision to
retire. If I have in the past, then I was wrong and my thinking has

I believe the IPMC has become to "interfere-y" with the podling
communities. If it takes a Hall Pass from VP Legal to get the IPMC out of
release voting, then Make It So. Podling communities should make their
releases, and the IPMC should have no vote in that process. Review/feedback
all they want, of course. But no votes, as that implies they have ownership
of the community's release process.


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