Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93318
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.217.169 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <dc3acf18-f95c-8ea6-c854-1154fa947d0e@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>
Date: Fri, 13 May 2016 11:06:21 -0700
Message-ID: <CAESVnVp+dqH9NvDJfb-2Ou48Af3Ef808x_6nucc=Jsmkj6XxGQ@mail.gmail.com>
To: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@php.net>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs
From: pollita@php.net (Sara Golemon)

On Fri, May 13, 2016 at 7:26 AM, Fran=C3=A7ois Laupretre <francois@php.net>=
 wrote:
> Le 13/05/2016 =C3=A0 15:30, Rowan Collins a =C3=A9crit :
>>
>> If somebody adds something that is genuinely irrelevant (e.g. based on a
>> simple misunderstanding of the RFC) then somebody else (*anyobdy* else)
>> could remove it.
>>
>
> Maybe I am not candid enough but do you imagine what it could become on a
> controversial RFC like STH ? What does 'genuinely irrelevant' mean ? Will
> you accept that someone deletes your comment because he finds it 'genuine=
ly
> irrelevant' ? Of course not. So, we'll end up with a system where anybody
> can write anything and nothing can be removed. IMHO, we touch the limit o=
f
> what can be done with a bare wiki.
>
I want to start by acknowledging this totally legitimate concern.  We
can get heated sometimes, and I wouldn't put it past one or more of us
(maybe me?) to deface someone else's argument out of spite.

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.

This isn't actually much different than what we have now, since we all
have the (technical) rights to edit anyone's RFC.  I've done so on a
few occasions, without asking the author, to fix minor wiki formatting
and typo errors.  The extra step being suggested is just explicit
permission to do so in one specific subsection with an implicit
expectation of adding to the conversation.

> Another way to solve this need would be to authorize voting as soon as
> discussion starts and allow an explanation comment to be associated with
> each vote. People could modify their vote and the associated comment whil=
e
> discussion runs, and it would be easy at any time to get a snapshot of th=
e
> current trend and a resume of the raised arguments. This would also allow
> RFC authors to know better why people were voting the way they did,
> something that was requested several times in the past. Unfortunately, I
> don't know if we can associate a free comment with the voting tool we're
> using. This could require writing a new vote app.
>
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.

-Sara