Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107747
MIME-Version: 1.0
Date: Sat, 2 Nov 2019 17:32:17 +0100
Message-ID: <CAF+90c-k6SXe9yiqbrUUgwcmz9mtfnQty5_BqxFDgcU-sWEvuA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002df69f05965fa137"
Subject: GitHub RFC workflow
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000002df69f05965fa137
Content-Type: text/plain; charset="UTF-8"

Hi internals,

Now that the union types RFC is drawing to a close, I think it's time to
discuss the question of RFCs in GitHub pull requests again. Overall I'm
fairly pleased with how this went and would like to adopt the process in
some form.

In particular, I would like to start with the following fairly limited
proposal:

 * RFCs may still be submitted directly against the wiki, using GitHub is
optional. For small and straightforward proposals this might be easiest.
 * After an RFC pull request has been opened against the GitHub repository,
the RFC needs to be announced on the internals mailing list.
 * Before voting starts, the proposal must be mirrored to the wiki (as is
now done with https://wiki.php.net/rfc/union_types_v2), and the vote is
held on the wiki.
 * Once voting ends, the RFC pull request on GitHub is closed (not merged)
with an Accepted or Declined label.

Unlike what I had originally in mind, this keeps the PHP wiki as the ground
truth: All proposals must be moved there in entirety before voting starts.
The GitHub pull request is just a means to make it easier to iterate on the
RFC prior to arriving at the finalized proposal.

In the future we may decide to abandon this approach with very little cost
(as the actual proposals are all in the wiki), decide to adopt it more
broadly (forgoing the wiki entirely) or decide to try a different approach
(such as one repo per RFC, similar to ECMAScript RFCs).

Thoughts?

Regards,
Nikita

--0000000000002df69f05965fa137--