Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:90621 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52294 invoked from network); 13 Jan 2016 16:26:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jan 2016 16:26:50 -0000 Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.27 cause and error) X-PHP-List-Original-Sender: larry@garfieldtech.com X-Host-Fingerprint: 66.111.4.27 out3-smtp.messagingengine.com Received: from [66.111.4.27] ([66.111.4.27:53958] helo=out3-smtp.messagingengine.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 48/B3-34116-8CA76965 for ; Wed, 13 Jan 2016 11:26:49 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 87B1F2249E for ; Wed, 13 Jan 2016 11:26:46 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 13 Jan 2016 11:26:46 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=SFPOsKYe6SGCGax sjclcf03XzME=; b=tMBtFTqy1b4GZWwRcWDij8F3o7wDMa8iYvaw0K9Myubq04f YvTX1GV2pVmEC3S6ITkL9a2ltkk+OVhofG3MWeq2yH4NpgchhOEXyUJBca9QH4Qo rz8i2l81RxF+do61mOERiz2tUl0fQdZUgmIGlBFBQR8L0j9lqSx8QwKozOlg= X-Sasl-enc: DGfuLMTKiqDvLtrIZ/pU3DniVwXCziJRRS0Uf7qrZ2Ai 1452702406 Received: from Crells-MacBook-Pro.local (unknown [63.250.249.138]) by mail.messagingengine.com (Postfix) with ESMTPA id 4A485C016F0 for ; Wed, 13 Jan 2016 11:26:46 -0500 (EST) To: internals@lists.php.net References: <5690BCE6.6010908@gmail.com> <569182FD.6070404@gmail.com> <56918458.1070101@gmail.com> <5691D2EA.1050808@gmail.com> <5692307D.5050900@lsces.co.uk> <56925977.1040801@dennis.birkholz.biz> <5693C027.4070804@eliw.com> <5694D270.3050109@dennis.birkholz.biz> <56950882.7020008@eliw.com> <56950BB4.7040400@heigl.org> <56952323.5030201@php.net> <56965B9D.5060200@php.net> Message-ID: <56967AC5.8050708@garfieldtech.com> Date: Wed, 13 Jan 2016 10:26:45 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <56965B9D.5060200@php.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] Re: Anonymous voting on wiki From: larry@garfieldtech.com (Larry Garfield) On 1/13/16 8:13 AM, François Laupretre wrote: > >> yeah, that(discussion only seems to happen after introducing the voting >> phase) is frustrating for the rfc author, but that is the last phase >> where >> complaints can be voiced and most people have a tendency to defer stuff >> until the last minute, that sucks, but not specific to our project, and >> don't know what can we do about it. >> some of those last minute feedback are actually useful, so if we are >> looking for the best solution it i better to have those concerns to be >> raised and heard even if late than ignored and voted on a flawed >> proposal. >> I think one possible countermeasure can be to start the voting as >> soon as >> the discussion dies down (while still keeping the minimal discussion >> period) instead of waiting for more feedback arbitrarly and getting >> frustrated that it only comes after one puts the rfc up for votes. >> > > What do you think of the opposite solution : merge the discussion and > voting phases, e.g. allow voting as soon as discussion starts ? This > discussion/vote phase would be required to last at least 1 month. > People could either vote early and, maybe, change their vote if the > discussion makes them think otherwise, or wait for others' arguments. > The big difference would be that the RFC could be amended during this > discussion/voting phase. It could be a way to avoid having to restart > the whole process from the beginning. > > Regards > > François Voting should never, ever be on something that's still in flux. Voting should be on a fixed, unmodified text so you know what you're voting on. Otherwise, something you're in favor of in its initial form may drift to be something else entirely that you don't like by the time the vote period ends, but since you already voted you're not paying close attention anymore. Which is the other problem: Once someone votes, they'll wander off. They won't wait to see the discussion, see if anyone has good points to raise (pro or con), wait to see if the text changes in a way that would change their vote (pro or con), or whatever else. Knee-jerk votes are generally uninformed votes, which is the last thing we want. -- --Larry Garfield