Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102772
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.208.171 as permitted sender)
MIME-Version: 1.0
References: <CAL=_i_ngW=NOe=T8VKReF7ov-3OhRM228QFZyWfg5aWPw9uSdQ@mail.gmail.com>
 <c5fb1d3e-e31a-88b5-a2fa-c87dd8471c39@gmail.com>
In-Reply-To: <c5fb1d3e-e31a-88b5-a2fa-c87dd8471c39@gmail.com>
Date: Wed, 11 Jul 2018 12:35:18 -0600
Message-ID: <CAFMT4NpTcbfAbfSwrxcKvSSCJcZZ9DRU+B6HieG+j=s9A=Zviw@mail.gmail.com>
To: Stas Malyshev <smalyshev@gmail.com>
Cc: Joe Watkins <krakjoe@php.net>, internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] abolish narrow margins
From: levim@php.net (Levi Morrison)

On Wed, Jul 11, 2018 at 12:19 PM Stanislav Malyshev <smalyshev@gmail.com> wrote:
>
> Hi!
>
> > We discussed it a year ago, and discussion died down to nothing (possibly
> > because it was sidetracked); If there are no objections I'll bring it to
> > vote in the coming days ...
>
> I tend to agree with the sentiment, but not 100%. I think there are two
> kinds of changes - one kind is more fundamental than the other. I.e., if
> we add a major feature to the language (like strict type checks, for
> example) it is going to have major influence on the language and
> virtually everybody using it. You can't just ignore it. This also goes
> to changes which alter ways that the syntax works, etc. which have
> potential to break existing code (even if it's bad code, still).
>
> Then there are more "neutral" changes - like adding an utility function
> or an option to a function. PHP has a lot of "syntax sugar" functions
> and sometimes even "kitchen sink" functions - ones that most people
> don't use but some do. Having one more would not be that big of a deal -
> that's where, unlike the above, "what you don't use doesn't hurt you" is
> true.
>
> You probably have guessed already what I am getting at - the second kind
> is probably OK to have 50%+1, since people that don't need this
> option/function can vote no but still we can have it if more people do.
> The counter-argument could be that people that don't need it can just
> avoid voting, but then we don't have clear boundary between "I don't
> think it's useful for enough people to add it" and "I am on vacation and
> haven't bothered to even have an opinion".

If it's a utility function and somehow ~49% of voters oppose it...
think about that. It's 49% objectionable! I don't think that should
pass, not even for a utility function people.

> That said, I'd love to see how many of the accepted RFCs we have now
> were actually accepted by margin between 50%+1 and 2/3 and what they
> are, if the number is very low maybe it's irrelevant. Unfortunately I
> don't have time to do it myself soon, but it would be super-awesome if
> somebody did.

I did this analysis in the past. There are very few RFCs that passed
in this window between 50%+1 and 2/3, but there are a few. The
array_key_first/last RFC is on track to pass in this region.

> P.S. The question of quorum is interesting to explore, though I am not
> sure how we figure out the numbers.