Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111503
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2008100935570.7489@singlemalt.home.derickrethans.nl>
 <BYAPR05MB65355FFBB6717491995EEBF4DE420@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CAESVnVqraG9V4VMrxrv5AOFX5Jt7Cx0-uo5L0doQEWcUVOdHkg@mail.gmail.com>
 <BYAPR05MB65356FCC029CD06F49F528A0DE420@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CABdc3WobP1HSRwcujd4=o4wv3QUp7gDT12KmMRQU1_wLj4YLuQ@mail.gmail.com> <BYAPR05MB65351C807797676BB08D8BDCDE430@BYAPR05MB6535.namprd05.prod.outlook.com>
In-Reply-To: <BYAPR05MB65351C807797676BB08D8BDCDE430@BYAPR05MB6535.namprd05.prod.outlook.com>
Date: Thu, 13 Aug 2020 15:39:27 +0200
Message-ID: <CABdc3WrovMT3VrM4opzOyxjYq83taEdfG=N07X9=8O3O+BoCng@mail.gmail.com>
To: Theodore Brown <theodorejb@outlook.com>
Cc: Sara Golemon <pollita@php.net>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008a0ccd05acc26f59"
Subject: Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--0000000000008a0ccd05acc26f59
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Theodore,

czw., 13 sie 2020 o 15:17 Theodore Brown <theodorejb@outlook.com>
napisa=C5=82(a):

> On Thu, Aug 13, 2020 at 3:13 AM Micha=C5=82 Marcin Brzuchalski <
> michal.brzuchalski@gmail.com> wrote:
>
> > Hi Theodore,
> >
> > =C5=9Br., 12 sie 2020 o 18:36 Theodore Brown <theodorejb@outlook.com>
> napisa=C5=82(a):
> > > On Wed, Aug 12, 2020 at 10:25 AM Sara Golemon <pollita@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 o=
f
> > > > > 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 finge=
r
> > > > 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.
>
> Hi Micha=C5=82,
>
> The discussion thread you're referencing did not announce an RFC. Per
> the voting rules, a "Proposal is formally initiated by creating an
> RFC on PHP wiki and announcing it on the list". After that there must
> be a minimum two week discussion period before voting starts. The
> Shorter Attribute Syntax Change RFC failed to meet this requirement.
>

True, but you cannot disagree that you knew about the discussion coming soo=
n
and yet it was 3 weeks ago.
True that the announcement was delayed but TBH for me, discussion began
earlier
and we argue about that while more than 43 votes who voted yes in the
primary vote
had no hard feelings about it.


> > 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!
>
> So you're saying that the rule on resurrecting failed proposals only
> applies to primary votes, and not secondary votes? So if a secondary
> vote fails it's okay to vote for it again and again until the desired
> result it reached? This is not my understanding of the rules.
>

Agree. This is how I understand this and this is my personal opinion on
that.

> 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.
>
> It was correct as far as we knew at the time. Anyway, this issue was
> fixed before the @@ syntax was merged, and I don't see its relevance
> to this discussion.
>

I do not hint to the fact that the issue was accidentally fixed due to
another planned RFC.
The thing I do hint about here is the fact that the RFC even got into
voting with an
ambiguity issue and that's a failure of RFC's author.

This proves RFC authors make mistakes all the time and since this vote
being
in the vote for couple of days have so much yes votes on primary poll prove=
s
that mistakes to some degree might be forgiven.

In case of your mistake AFAIK nobody asked you to withdraw accepted RFC
after
a mistake made by you was found, right?

> 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.
>
> I don't follow you. The grouping feature for <<>> wasn't even accepted
> yet when the Shorter Attribute Syntax RFC went to vote. One of the
> primary motivations of the Shorter Attribute Syntax RFC was to reduce
> verbosity and remove the need for two different syntaxes (grouped and
> non-grouped) for declaring attributes. It was also discussed on list
> how @@ is equally or more concise without grouping:
> https://externals.io/message/110355#110414. Finally, the Attribute
> Amendments RFC itself explicitly stated that the grouped attribute
> feature "would be superseded by any other RFC getting accepted that
> changes the syntax."
>
> Attribute grouping makes some sense to help reduce the verbosity of
> the @[], #[], and especially <<>> syntaxes, but with @@ there is no
> need for the extra complexity since it is equally concise without it.
>
> > 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.
>
> If it was just a matter of my personal syntax preference I wouldn't
> be having this discussion. I was fine with voting on #[] originally
> and included it as an option in the Shorter Attribute Syntax RFC.
>
> What I have a serious problem with is breaking rules to arbitrarily
> vote again in the hopes that this time voters will choose #[] even
> though it was declined in the last vote. Moreover, the current RFC
> does not fairly present all the pros and cons of each syntax, and
> the requests of myself and others to include additional important
> details in the RFC about the BC breaks and other considerations have
> not been heeded.
>
> What is happening here is wrong, and because I want the best for PHP
> I have to stand up to it.
>

Here we agree. I also do want the best for PHP!

Cheers,
Micha=C5=82 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
>

--0000000000008a0ccd05acc26f59--