Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52965
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.199.177.89 as permitted sender)
To: Zeev Suraski <zeev@zend.com>
CC: PHP Internals <internals@lists.php.net>
Thread-Topic: Voting Process (was: [PHP-DEV] Re: Voting does not belong on
 the wiki! (Was: [PHP-DEV] 5.4 moving forward))
Thread-Index: Acwju4mMVI/geX/lRt2X0REy1lGzywAARK8g
Date: Sun, 5 Jun 2011 20:11:15 +0000
Message-ID: <887FE7CFF6F8DE4BB3A9535F53AFD06A493060F5@il-ex2.zend.net>
References: <887FE7CFF6F8DE4BB3A9535F53AFD06A4930609E@il-ex2.zend.net>
In-Reply-To: <887FE7CFF6F8DE4BB3A9535F53AFD06A4930609E@il-ex2.zend.net>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: Voting Process (was: [PHP-DEV] Re: Voting does not belong on
 the wiki! (Was: [PHP-DEV] 5.4 moving forward))
From: zeev@zend.com (Zeev Suraski)

For those of you who lost these proposals in the flood of RFC related email=
s of recent days, here they are again:

---

First, we need to make sure that the RFC is properly evaluated by the membe=
rs 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 t=
hat discussions can be endless, but we shouldn't go for the other extreme o=
f 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 b=
e when the RFC was published on wiki.php.net/rfc - but when it was announce=
d on internals@, by the author, with the intention of voting on it.  It doe=
sn'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 h=
ealthy discussion, as opposed to just yes/no.   This will also allow for pe=
ople 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, t=
he 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 th=
e RFC.  That means that if the author feels that there's still healthy disc=
ussion going on, he can decide not to move ahead to request a vote after 2w=
ks, but after 3 or 4wks.  On the other hand, if he feels that the discussio=
n is being derailed - he can always move ahead to a vote as long as the min=
imum discussion time elapsed.
- In my opinion, only RFCs with active proposers should be discussed.  If t=
he proposer of an RFC is no longer leading the effort to get this RFC accep=
ted - it should either find a new proposer, or it should be abandoned.

Secondly - the announcement of the vote - I very much agree with Derick tha=
t having someone announce a vote in a thread of 50 messages (or even 10) me=
ssages 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 ya=
y 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 en=
d 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 i=
sn't.  Any mistake we make can take a decade to fix, because downwards comp=
atibility 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, es=
pecially if we have rules and predefined schedules - so that discussions ca=
n't drag forever.

Zeev