Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120167
MIME-Version: 1.0
Date: Mon, 1 May 2023 12:20:45 +0100
Message-ID: <CAEKnhAEfQqNuk9Ah7OeyA756r5P1Z=iaqqEXAgr1kxTAbbvLmQ@mail.gmail.com>
To: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000042c86405faa004bc"
Subject: Current RFC process and project decisions
From: bukka@php.net (Jakub Zelenka)

--00000000000042c86405faa004bc
Content-Type: text/plain; charset="UTF-8"

Hi,

First of all the intention of this email is to try to clarify and later
better define the current RFC process and project decision processes. The
ultimate goal is to have a single document that would define project bylaws
and except other things be a guide for new contributors to quickly get an
idea how the project decisions are done.

Currently the RFC voting in defined in [1]. This defines all necessary
details about a discussion, proposing changes and voting. However it
doesn't say anything about the actual proposals so it can be more or less
anything impacting PHP. Also it doesn't say anything about implications of
the accepting of the idea (e.g. if it needs be merged) or when it should be
used.

There is another accepted RFC about release process [2] that defines better
for what RFC should be used. Specifically it states that it should be used
for the features in the following sentence:

> New features or additions to the core should go through the RFC process.

It is important to note that the RFC specifically states "SHOULD" and not
"MUST" which is something that has been probably applied to many smaller
features that didn't go through RFC over the years. It is not exactly clear
if this is actually allowed as there is a conflicting note regarding
release cycle that kind of says that the feature can get to the next
release as long as it gets accepted:

> The shorter release cycle also ensures that a given feature can get into
the next release, as long as the RFC has been accepted.

This could be taken that only RFC accepted feature can go to the next
release which kind of conflict with the "SHOULD" above.

As you can see it's pretty vague and not exactly something that has been
really accepted in practice. The fact is that there is also no definition
of the feature so if we took it to the extreme, it could mean any technical
change would also need an RFC. I think we all agree that would be really
inconvenient so that's something that we should probably better clarify.

We then have rules for RMs but they are mainly based around releases. I
think it would be good to define that part as well but will leave it aside
for now as it is much clearer and less impacting the core development. The
only important thing to note is that RM decides about bugs going to the
release.

It seems that in the current definition, the RFC is just for blocking
rejected features to get to the next release rather than requiring accepted
features to be in the next release. It means if the RFC is accepted, it can
get to the next release but it does not mean that it must get to the next
release. Obviously if RFC is rejected, it means that it cannot get to the
next release.

The implication of that is that to fully accept the feature, it requires
someone to merge it and no one to revert it... It means it requires some
sort of consensus between core developers or at least no objections from
some core developers. This is largely undefined as almost always the core
developers would follow the decision in RFC but technically there is
nothing in our process that would require them to do so.

In terms of conflicts between developers, the RFC does not even have much
meaning because of the above. It could be used just as some sort of poll
and honour the decision as such but it has no deciding factor in it.

This is at least how I understand the linked RFCs so please comment if you
think that the analysis is incorrect or I missed anything. I think it would
be good to define this somewhere so we can potentially make tweaks into it
in the future.

The idea is to maybe create a single document in the wiki collecting both
linked RFCs with extended clarifications and maybe mirror it in git so the
future proposal are easier to do.

Thoughts?

[1] https://wiki.php.net/rfc/voting
[2] https://wiki.php.net/rfc/releaseprocess

Cheers

Jakub

--00000000000042c86405faa004bc--