For those of you who lost these proposals in the flood of RFC related emails of 
recent days, here they are again:

---

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.
For this reason, I propose the following:
- 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.
- 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.
- 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.

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.

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.

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.

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.

Zeev


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to