Taming the Wild West of PHP

Flickr: by Moyan_Brenn

In a previous posting, I briefly mentioned something bizarre that happened this past December 2013.  At a certain point while core contributors were voting, the individual votes suddenly vanished!   A solitary number remained visible for each active RFC ( “Request for Comments”,  a formal proposal), representing  the current vote tally.  Initially, I believed that a temporary glitch had occurred, but as time passed I began to suspect that someone had intentionally sought to impose a secret ballot.  Just as a most historic vote was occurring  with respect to the addition of an exponent operator for PHP, along came this annoyance obscuring the view of the vote’s progress.

The imposed secret ballots resulted from merging a year-old pull request (PR) entitled “Hide vote choices for in-progress votes.” And, it came from a good thought, too, a desire to protect the integrity of the voting process. Various political factors might potentially shape the outcome of a vote, according to one core developer (see http://markmail.org/message/4dgzlcbakvgpvxtw).

Secret ballots may appear to clash with the open nature of opensource  projects. While transparency is normally commendable for such projects, must everything be transparent?  I enjoy entertaining my curiosity in following the voting, but perhaps the visibility of the votes during the voting period might hinder the voting. That visibility may create an unfair environment for people to heed the dictates of their conscience.

The major mandate for an open source project in terms of openness is that its source code stay openly accessible. Governance in general and voting in particular are internal affairs left to the discretion of the project leadership, or in the case of PHP those who step up to the plate from time to time and exert leadership while remaining unofficial in that capacity; the project has yet to have an official leader.

One question, why the decision to merge the PR whose content is far from trivial while the voting was still underway?  Perhaps, realistically there is always a voting period in progress  and so waiting for a more optimal time would be futile. More disturbing than the type of change was neglecting to consider any discussion before merging it.  Why did the merge happen?  Probably because of a lack of laws or other restriction to make anyone think twice.  Welcome to the Wild West of PHP where bylaws are to date non-existent.

Someone once warned me that Git can pose some serious challenges since its version control system permits an abundance of freedom.  This incident illustrates the necessity of  establishing some kind of software sentry  to prevent a core contributor with an exuberance of initiative from acting single-handedly and take matters into his/her hands.

Software alone is in an incomplete answer. The way this particular change transpired is a wake-up call that the PHP project seriously needs bylaws. Other opensource projects have them, such as the Apache Software Foundation. The PHP project would be wise to do the same.  In this case,  bylaws could  address the issue of secret ballots, including whether to reserve them for special circumstances.

The whole matter of someone taking audacious action while voting was already in progress is a point that tends to get obscured in the urge to denounce this particular merge.  I proposed a while back, on the Internals List, that the PHP project ought to have bylaws as do most modern organizations. That idea met with abject silence.  (Maybe the mute response really indicated displeasure at my having unintentionally committed the sin of top-posting?)  Until the adoption of bylaws, the most reasonable way to resolve this matter is for someone to create an RFC, submit it for discussion and then conduct a vote, openly of course.

Just as the time came after nearly two decades for PHP to have an exponent operator, this incident should provide the necessary anecdotal evidence in favor of the project having  clear, well-written bylaws.  In geek-speak that means decoupling matters procedural concerning the governance of the project from the RFCs.  If there were bylaws that clearly articulated the minutiae concerning voting, for example, including who has the right to vote and how one may attain that right, surely the PHP project would reap the benefit of greater clarity and increased participation.  

Suggested Reading:

http://markmail.org/message/3tk3ayjy54mviuig

https://github.com/php/web-wiki/pull/1

This work is licensed under a