Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104104
To: Zeev Suraski <zeev@php.net>, internals@lists.php.net
References: <03f401d4b96b$18b9dc60$4a2d9520$@php.net>
Openpgp: preference=signencrypt
Autocrypt: addr=smalyshev@gmail.com; prefer-encrypt=mutual; keydata=
 mQMuBE9mqaARCACFSqcGmNunkjQQu3X+yXnTmFeEkvM4JXZTOBdR8aEevNGmmFEfyvjaDjWi
 9hcwp4E/lYtC+P7VsVjM1OSX9eq0jC/lGL0ZyRXek+mNy0n5H1NSuTpf9Y18LMqhc4G+RU+L
 cNiZ9K0DJuOOvNLPxW7OHZguxb3wdKPXNVa2jyRfJAKm2uaJJMT1mTmFT9a0Q8SKr+mUrrJk
 uG0H2o6SzrKt8Wwoint1eh67zVsJaJtQFchnEZnlawIcqP2yC4nLGR3MkubowxoEBYCZet18
 aHVVRbvpG2Qtob8Lu5xrsGbmXymTkHTdpvkfcJFADa8MzOL90zOxXwbGfbIZOlh5En8jAQCX
 lfnx2eQL3BSW/6XANa51dbWiEp1d1BAkpGKtZvlk0Qf+M9WAi+9aXMe3xP5krxtgnRNUf2WN
 6Zdy2MxL1RRJCFbytLhl0ronC49BsGYVGshdEH8xhBbiIOJKuVZ/DTl9bEm7P9c7CC7iJyVC
 khUAhouH6xzZQNLR+RU+QebYzXypVfl99Qk7EdMmr/WAZCHLuvanyqepC5EBsa3VnAfQemSN
 oBeGBKWWLiOsPjvS72+y1z4RUMAfXHn4l/sFMt8zt7/74AmJPwZquV41p4mPO12V4+xPyc6R
 sB84sfsk2QVivU8w8AkvGQeYjXoz7Iwao95+fWteVzZ36KRQvUckP8pGjHlDXnHxJ0HI1I/k
 OBZSjwRwUf0dd73y6erPhbLk+gf+NdI3H9KGJBzG5/rVyWKwUeQ9d5ud4jTJRkQGvAP5pg76
 vEa9dogbpe4W5Z+0BfbiJSnQmQWSHiZddj/t33ptbup44Ck6ZTgdlmFYMLF1hR47PIZTDKER
 EuKYGci/vq8snZvEJP9YCw/TtiHcMdrMKcY/+Lp8lQO0GHLPB9glVhnC0db6l1Xpg1CMI8/R
 ozBMcij30EgATggC/y2zbiqAFoS9FN9nXPbe4phStqABEyeZ+nXudt7PUYTjVgcrqo8bHZCi
 sBobWC7OnKyUzxVxzUeuPkIfmZuzkLaMw2McQdvwwsNvQ0DzaLP30c1Xsm/7EIYJcOWpzlVJ
 5QrdmE0/BbQyU3RhbmlzbGF2IE1hbHlzaGV2IChQSFAga2V5KSA8c21hbHlzaGV2QGdtYWls
 LmNvbT6IegQTEQgAIgUCT2aqtAIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQL3lW
 vF2gS12XMwD9HuRIolSwIK77u8EY461y2u6sbX36n5/uo/LDQuxoi3sA/0MvpnvzOhv9Iufv
 vsZEj3E7i3h+iD5648YMwfTFCij+uQINBE9mqaAQCADfZPMpjZkkGZj3BY/7ApoLq4mwqzbh
 +CpLXwNn20tFNvSXfb8RdeXvVEb7Scx+W9qYpiaun2iXJgCVH8fgpZpR856ulT1q6uCG++CX
 ubEvip/eJkZl93/84h04KQJwsgOrAh0Om3OePRn8Pr+++0LNS0EL8uX/YHeTOGOnnmTqYTey
 SBVFdov6L4mepddfjekicKQqhL7mZh/xuq29JijT0uNNX8v4vDWQDu5dlAcdd+uB3gcXMD/P
 ginD11zp+6wtrWCm/+yBqpvDwXQX5PGUnwvbRfl7Ay3MmwmoXiecZMg0dwTSc7e0lhB4HGRH
 ZdBMJB4rHUVGdzqujK/ctOvrAAMFB/0Utb76Qe6sCMlHxVAmeE/fbo7Pi05btZ/x01r67dHf
 aMSP0riCKJ7M0OW+jAXtu9+z/BVnYisW67WWfxl2cS5tZDgiHgJARXWUOO72+sScHP8KQmTl
 1z16gyKbwY3SmyBkwcpOL35nhUWNLy93syPoY6sZUTikr2bZYukHDQ33XBPs4e6MbWKfsa9q
 aVmnlOF3k5UqChjutfHaEa4Q7VP4wBIpphHBi9MI16oJIzzBPbGl2uoedjwiZ6QeQZnSuOVY
 ZxU2d3lRA8PrtfFN1VSlpEm/VcAvtieHUYWHN0wOu+cp3Slr5XJVNjTjJhl28SlinMME54mK
 AGf2Ldr/dRwXiGEEGBEIAAkFAk9mqaACGwwACgkQL3lWvF2gS126EQD/VVd3FgjLKglClRQP
 zdfU847tqDK4zJjbmRv5vLLwoE0A+wbrQs7jVGU3NrS0AIl5vUmewpp2BKzSkepy23nWmejw
Message-ID: <fd21deb6-d490-4d04-1449-6cd75a103b11@gmail.com>
Date: Mon, 4 Feb 2019 00:56:48 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0)
 Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <03f401d4b96b$18b9dc60$4a2d9520$@php.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

Reading the RFC, here's my thoughts:

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.

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.

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.

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.

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.

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.

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?

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).

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?

10. I like the idea of no discussion during vacation time - though,
frankly, I've been using some vacation days to catch up with Internals
in the past...

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?

12. I think we need more work on eligibility criteria. 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.
b) including important non-code contributors
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
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.

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...

Probably will have more, but it's long enough for now :)
Also, I realize the above has a bit of a negative tint because I have
mostly addressed things that I disagree with or think may be improved,
so I want to explicitly state that I think it's great we are discussing
these things, and explicitly thank Zeev for working on it.
-- 
Stas Malyshev
smalyshev@gmail.com