On Mon, Feb 16, 2015 at 7:48 PM, Larry Garfield <la...@garfieldtech.com> wrote:
> On 02/16/2015 10:31 AM, François Laupretre wrote: > >> >> - The leadership of the language is left to consensus, so that when >>> consensus cannot be reached, someone has to take on the role of mediator >>> / chairman / leader for the feature, and try to push through a >>> compromise. >>> >> I have no democratic solution for this. In the PHP spirit, as Zeev >> explained, if the RFC process doesn't bring a consensus before the vote, >> the discussion should stop and the RFC should be modified. Trying to push >> it to a 2/3 approval while people are fighting is counter-productive. In >> this regard, IMO (and I told her), Andrea should have withdrawn her RFC >> much sooner. It would have allowed to take more time for building the next >> one, and start a new discussion in a more constructive atmosphere. Upcoming >> feature freeze was probably the reason but the result is that we need to >> restart everything from scratch in a bitter atmosphere. >> > > To be clear: consensus is not leadership. Consensus cannot be > leadership. So the statement "leadership of the language is left to > consensus" is a very explicit and deliberate statement that the language > has no leadership. > On what basis are you making that assertion? Consensus can be viewed as a form of "group leadership", so long as there are sufficient processes involved to facilitate that. It need not necessarily lead to anarchy and disorder, so I don't think it's necessarily a contradiction in terms. The problem with having a single leader calling the shots in this case is that it wouldn't make all the divergent views go away. Instead, we'd probably see a good half a billion or so new hooks to PHP emerging as competing projects. I think that would be far worse than what we have now, even though what we have now is far from perfect. > > That is, as I understand it, by design. But let's not pretend otherwise. > We have a leaderless language and development process, by design, with all > of the negative side-effects that such a power-vacuum structure entails. > > I'm not saying that as a criticism necessarily. It's just a fact, and we > shouldn't pretend otherwise. > > >> - The RFC process traditionally has only one voting phase, with a >>> Proof-Of-Concept patch completed, and voters expecting few >>> implementation details to change. So a lot of time has to be committed >>> to the details of a feature which might be outright rejected. It might >>> be more efficient if the principle of a change, details such as syntax, >>> and final implementation, could be considered separate phases. >>> >> That's the tradition but I think it is quite open for improvements. While >> we are traditionally using one final vote with multiple options, nothing >> refrains anyone to organize informative pre-votes during discussion to test >> the popularity of a feature before he starts writing code, clearly stating >> that it is not the final vote. This would allow a better information from >> the community to the RFC author. The interest of such running pre-votes is >> that they can contain many more options than the final vote and can be >> started and closed at anytime during discussion. The only requirement is >> that everyone understands that it in *not* the final vote. >> > > The FIG ran into a similar issue a while back. The result is a somewhat > different two-stage RFC process as described here: > https://github.com/php-fig/fig-standards/blob/master/ > bylaws/004-psr-workflow.md > > It's imperfect, but it does provide extra structure that has been a huge > improvement over the internals-like free-for-all that preceded it. In > particular, it allows members to vote on the concept of a PSR before the > implementation. IE, "do we want to have a spec dealing with HTTP messages" > is a separate vote from "is this particular implementation of an HTTP > message spec what we want to put our stamp on"? > > Additionally, there's a separate spec and meta document. The meta doc is > specifically for things like "Why did you do X instead of Y?" and "we > rejected Z outright for these reasons". That said, people generally don't > read the metadoc any more frequently than they read the same notes in > Internals RFCs today, which often address the issue people are talking > about for the 5th time. :-( > > An exact replica of FIG's process is probably not going to fly for > Internals for various good reasons, but it can hopefully serve as a source > of ideas. > > The FIG is a good example of a relatively small group of individuals who decided to draft their style preferences into a set of standards and tried to impose that on everyone else by aggressively billing themselves as the de-facto "official" standard. I recall on more than one occasion one of their organizers posting here trying to get us to endorse their standard as the official PHP standard. I've also seen them post on places like StackOverflow on at least a couple occasions, interjecting on some unrelated coding question to tell someone their code is not standards-compliant and providing links to the PSR's. I realize this is a tangent, but I always feel a need to push back now whenever someone links to their PSR stuff as an example of what people should be doing. You're fine citing them; I just had to put that little asterisk in there. I'd hate to have to post a link to XKCD's "Standards" strip again.... </soapbox> > --Larry Garfield > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I think we should be careful not to make this more complicated than it needs to be. Adding a complex new set of rules wouldn't make things any more or less civil. On the whole, I think we do a fairly good job of that on this list. There can be very heated disagreements, sometimes, but you'll find that when you put any group of developers together. So long as people behave like adults and make an effort to be civil, I don't think any special action is needed on our part. Like the FIG, I'd tend to look at it as a solution in search of a problem. --Kris
