On Sun, Jun 5, 2011 at 4:18 PM, Zeev Suraski <[email protected]> wrote:
> Some of you may have followed the twitter conversation that Pierre and I had at the end of last
> week; In my opinion, this dry (or partially wet) run that we had in the last few days of a voting
> process pointed to several deficiencies that need to be addressed in the RFC release process that
> need to be addressed before we move on.
Fully agreed and it was the case for the array stuff and a consensus
is clear here, and in favour of one the proposals. To make the point
straight.
> First, we need to make sure that the RFC is properly evaluated by the members of internals@,
> and that there's enough time for the RFC to be discussed here on the list. As Philip pointed
> out - an RFC is request for comments, not a request for a vote. This list isn't supposed to
> become some sort of a bureaucratic voting body, but where new ideas are discussed, refined, and
> eventually - accepted or rejected. I realize that some here are worried that discussions can be
> endless, but we shouldn't go for the other extreme of having no discussion.
Right, that's why we have draft, on discussions status and we should
add a vote status. Maybe clearly document that as well on the main
RFCs page to avoid badly proposed RFC to end in a voting phase too
early or at all.
> - There'd be a minimum amount of time between when an RFC is brought up on this list and
> when it's voted on (say 2wks). The effective date will not be when the RFC was published on
> wiki.php.net/rfc - but when it was announced on internals@, by the author, with the intention of
> voting on it. It doesn't matter if the RFC was up there for 2yrs, or discussed 20 times in
> the past - if the intention is to go for a vote, there needs to be time for a healthy discussion, as
> opposed to just yes/no. This will also allow for people who are attending conferences, are on
> vacations, etc. - not to miss an entire discussion/vote.
Agreed.
> - The announcement will be done in a way that's easy to flag & follow, e.g. - by [RFC]
> in the subject line followed by the title of the RFC. Again, the effective date will start from
> the time this email is sent to the list, not any other time.
Afaict, it is the case already.
> - Eventually, it'll be up to the author to move ahead and call a vote on the RFC. That
> means that if the author feels that there's still healthy discussion going on, he can decide
> not to move ahead to request a vote after 2wks, but after 3 or 4wks. On the other hand, if he
> feels that the discussion is being derailed - he can always move ahead to a vote as long as the
> minimum discussion time elapsed.
> - In my opinion, only RFCs with active proposers should be discussed. If the proposer of an
> RFC is no longer leading the effort to get this RFC accepted - it should either find a new proposer,
> or it should be abandoned.
Yes, the authors should have the hand on the process, not some random
not related developers, while anyone could be able to help to push an
idea.
> Secondly - the announcement of the vote - I very much agree with Derick that having someone
> announce a vote in a thread of 50 messages (or even 10) messages is impractical. It needs to be a
> separate thread, and it has to be clearly marked - a simple subject prefix like [VOTE] followed by
> the title of the RFC should do.
Agreed.
> Thirdly, there's the voting mechanism itself. The voting experience has to be nicer than
> editing a wiki page, I think we all agree about that... The plugin Stas installed gets us
> something better than that, but ideally, if we could provide single-click URLs in the [VOTE] email
> itself for voting yay or nay that would be great.
It is the case now. We have a poll plugin installed. To be proven to
fulfill our needs but as far as I remember, moodle2 does the job
pretty well.
> Last, we need a predefined time for voting. It too has to be sufficiently long so that
> everyone has a chance to cast their votes, and on the other end shouldn't be endless. I think
> the 1wk should do.
Again, agreed. Deciding things between Friday evening and Monday
morning is simply not possible nor correct, for example.
> If there's anybody who feels that the minimum 3wks period is too slow, it isn't.
> Any mistake we make can take a decade to fix, because downwards compatibility is such an important
> factor in PHP's design goals. Taking a bit of time to discuss the merits and contents of each
> RFC is well worth it, especially if we have rules and predefined schedules - so that discussions
> can't drag forever.
Even more true for languages related RFCs, they are critical (and
irreversible) and we should proceed with much caution than anything
else.
I'd to say that I'm very happy to finally see such discussions
happening, let sort the base (99% is done by our existing RFC about
release process, let adopt it already!) and move on with 5.4.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org