Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104011
MIME-Version: 1.0
References: <03f401d4b96b$18b9dc60$4a2d9520$@php.net> <CAKOpQSwTneMrNnN=RAKUU2uU5JVEUoJkXwuO_5ymxBarBJNR7Q@mail.gmail.com>
 <CAJHtznwtMDyQg5gvUjmEzfVqGOjnm-3neq=tPJxUbamPub=4ng@mail.gmail.com>
 <CAEYWF=7fCDBv8M1XUi865Dn92p4CA8w+DviFfcWwC5GfijEQ9A@mail.gmail.com> <1549071678.26811.6.camel@schlueters.de>
In-Reply-To: <1549071678.26811.6.camel@schlueters.de>
Reply-To: bishop@php.net
Date: Sat, 2 Feb 2019 01:20:30 -0500
Message-ID: <CAEYWF=7YE72fGs+2=PH2XeEWJ7JUXJRUQNP6XjhnVVX8MUv8Qg@mail.gmail.com>
To: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>
Cc: Zeev Suraski <zeev@php.net>, PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002e70060580e34356"
Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
From: bishop@php.net (Bishop Bettini)

--0000000000002e70060580e34356
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 1, 2019 at 8:41 PM Johannes Schl=C3=BCter <johannes@schlueters.=
de>
wrote:

> On Do, 2019-01-31 at 14:28 -0500, Bishop Bettini wrote:
> >
> >    2. Core developers are defined as the top 13 committers within the
> >    period of two years since voting began. A core developer is a de
> > facto
> >    community member, but caucuses as a core developer.
>
> How do you define "top 13 committers"? How do you prevent people from
> playing the system by committing typo changes in comments etc.? Will
> somebody who rewrites a larger change into a single commit be
> negatively ranked compared to somebody who creates a small fix which
> requires multiple small fixes afterwards?


> I don't think quantity of anything (lines changed, commits, ..) is a
> good metric in any way.


> Either the list of contributors has to be inclusive or people have to
> be elected (with all the issues of electing people)
>

TL;DR: I don't think it matters. Any quantitative measure identifying those
with the highest skill, accomplishment, availability, and belief in the
community will suffice. The combined effect of a multi-cameral system,
quorum, and super-majority override will minimize the effects of gaming.

Identifying those who can vote requires a "selection metric". Our current
unicameral voting system has a "low bar" selection metric. The voting
eligibility portion of Zeev's proposal changes the selection metric, but
keeps the unicameral body. I feel formally identifying the top contributors
and giving them a separate say is an important step toward reform, but
retaining a unicameral body is not, in my opinion, progress.

So, how do we identify those who are currently the most contributory?
Commits mostly, though we can't ignore other qualities. In a 2003 paper
[1], Scacchi (UC Irvine) defined a F/OSS meritocracy pyramid in which those
at the top had the highest *perceived* authority. Kaats (Utrecht
University) et. al. in 2014 [2] built on Scacchi's research saying:

"In order to assess the merits [of those at the pyramid top] one
cannot simply measure one aspect... while most had a good commit
track-record, there were also a fair amount that had barely written any
code... yet those individuals might contribute in other ways."

Scacchi's research cautions, in counterpoint, that SCM write access is a
form of potentially damaging control:

"The ability for the eyes of many developers to review or look over source
code, system build and preliminary test results, and response to bug
reports also realizes peer review and the potential for embarrassment as a
form of indirect social control over the timely actions of contributing
F/OSS developers. Thus, F/OSS development allows for ... manipulation by
the core developers, so as to encourage certain patterns of software
development and social control, and to discourage others that may not
advance the collective needs"

That is, git is a mechanism for control. Be that gaming to enter the
selection metric, or by rejecting contributions of others, it's a means for
those who *can* contribute to control those who only *might* contribute.

So while a selection metric based on commits is a robust means of
identifying top contributors, it's necessary - but not sufficient - and may
even be damaging. For this reason I suggest the safer strategy of a
multi-cameral system that includes the voices of those who don't commit, or
commit substantially less than those selected as top.

Let us imagine a faction that games git and seizes majority control over
the core contributors metric. Under Zeev's voting eligibility proposal, yes
it'd be harder to game the contingency of 175 members. But, that large a
group also can't reasonably form a quorum, which means we have no assurance
those that vote speak for the group. Under my counter-proposal, with only 7
members to quorum, it's statistically easier to game. But those that are
bumped out still have a vote in the community, so the effect of gaming is
effectively cancelled. Further, the community does not have to form a
quorum, so it's statistically easier for the community to counter a 2/3
super-majority of core developers. Which is why, in all likelihood, the
tie-breaking member would typically be a top committer or a grand-elder.

In short, the balance from a multi-cameral system limits the effects of
gaming git and gives a vote to those who contribute in ways other than
writing huge amounts of code.

[1]:
https://www.researchgate.net/publication/266661660_The_Merits_of_a_Meritocr=
acy_in_Open_Source_Software_Ecosystems
[2]:
https://www.researchgate.net/publication/2856601_FreeOpen_Source_Software_D=
evelopment_Practices_in_the_Computer_Game_Community

--0000000000002e70060580e34356--