Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:52937 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84204 invoked from network); 5 Jun 2011 15:21:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Jun 2011 15:21:03 -0000 Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 74.125.82.54 mail-ww0-f54.google.com Received: from [74.125.82.54] ([74.125.82.54:46162] helo=mail-ww0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 58/6E-26000-3DE9BED4 for ; Sun, 05 Jun 2011 11:20:52 -0400 Received: by wwd20 with SMTP id 20so2864684wwd.11 for ; Sun, 05 Jun 2011 08:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=THIOBgJoN0nidx9swtXJiuRgKG1tdLMvdMUXUKcPsT0=; b=rxShb/H8NlhlhWBfj82bVxPNmQgTUEG8rJUy4mryEK2F1U4H5PecXivtjPjB6nADnk 4zLyZoD9smMN4PtMJvxEsUvBc5AEiJCs3Er39IQGZTKZjyrnByKz8TAJguUrtsgXfhAD wHEzJi29faOVA8kEwdi7pBQ2SJO7g8WrLUGD0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JBPAQtGjhsaXDPYfhFdfDovN4BKC2PvvMEdsYqCnJCZ9P154O6GgeiYH7LzNjiHkJO QV69iRcvcjDeBAF+i2Qwo0j2JRClh8C5EQuULKuhwIFYpTalBZfdkMHnR9hgJ8saauxj SR9gnPwmE/Y5v+BmIi8HIM8+dSpGlibwSXhAU= MIME-Version: 1.0 Received: by 10.216.134.66 with SMTP id r44mr1455899wei.92.1307287247871; Sun, 05 Jun 2011 08:20:47 -0700 (PDT) Received: by 10.216.253.168 with HTTP; Sun, 5 Jun 2011 08:20:47 -0700 (PDT) In-Reply-To: <887FE7CFF6F8DE4BB3A9535F53AFD06A493052EF@il-ex2.zend.net> References: <4DE7F179.5010402@sugarcrm.com> <4DE89534.5070206@sugarcrm.com> <4DE89CD2.4040302@sugarcrm.com> <4DE9AA9B.3000108@sugarcrm.com> <5D5F48EF-F7CD-424B-B3C6-6FA1E1412FA0@roshambo.org> <887FE7CFF6F8DE4BB3A9535F53AFD06A493052EF@il-ex2.zend.net> Date: Sun, 5 Jun 2011 17:20:47 +0200 Message-ID: To: Zeev Suraski Cc: Philip Olson , Stas Malyshev , Derick Rethans , PHP Internals Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward) From: pierre.php@gmail.com (Pierre Joye) On Sun, Jun 5, 2011 at 4:18 PM, Zeev Suraski wrote: > Some of you may have followed the twitter conversation that Pierre and I = had at the end of last week; =A0In 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 nee= d 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 mem= bers of internals@, and that there's enough time for the RFC to be discusse= d here on the list. =A0As Philip pointed out - an RFC is request for commen= ts, not a request for a vote. =A0This list isn't supposed to become some so= rt of a bureaucratic voting body, but where new ideas are discussed, refine= d, and eventually - accepted or rejected. =A0I realize that some here are w= orried that discussions can be endless, but we shouldn't go for the other e= xtreme 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 o= n this list and when it's voted on (say 2wks). =A0The effective date will n= ot be when the RFC was published on wiki.php.net/rfc - but when it was anno= unced on internals@, by the author, with the intention of voting on it. =A0= It doesn't matter if the RFC was up there for 2yrs, or discussed 20 times i= n the past - if the intention is to go for a vote, there needs to be time f= or a healthy discussion, as opposed to just yes/no. =A0 This will also allo= w 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. =A0Agai= n, the effective date will start from the time this email is sent to the li= st, 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. =A0That 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 afte= r 2wks, but after 3 or 4wks. =A0On the other hand, if he feels that the dis= cussion is being derailed - he can always move ahead to a vote as long as t= he minimum discussion time elapsed. > - In my opinion, only RFCs with active proposers should be discussed. =A0= If the proposer of an RFC is no longer leading the effort to get this RFC a= ccepted - 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 t= hat having someone announce a vote in a thread of 50 messages (or even 10) = messages is impractical. =A0It needs to be a separate thread, and it has to= be clearly marked - =A0a simple subject prefix like [VOTE] followed by the= title of the RFC should do. Agreed. > Thirdly, there's the voting mechanism itself. =A0The voting experience ha= s to be nicer than editing a wiki page, I think we all agree about that... = =A0The plugin Stas installed gets us something better than that, but ideall= y, if we could provide single-click URLs in the [VOTE] email itself for vot= ing 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. =A0It too has to be sufficien= tly long so that everyone has a chance to cast their votes, and on the othe= r end shouldn't be endless. =A0I 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. =A0Any mistake we make can take a decade to fix, because downwards = compatibility is such an important factor in PHP's design goals. =A0Taking = 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 discussi= ons 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, --=20 Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org