Hi Theodore, śr., 12 sie 2020 o 18:36 Theodore Brown <theodor...@outlook.com> napisał(a):
> On Wed, Aug 12, 2020 at 10:25 AM Sara Golemon <poll...@php.net> wrote: > > > On Wed, Aug 12, 2020 at 9:48 AM Theodore Brown wrote: > > > > > It has just come to my attention that this RFC was rushed to vote > > > after less than the minimum two week period required after it was > > > brought up on list. Furthermore, discussion was still very active at > > > that time - I certainly didn't have a chance to respond to some of > > > the emails before voting began. > > > > > > Joe first announced this RFC on Tuesday, July 28 at 9:47 AM, and the > > > vote was started this Monday at 3:41 AM, less than 12 days, 18 hours > > > after the announcement. Per the voting rules: > > > > So, 30 hours short of 2 weeks. I'm going to ascribe good intentions > > in trying to get the issue resolved in the minimal timeframe. The > > fact active discussion was ongoing makes this a questionable choice, > > but in my opinion, purely on a matter of time, quibbling over 30 hours > > is splitting hairs. Maybe compromise on adding time to the vote end > > period so that the total is greater than 4 weeks? > > > > > What should be done to prevent this rule from being violated? > > > > Vigilance. You're right to raise the concern. And let's wag a finger > > over it at least. If others agree that it's premature, we can stop > > the vote, but I'm not inclined to disrupt the process over such a > > small variance. > > On top of violating the minimum two week discussion period, I believe > this RFC also breaks the rule on resurrecting failed proposals. When > I authored the Shorter Attribute Syntax RFC, I specifically did not > include a voting option for `@:`, since this syntax was declined, > and my understanding was that a six month waiting period is required > before resurrecting rejected proposals. [1] > > But if we can vote again on `#[]` and `<<>>` after they were declined, > why can't we also vote again for `@:`? This syntax has the advantage > of being equally short as `@@` without any BC break. > > I'm really disappointed and disillusioned with how the process has > been handled for this RFC. It seems like the rules are arbitrarily > going out the window in order to keep voting until the desired result > is reached. > > What is the point of having rules if they aren't followed or enforced? > If anyone else is troubled by the precedent being set by this RFC, > please vote No on the primary vote. I'm not sure what other recourse > we have at this point. > > Sincerely, > Theodore > > [1]: https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals You hint to the fact of shorter discussion period and the fact that you haven't got time to respond to all discussions while if you take a closer look on ML [4] that is obvious that discussion in fact began earlier and it's 3 weeks from now and to avoid insinuation you replied to it [5] 3 weeks ago as well. You blame others for breaking rules which in fact are not broken. IMO you think they're broken cause of your own interpretation. Rejected features have nothing to do with a re-vote on a syntax change at least this is how I understand this. Besides you already mentioned this argument on ML [1] so we can argue actually if a re-vote on syntax change is actually resurrecting a declined proposal since it was not a standalone proposal which got into a declined section of RFC's index [2] and yet you did it again! You blame others for "abusing" the RFC process while you've brought to us an RFC with a significant ambiguity [3] which you haven't mention and it turned out after closing a vote. Personally I think that it was your huge failure to bring the previous @@ syntax change RFC up to the voting without checking it's correctness. I'm personally also disappointed with the fact that in your RFC under the primary vote question "Are you okay with re-voting on the attribute syntax for PHP 8.0?" removing features like grouping ability was hidden. Personally I think you're forcing to stop the re-vote cause of mental connection to your previous @@ RFC and trying hard to find an argument against the re-vote. >From the results which are available so far, it can be seen that your proposed syntax is no longer the leading one. I understand it fully cause I'd be upset as well. >From my own experience, I know that as a RFC author there has always be a place to just let it go cause you won't always get to convince 50+ voters to your PoV. Cheers, Michał Marcin Brzuchalski [1]: https://externals.io/message/111218#111254 [2]: https://wiki.php.net/rfc#declined [3]: https://externals.io/message/110640#110819 [4]: https://externals.io/message/111101#111101 [5]: https://externals.io/message/111101#111132
