Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93321
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.161.173 cause and error)
MIME-Version: 1.0
In-Reply-To: <8c7872c3-c7c0-e2df-c61f-912ca6eb3527@gmail.com>
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>
	<8c7872c3-c7c0-e2df-c61f-912ca6eb3527@gmail.com>
Date: Fri, 13 May 2016 21:56:11 +0100
Message-ID: <CAL=_i_=M14trnB_SP+0sVXM7PUzmjC-wnibXi_T5U3UExwvNtg@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Sara Golemon <pollita@php.net>, =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@php.net>, 
	Rowan Collins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c0775bc374fb20532bf8116
Subject: Re: [PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs
From: pthreads@pthreads.org (Joe Watkins)

--94eb2c0775bc374fb20532bf8116
Content-Type: text/plain; charset=UTF-8

Evening,

    I like the idea that we should pay more attention to setting out
arguments, for and against.

    Still, I regard editing someone else's work as poor form.

    Introducing a way to do that, and relying on social pressure to keep
everyone in check is not a good long term plan ... sounds great, until
someone actually does make an edit that the original author vehemently
disagrees with.

    Can't we just require the section to be included by the original
author(s) ?

Cheers
Joe


On Fri, May 13, 2016 at 7:36 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--94eb2c0775bc374fb20532bf8116--