Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93320
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.53 as permitted sender)
To: Sara Golemon <pollita@php.net>, =?UTF-8?Q?Fran=c3=a7ois_Laupretre?=
 <francois@php.net>
References: <CAESVnVqAYFZ8qoPe=jgbwaCT3azS6rn_Rb2Hx_Q4=JAYf0zLaA@mail.gmail.com>
 <1d8d5c0c-0403-7e9e-5b93-56de43648c99@php.net>
 <7119991e-415f-20e3-22e8-5f6a68df0e34@gmail.com>
 <dc3acf18-f95c-8ea6-c854-1154fa947d0e@php.net>
 <CAESVnVp+dqH9NvDJfb-2Ou48Af3Ef808x_6nucc=Jsmkj6XxGQ@mail.gmail.com>
Cc: Rowan Collins <rowan.collins@gmail.com>,
 PHP internals <internals@lists.php.net>
Message-ID: <8c7872c3-c7c0-e2df-c61f-912ca6eb3527@gmail.com>
Date: Fri, 13 May 2016 11:36:58 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0)
 Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <CAESVnVp+dqH9NvDJfb-2Ou48Af3Ef808x_6nucc=Jsmkj6XxGQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> BUT, these Wikis have a history log.  And if John Smith removes or
> maliciously modifies an argument I've introduced, I'll notice, and
> I'll be the first to ask for a public explanation of why he chose to
> do so.  Maybe they were right to do so, maybe they weren't.
> Regardless, that'll put social pressure on one of us to shape up.
> Similarly, anyone spamming RFCs with irrelevant arguments can be
> brought to task on by anyone else for doing so.

I agree. The fact that we are having the RFCs is a proof that this
strategy works well enough - all the sides of the RFC have commit
access, so we could just be committing the code into the repo and
reverting and making the mess out of it. But we aren't because we
realize that's not how the things should be done. In the same way, we
can agree about how the things are done inside RFCs, and while we
definitely will have argument and controversy, I have full confidence we
will be able to manage it within reasonable bounds - because we already
are.

> Even if not done in a pre-vote period, I would love the OPTION of
> adding an explanation for votes.    I'm a bit more on the fence about
> declaring voting intention ahead of time though.

This can be - and is - done in the list discussion. I don't see much
value in having permanent record of voting intent on the RFC beyond the
vote itself.

OTOH, this is roughly how the voting is done in Wikipedia and sister
projects - you place a vote (either positive, negative or you can also
abstain) and usually a short description. Which can be as short as
"agree with N." or "I don't think this is right" or much longer and
result in a discussion and sometimes even change of vote. But usually
long discussion in votes is discouraged. It is also not easy to keep
track of it because whole discussions on wiki implementation is meh.

I do not know if this system is superior to what we have - very well may
be not - but just bringing it forward that such system exists and if
interested, you can observe it in action.

-- 
Stas Malyshev
smalyshev@gmail.com