On Fri, Feb 1, 2019 at 8:41 PM Johannes Schlüter <johan...@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_Meritocracy_in_Open_Source_Software_Ecosystems [2]: https://www.researchgate.net/publication/2856601_FreeOpen_Source_Software_Development_Practices_in_the_Computer_Game_Community
