Hi
Am 2026-06-16 21:33, schrieb Hendrik Mennen:
Reason for this: I’m native German and it’s easier for me to write an
answer with LLM instead of using google translator for words, which
don’t come to my mind.
The majority of participants on this list are not native speakers of
English. Personally I'm a native German as well. Minor grammar mistakes
or a sub-optimal choice of words is not a problem and something that
readers will just autocorrect. If there really is an issue with
something being completely incomprehensible, someone will ask a
clarifying question and usually rephrasing things will keep things
moving. I'd even say that simple language is preferable, because it
increases the chances that folks with varying English skills will be
able to understand what is being said.
LLMs are great at generating incredibly complex sentences with words
that sound smart, but that will make it harder for others, particularly
non-native speakers, to understand things without resorting to tooling
themselves.
If you are really struggling with expressing yourself in English, I
strongly suggest to write the texts in German and translate them to
English. Or write them in English and ask a tool to just correct the
grammar. From my experience DeepL is working well even for technical
texts. This will ensure the resulting message matches the tone and style
of how you would communicate.
All that said, the RFC text itself also appears to come straight from an
LLM. Notably is doesn't follow the RFC template at
https://wiki.php.net/rfc/template and the expected structure from an
RFC. Some important parts are missing. While following the template is
not strictly necessary, it is carefully designed to make sure to guide
authors through the process and make sure they don't forget anything. I
would strongly urge everyone to follow the template, unless they are an
experienced RFC author and have good reasons to diverge.
Specifically missing from your RFC is the “To the Ecosystem” section
from the “RFC Impact”. The voting widgets should also be set up right
from the start so that there is no ambiguity with how the vote will
look.
With regard to the contents of the RFC: The RFC should primarily contain
a factual description of the *user-facing* behavior of the proposal. The
value for a strong proposal should become obvious by itself.
If it is necessary to specifically argue against “counter-arguments”
within the RFC itself, it is likely that the proposal itself is not
sufficiently strong by itself. Specifically paraphrasing individual
counter-arguments from the discussion within the RFC and then “replying”
to the individual in question is not appropriate for the RFC text,
especially since this easily results in a biased representation by
accident. Discussing the merit of the RFC is what the discussion is for
and to make it easy for folks to find the discussion the reason why the
RFC policy mandates including a link to the discussion thread in the
archives (the link to this discussion is missing from the RFC, only the
pre-RFC discussion is linked).
Similarly, including implementation details within the RFC text is
typically not useful, because the implementation is likely to change
during review and literally is an implementation detail. What is
relevant is how the proposal affects users of PHP.
-----------
As for the proposal itself: I don't see value in trading `<?php` against
an additional `c` in the filename. And I also don't see writing `<?php`
as an issue at all. This discussion and the pre-RFC discussion probably
already spent more time than allowing to omit `<?php` will ever save.
If you want to proceed with the RFC, you should make sure to rework the
RFC to make sure it includes all the important parts from the RFC
template.
Best regards
Tim Düsterhus
