Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107748
MIME-Version: 1.0
References: <CAF+90c-k6SXe9yiqbrUUgwcmz9mtfnQty5_BqxFDgcU-sWEvuA@mail.gmail.com>
In-Reply-To: <CAF+90c-k6SXe9yiqbrUUgwcmz9mtfnQty5_BqxFDgcU-sWEvuA@mail.gmail.com>
Date: Sat, 2 Nov 2019 19:40:56 +0100
Message-ID: <CAOwTYAu-S4P57oyOHU_h82unytx-_Og=X_Yi6wW1Euoi++Zd2Q@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000edb2c50596616c1d"
Subject: Re: [PHP-DEV] GitHub RFC workflow
From: krakjoe@gmail.com (Joe Watkins)

--000000000000edb2c50596616c1d
Content-Type: text/plain; charset="UTF-8"

Evening Nikita,

This is not really what we imagined when we started to discuss using github
for pull requests - everything is going to end up on the wiki anyway.

I do think this is a very reasonable first step, given how the discussion
went on github and given the general feeling that we ought to "own" the RFC
content.

I would like to question the reasoning behind wanting to "own" the RFC
content: We don't require any such thing for any other kind of PR although
we say we require a patch on bugsnet, we actually don't require it. So, I
have a hard time telling the difference between a PR for an RFC and a PR
for a bugfix or enhancement.

Can anyone tell the difference ?

Having to move the content before voting starts satisfies the urge to own
the content, but it also creates an unnecessary step for the proposer which
translates to more noise for everyone.

Cheers
Joe

On Sat, 2 Nov 2019 at 17:32, Nikita Popov <nikita.ppv@gmail.com> wrote:

> 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
>

--000000000000edb2c50596616c1d--