Voting on PHP development processes

This post is mostly going to be a (fairly) quick brain dump of my thoughts. Warning: they may not be particularly coherent or well explained. The topic of thought is my voting on two side-by-side votes centered on improving practices surrounding PHP version releases and additions to (or removals from) the language.

For those with some time to spare, the subjects were written up as RFCs for discussion on the PHP internals mailing list and were then put up for vote. Those RFC pages are on the PHP wiki under Voting on PHP features (votes) and Release Process (votes).

Both votes are now closed and the tallies are as follows:

Now, on to the point of this post: I voted Nay to both of the RFCs. As you will see (or not, if boredom sets in) neither are the strongest nay in the world but sitting on the fence would be a wasted opportunity.

Voting on PHP features

It is beyond the scope of this post to detail what this RFC covers, go read it now. I’ll still be here when you’ve finished. For those not wanting to bore themselves with the details, or as a reminder for whose who did, this particular topic boils down to: lets have more structured voting for changes to PHP, lets tag mailing list threads with [RFC] and [VOTE] as appropriate, lets move that voting off of the mailing list and on to the wiki, and finally lets put some minimum/guideline timeframes into place for the process.

All of the points are sensible and clearly are favourable to many over what we have (indeed, don’t have) at the moment. But it all seems too lacking in substance and arbitrary for my taste.

Proposal initiation

Ideas for adoption by the community are mostly posted to internals for discussion anyway so the only real change on the discussion side of things is to make an RFC wiki page a mandatory feature. However, requirements of and guidelines for RFC pages is completely glossed over (I’ll assume, because this is a voting RFC). Which proposals require an RFC, every single one? For minor changes, which for practical purposes an RFC might well be overkill, what place is there for a quick show of hands? Is that even to be considered/allowed at all? What place is there for the “scratch an itch” changes that core developers love to slide in to PHP? (Aside: itch scratching is the main reason I got involved!)

Discussion period

The minimum amount of “thinking time” is stipulated as follows:

• 1 week for RFCs that don’t “touch the language”
• 2 weeks for RFCs that do

What exactly constitutes touching is not totally clear, but the example given in the next section is of adding new syntax (compared to, lets say, a new function or class). Why those necessarily need double the amount of thinking time escapes me, as does why any RFC must require a minimum span of time between discussion on the mailing list (and elsewhere) and opening of the vote. What real problems does this period solve? The numbers involved seem completely arbitrary and might as well have said 3 days, or 3 weeks.

Required Majority

Now, I’ll admit to having a love-hate relationship with this particular part of the RFC. I love the idea of everyone having equal say from 15-year veteran of PHP to the brightest sparkly new face, to those who haven’t yet even ventured into the land of PHP internals discussions. As an idea, it gives that warm, fuzzy feeling.

However, I also believe that we’re not all equal. My vote should certainly not carry the same weight as those who have many contributed orders of magnitude more to the language that I have or will, those who, in the past, may have vetoed proposals even with strong “yay” votes. I like the idea of having people who can say, “no, that’s a crap idea and I won’t allow it.” Of course everyone (everyone!) should be encouraged to give their own two pence, but if the likes of Rasmus, Zeev, Andi, or individual extension maintainers are dead against (or dead for) something then that has to mean more than, for example, my vote. Right?

Resurrecting Rejected Proposals

I don’t have much to say on this point. Giving previously rejected proposals another chance sounds fair enough to me, the wants and needs of the community does tend to sway over time. If a rejected proposal is improved enough to be “substantially” changed then it is likely not the same proposal at all so none of the old votes would be on the topic of the new, changed proposal anyway.

Who can vote

Everyone who uses PHP! Oh, no, wait, sorry that’s just impractical. Everyone who has committed code to PHP! Oh, no, wait, sorry that’s just too few. Hmm, everyone who has written a framework! *sideways glare*

I still have no idea of who we’re voting for being allowed to vote. My conclusion is: whoever can be bothered signing up for a wiki account and following the required “hey, I’m not a robot” procedure.

Conclusion

The aim of this RFC is to put in place a process to replace the old “+1″ emails on the internals list. That system had its problems, mostly in the shape of finding all of the votes to tally them! In the same way, I think that the proposed system also has problems which the RFC does not even attempt to provide direction or solutions, and also has solutions where there aren’t problems.

Release Process

As with the other RFC, I really do kind of agree with the sentiment of this proposal; it would be nice to have neat, tidy, regular releases (to know an addition will be publicly available within a year would be a nice incentive). My main disagreement with this RFC is that we were expected to give a single yes/no vote on… well, multiple things.

Releases Cycle

I’m no expert on release cycles in open source projects, so comparison with what works elsewhere is beyond me. The proposed yearly release cycle (for major versions) with 3-year lifetime seems super-duper short for PHP, as does a monthly (or less) cycle for minor releases, but if folks think it will work great then lets run with it. I do worry however about having too many plates to keep spinning. One of the illustrations shows 5 separate branches being actively developed concurrently. I don’t know if that is a lot, or a drop in the ocean compared to other projects, but tackling just a couple of branches at any one time seems more than enough work for PHP at the moment.

Feature selection and development

There is not much to say for this section. The idea is that RFCs and wiki votes is the way forward. However it does add to the list of questions that we’re supposed to provide a single vote for/against. The topic of who can vote should have been decided during discussion (and a previous vote!), and the proposal updated to reflect that. We can’t say “yes” to, “Who will be allowed to vote?”

RMs Role

Apparently, they won’t be allowed to decided which non-bug-fix changes get to go into a release. So much for, “hey, that’s still super-buggy lets keep working on it for a while.” I believe a release manager should have the final say as to whether any individual feature is ready to go into a release. The RFC doesn’t make this clear, but it certainly sounds like once something has been committed, it will be in the next release; at least, there is no mention of anyone (community decision or otherwise) agreeing whether a feature is ready or not.

Release managers selection

The idea here is that pairs should put themselves forward as RMs, and we should vote them in. Are there really so many pushing to become RMs? I have not been around the core for too long but I’ve certainly not seen an over-abundance of volunteers for the role. This particular proposal sounds like needless faff.

Feature(s) preview release, solving the experimental features

Harking back to an earlier section, the aim here is to provide “feature preview” releases so that new features can get some more thorough real-life testing/use by brave folks before hitting a normal release. As with above, there is no scope for “whoa, this really isn’t ready yet” or even “what were we thinking?!” whatsoever. On the plus side, more testing is a very good thing.

Security Management

This section gets a big thumbs up from me, even though not being able to read the security-related bugs is a personal annoyance. How this relates to the rest of the RFC in any way is questionable, but I like it.

Conclusion

As with the other RFC, the general theme is certainly something I will support. However, the devil is in the details and in this case so is my disagreement with what is, and isn’t, being put on the table here.

And finally

The primary reason for this post is not to start some long-winded discussion on the above, merely to document my varied thoughts. If any discussion does come of it, then that’s great but I will probably run away and hide if people start getting all outspoken.