Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104165
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=A2M1MbAie6U/fZ2tLPO8gm7mOiG+I37/PafkgFnsoGdk5agCBWyVilu5r6eySn
	RChDCI8ovz0N6Uvc4P7M2KhzlRz52sUZpKZRPFvTYrDl1xgfQb23U8/SQlxzVNUq
	W4v5pL220TE/xjNIB4sE9FUw+96R7amkxxoa3yYMb1Uwo=;
MIME-Version: 1.0
References: <03f401d4b96b$18b9dc60$4a2d9520$@php.net> <fd21deb6-d490-4d04-1449-6cd75a103b11@gmail.com>
In-Reply-To: <fd21deb6-d490-4d04-1449-6cd75a103b11@gmail.com>
Date: Tue, 5 Feb 2019 11:46:14 +0200
Message-ID: <CAJHtznxzTvAqjS-r7DaTBkzAoofmKAS0ETHMoPU6Ed5yAMZRXQ@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d9460c0581227b88"
Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
From: zeev@php.net (Zeev Suraski)

--000000000000d9460c0581227b88
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 4, 2019 at 10:56 AM Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> Reading the RFC, here's my thoughts:
>

Thanks for the detailed response!


> 1. Do we really need different classification of changes? I think having
> one single vote procedure would have larger benefit, and RFC that fails
> 2/3 requirement would be suspect anyway. RFCs can have parts - "whether
> we do it" and "how exactly we do it" - the former would be 2/3
> requirement, the latter can be simple plurality even - e.g. if we decide
> to have an extension for libfoobar, that should have 2/3 vote, but then
> decision between whether to name it foobar or barfoo can be decided by
> majority or plurality.
>

I think we do.  There are decisions where a 2/3 majority requirement makes
no sense, as the vote itself is about a choice between two options that are
on the table, as opposed to deciding whether to do something or not.
There aren't many such cases, but when they do occur - they tend to be
important.

The most obvious case I have in mind is that of the choice between PHP 6
and 7.  It doesn't expose us to any future commitments, doesn't change the
language - it's arguably almost a marketing decision.  Similarly, if we
decide to change our release schedule, I don't see why that should require
a 2/3 majority.  The 'bias for the status quo', which is the main reason we
have the super majority requirement to begin with, doesn't really play a
role here - as it bears no long term commitment.

2. The RFC deals simultaneously with two questions - whether vote is
> needed for certain changes and how the voting process is performed. I am
> not sure these issues should be handled together - they are
> substantially different.
>

Yes, that's something I intend to look into.


> 3. Requiring patch for each RFC is kinda high bar - if I propose some
> functionality, I don't really want to spend months on implementing it
> only to see it voted down and my time completely wasted.
>

This new workflow does not require an RFC for each patch.  It does require
an RFC for functionality that affects end users.
You do have a point regarding a scenario where you invest time into a patch
that then it ends up being rejected.  However, I think there are several
things to consider here:

- De-facto, most large RFCs actually come with an accompanied
implementation even today.
- In certain cases, the feasibility of implementation - and the ability to
do it in a reasonable, high performance way - are substantial parts of the
decision on whether to accept the RFC or not.
- Usually, it's possible to gauge the level of interest/acceptance even
before beginning work on the patch and/or working on the RFC.  This
workflow does not intend to replace all of the discussions on internals or
other avenues, and it may make sense to explicitly suggest in the workflow
to informally discuss the proposal with fellow contributors before
investing heavily in the implementation or RFC.
- Perhaps most importantly, I think it's very difficult to create a simple,
repeatable criteria to determine which end-user-affecting change requires
an RFC and which one doesn't.  Still, perhaps we can employ something like
Larry's approach - i.e., some sort of a "pre-RFC" stage where the author
asks for an 'exemption' from the full process for a small patch, and they'd
get it as long as there are no eligible voters opposing (say, 3 of them, or
whatnot).

>
> 4. I am feeling a bit uneasy about any change requiring a week's waiting
> period - read literally, that means you'd better not fix typos in your
> RFC if you don't want for it to take forever, and certainly not address
> feedback like "X is not documented enough" or "Y description could be
> clearer". I do think substantial changes require discussion and in some
> cases even full re-launch of the RFC but requiring a week's wait for any
> change, even the trivial one, seems going to far to me.
>

Again, here too drawing the line is difficult.  Typos are easy (although
certain types of typos can be quite strategic), but sometimes things like
further documentation may result in different levels of support for the
RFC.  That's why I like Larry's approach and would try to build it into the
workflow - small changes will be permitted to the RFC without resetting the
clock, but that's provided there's consensus that they're indeed small
(e.g.., fewer than 3 eligible voters object).

5. The RFC changes [VOTE] subject that we've used before to [RFC VOTE].
> I know it's a nitpick but is that change necessary? If people had
> filters to match such things, the change would break them and I'm not
> sure it improves anything.
>

Agreed, fixed.


> 6. I think we should allow longer voting periods than 1 week. In fact,
> I'd go as far as recommend longer minimum even, but even if we keep
> minimum of 1 week, there would be cases - holidays, conferences, sports
> events ;) - where a lot of people could be offline for prolonged time
> and 1 week won't be nearly enough.
>

I'm fine with going for a longer period of two weeks instead of one.
You're right that conferences and holidays may make a one week voting
period too short.


> 7. For the sake of clarity, we should define what 2/3 threshold means -
> is it:
> a) $voted_yes >= 2 * $voters / 3
> b) $voted_yes > 2 * $voters / 3
> c) $voted_yes >= floor(2 * $voters / 3) + 1
> d) something else?
>

Agreed.  I think that it should simply be $voted_yes >= 2 * $voted_no (or
in words, at least twice as many people voted yes vs. voted no).


> 8. 6 months seems a bit too long for rejected RFC. I'd probably shorten
> it to something like 2 months, maybe even less. But include the language
> that the feedback provided on the previous discussion stage should be
> addressed (of course we can't control it, but we can establish the norm).
>

I'm not sure about that one.  Perhaps we can set a certain bar (say, 60%
yes votes) above which - you're entitled to put the RFC back into a vote
sooner than 6 months.  But I very much want to avoid situations where the
workflow is left to the arbitrary decision of the author.

Another approach would be shortening that period, perhaps to two months,
but if it fails again - the 'hibernation' period would be longer (say
1yr).  I actually like that approach better.  Thoughts?

9. I'm not sure I understand the purpose of "RFCs that targeted the next
> mini version, and are moved back to the Discussion Stage after a
> Hibernation Period, may not target that same mini version" - why not?
>

Not sure I agree with my 2017 self either on this one.  Should probably be
removed (and would be moot if we go for the different 2 months / 1 year
approach).


> 11. 5 people to object to restart vote looks relatively high, and in
> fact the procedure looks rather complicated... Is it a frequent
> occurrence that needs special mention?
>

I don't think it's common, but it's important when it happens.  Here too,
I'm trying to codify things as opposed to just leaving them to the
arbitrary decision of the RFC author.
I'm not sure I understand your feedback regarding 5 people being too high.
Are you saying it should be enough for fewer people to object to a vote
restart for this to be denied?  Employing the approach of "whenever there's
doubt, there's no doubt", then perhaps even 3 people should be sufficient,
especially if we allow the RFC to be discussed once again after two months.

12. I think we need more work on eligibility criteria.


I agree.


> Specifically, I
> think we should aim for:
> a) including everybody who made contribution to PHP project in the past,
> if their contribution are recent or they plan to keep contributing
> (simple public declaration of intent should be enough). I am not sure
> yet if we need minimal conribution size - depends on whether it actually
> changes anything or not (should we make some tools that allow us to see
> what changes with and without minima?). I think the process should be
> biased to the side of inclusion - one more voter wouldn't hurt, but one
> person unjustly excluded from voting would feel very bad and it may lead
> to bitter discussions that don't help anything.
>

The devil is in the details.  The problem (that you acknowledge yourself)
is that we still need to set a bar regarding what constitutes contribution
to PHP.  First, are we talking about php-src?  I'd say yes.  Does a single
line of code qualify?  I'd say no.  Do two?  We need to set a certain
threshold, even though it will be arbitrary to a degree.

I do think that the current criteria is biased to the side of inclusion, as
it includes folks with huge variance in their levels of contribution.  At
the same time, we need to realize we're not talking about "one more voter",
but potentially dozens and even hundreds, depending on how we set the
criteria.

b) including important non-code contributors
>

This is tough, as I don't think we'll be able to come up with metrics.  As
I've mentioned elsewhere, I currently see two options here:
- Rely on the non-code-contributors participating in internals, and having
their opinions ultimately represented by code-contributors
- Have some sort of a process where the code-contributors elect a certain
number of non-code-contributors - coming up with a mechanism that we can
both agree on and can implement effectively will likely be mind boggling,
though

c) having the mechanism to periodically remove participants that have
> left the project and have no intent to contribute anymore, and to
> restore their voting eligibility if they come back
>

I think one way to do it would be disabling the right to vote for those who
haven't voted in the last 12 or 24 months.  It can then be reinstated
on-demand, but with a 'cool-off' period of 3 months - to ensure that folks
don't just periodically come to vote on specific RFCs when 'summoned' on
demand by their friends.  This will also serve to encourage people to vote,
if they want to keep their voting rights.

d) as I said before, I certainly do not feel comfortable with including
> all 50-strong PHP-FIG membership, and all future members, given that we
> have no say about how they are selected. We may want to think about
> mechanism to include their feedback somehow but current proposal seems
> to broad.
>

I'm going to remove FIG from the proposal for now, and replace it with a
question mark regarding a mechanism to include non-code-contributors.


> 13. Quorum question would be an interesting one to tackle. Some votes
> are being decided by very low number of votes, however I am not sure
> whether or not it's a problem...


Same here, I'm undecided on this.


Thanks again for the detailed and high quality feedback!

Zeev

--000000000000d9460c0581227b88--