Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107767
To: Nikita Popov <nikita.ppv@gmail.com>
References: <CAF+90c-k6SXe9yiqbrUUgwcmz9mtfnQty5_BqxFDgcU-sWEvuA@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <4bac49ae-7a21-5e25-19f7-e284f89cea40@telia.com>
Date: Tue, 5 Nov 2019 20:28:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c-k6SXe9yiqbrUUgwcmz9mtfnQty5_BqxFDgcU-sWEvuA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] GitHub RFC workflow
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

Den 2019-11-02 kl. 17:32, skrev Nikita Popov:
> 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
Hi Nikita,

I think this is a good proposal trying to achieve a balance and also 
showing some
prudence, which in my eyes don't hurt.

My impression from the RFC discussion on Github is that it was good for 
the nitty
gritty details, but getting the overall picture on the discussion was 
more difficult.

Looking back I feel it was more valuable during the discussion phase, 
but after it
I only go to the wiki to read up on the RFC. Having a threaded news 
reader also
helps catching up on old discussions (using thunderbird).

Another aspect to consider is that RFCs have a lifespan after they are 
approved,
by being used in different books, tutorials etc. Also when doing 
migrations I often
go to the wiki to check on which RFC in which release that generated 
warnings in
the code, e.g. countable RFC. I do like the simplicity and accessibility 
of the wiki.

r//Björn L