Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111512
To: Levi Morrison <levi.morrison@datadoghq.com>,
 "Paul M. Jones" <pmjones@pmjones.io>
Cc: Theodore Brown <theodorejb@outlook.com>,
 "internals@lists.php.net" <internals@lists.php.net>,
 Sara Golemon <pollita@php.net>, "carusogabriel@php.net"
 <carusogabriel@php.net>
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>
 <5cc837df-ab47-628a-d29b-46d7933be973@gmx.net>
 <BYAPR05MB653522F9123B59F7E066BDB8DE430@BYAPR05MB6535.namprd05.prod.outlook.com>
 <3A7CECC3-CDEE-4852-BF4B-4EC7CA1BD538@pmjones.io>
 <CAAKU0u=VYh7D+XJ93dDdAxdJ8nEU8iPfeN0f=Xv9Qm=cCQKX6w@mail.gmail.com>
Message-ID: <5e937e81-a51c-fcaf-abf7-47d297ab6105@gmx.net>
Date: Fri, 14 Aug 2020 11:47:46 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <CAAKU0u=VYh7D+XJ93dDdAxdJ8nEU8iPfeN0f=Xv9Qm=cCQKX6w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Subject: Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
From: a.leathley@gmx.net (Andreas Leathley)

On 14.08.20 03:41, Levi Morrison via internals wrote:
> I just want to make sure I understand: there are people who think we
> haven't discussed the syntax for attributes yet?
>
> I assume this is a serious email, but I can't fathom why anyone cares.
> We've discussed this subject soo much...

I am kind of new to the Internals discussions, which might be the reason
why I actually read through all the RFC process material, but I
recommend anyone to do so too. I will highlight the relevant parts as
succinctly as possible:

In https://wiki.php.net/rfc/howto - How to create an RFC - it says:

  * When your RFC is ready for discussion, change the status of your RFC
    page to "Under Discussion", and send an mail to
    internals@lists.php.net introducing your RFC.
  * Listen to the feedback, and try to answer/resolve all questions.
    Update your RFC to document all the issues and discussions. Cover
    both the positive and negative arguments. Put the RFC URL into all
    your replies.
  * When discussion ends, and a minimum period of two weeks has passed
    since you mailed internals@lists.php.net in step 4, consider one day
    heads up mail on the mailing list and then you can move your RFC to
    =E2=80=9CVoting=E2=80=9D status. There should be no open questions in =
the RFC.

The two weeks discussion period is specifically about the RFC itself,
not the discussion at large, which does make sense to me, as you discuss
a specific proposal and are trying to include all relevant information
into that RFC, so people voting on the RFC do not have to read through
all emails in Internals to get the information - it should be on the RFC
page. This is something objectively lacking with this RFC.

In https://wiki.php.net/RFC/voting - Voting on PHP features - it says:

  * Proposal is formally initiated by creating an RFC on PHP wiki and
    announcing it on the list.
  * There'd be a minimum of 2 weeks between when an RFC that touches the
    language is brought up on this list and when it's voted on is
    required. Other RFCs might use a smaller timeframe, but it should be
    at least a week. The effective date will not be when the RFC was
    published on the PHP wiki - but when it was announced on
    internals@lists.php.net, by the author, with the intention of voting
    on it. This period can be extended when circumstances warrant it -
    such as major conferences, key people being busy, force major
    events, or when discussion merits it - but should never be less than
    minimal time.
  * This does not preclude discussion on the merits on any idea or
    proposal on the list without formally submitting it as a proposal,
    but the discussion time is measured only since the formal discussion
    announcement as described above.

Here it also specifically mentions a discussion period of two weeks
after the RFC was created and announced on the list, yet it mentions it
can be only one week if it "does not touch the language". An RFC with a
syntax change would definitely touch the language in my opinion.

It also mentions again that the discussion period is after the
announcement on the list of the RFC - not after the discussion began
about the topic in general. The RFC has to exist and be mentioned with
the intent on voting on it.

Now, I don't know all the history of past RFCs, and maybe some of these
rules were not always followed, which someone alluded to in another
email. Yet in my understanding of the process, if nobody mentions that
timeframes were not heeded or that RFCs are incomplete, it seems likely
that there is already a large concensus around the topic, and nobody
cares about the details of the process. This is fine, and no harm is
done, although it might be good to remember the rules just to be consisten=
t.

If on the other hand people reference the documents that should steer
the RFC process and there is a clear violation of those, and if there
are multiple people who feel their points have not been included in an
RFC, then it makes sense to actually read through the RFC documents
again and follow them as intended, as obviously the intent of these
documents are different from what is happening.

Something else to point out, on https://wiki.php.net/rfc at the top it say=
s:

  * An RFC is effectively =E2=80=9Cowned=E2=80=9D by the person that creat=
ed it. If you
    want to make changes, get permission from the creator. If no
    agreement can be found, the only course of action is to create a
    competing RFC. In this case, the old RFC page should be modified to
    become an intermediate page that points to all the competing RFC's.

This might be an alternative, if the many discussion points are not
included in this RFC and it therefore remains incomplete, to make a
competing RFC. Not sure if this has ever been done, but it is on the
main RFC overview page, although it seems sad if that would be necessary.

I would like to mention that I would help any efforts to make this or
another RFC about a possible attribute syntax change as
information-complete as possible. For me this is not about the syntax,
but about properly thinking about the syntax (and discussing all
ramifications) and gathering as much information about each syntax and
its possible pros/cons/outcomes as possible. Many emails in Internals
have changed my mind in one way or the other, so that kind of
information not being included in the RFC will lead to people basing
their decisions on incomplete information, which seems bad to me.