Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104099
To: Nikita Popov <nikita.ppv@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAF+90c-auGYVhCzt-1GpdU1-uZ+xiY7A_FwWSRKftuKBwtszYg@mail.gmail.com>
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: <f668d011-fdb6-987c-1fa0-25c7d58e2495@gmail.com>
Date: Sun, 3 Feb 2019 23:48:24 -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: <CAF+90c-auGYVhCzt-1GpdU1-uZ+xiY7A_FwWSRKftuKBwtszYg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> 1. There is no required discussion period. However, if an RFC vote is
> opened without leaving enough time for discussion, then voters can and
> should vote the RFC down on the grounds of insufficient discussion.

I don't think this is a good idea. I see no scenario it improves -
there's nothing in any RFC that can't wait for a week or two. However,
there can be then a situation where somebody sees something as obvious
and declares immediate vote, while others think it's not obvious at all
but by the time they get there the vote is already done. I see
absolutely no need to speed it up - the RFCs that ever got stalled
didn't get stalled because of mandatory discussion period. This tries to
solve a problem we don't have with something that may have bad
consequences.

> and require more time for an adequate discussion. Other RFCs are simple and
> of limited scope (such as an extension function addition) and do not
> require extensive discussion.

Yes, some RFCs are simple. But none of them are urgent. And frankly if
the proposed can't stay on track for two weeks

> While a two week discussion period should remain a good guideline for
> language-related RFCs, it is up to the RFC author to decide when opening an
> RFC vote is appropriate. This will depend both on the scope of the RFC

This is also not a good idea - I can easily see unexperienced RFC author
setting discussion period too short, because it's obviously a good idea,
people that didn't have time to understand the RFC vote no, as you
recommended, and then RFC fails not on merits but because of easily
avoidable process issue. Better to avoid it upfront.

> 2. There is no moratorium period after an RFC vote fails. If you think that
> you have made significant progress on an RFC and resolved the issues that
> made the previous vote fail, you can give it another shot at any time,
> without having to wait out some fixed period.

Obvious failure scenario is to submit the same RFC with minimal cosmetic
changes in hope detractors gave up or don't pay attention (either
explicit or implicit - i.e. genuinely thinking the RFC was fixed but not
actually fixing it) and essentially subverting the consensus. Coupled
with no minimum discussion period I think this can happen a lot,
especially given that many people don't have time to read all discussion
on all topics on the list in real time (I don't for example).

> A failed vote does not (necessarily) mean that a feature is not wanted. It
> is quite common for significant changes to fail on first vote, due to
> issues in the initial proposal. A failed vote should not be a
> discouragement, but a motivation to address problems expressed during
> discussion or voting.

True, but I don't see how having cooldown period contradicts this.
That's exactly when the problems have to be fixed. What's the point of
putting up for vote an RFC that just yesterday have failed a vote (your
reform allows this)?

> Essentially, this is about making the RFC process more suitable for changes
> small and large, and empowering both RFC authors and the voter base to make
> decisions that are appropriate for each RFC.

I do not see which decisions it enables that will improve the process.
So far I only see the decisions that if enabled would likely to lead to
more controversial decisions passing and more people being left behind
or unable to properly participate in the process.

-- 
Stas Malyshev
smalyshev@gmail.com