Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106900
MIME-Version: 1.0
References: <CAF+90c8EvfFPqjRJjJ3T-qTfLiWn7aZzCrGpk7R3yNFLT1qWjQ@mail.gmail.com>
 <1686643.PblvKQRnJp@mcmic-probook> <190b7291-812e-4337-bd09-950dc30c655a@Spark>
 <2157489.0uZv62oTo4@mcmic-probook>
In-Reply-To: <2157489.0uZv62oTo4@mcmic-probook>
Date: Fri, 6 Sep 2019 16:47:52 +0200
Message-ID: <CAF+90c8cBwXrdmfpBz6=Kt3ZM+X5fmVU+S+Op0JNhSEQ-GT4jQ@mail.gmail.com>
To: =?UTF-8?Q?C=C3=B4me_Chilliet?= <come@opensides.be>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c836e30591e3863f"
Subject: Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000c836e30591e3863f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Here are my own thoughts on how the pull request discussion for union types
went...

I think the main takeaway for me is that inline comments (on specific lines
in the RFC) were really invaluable. Each comment thread discussed a
specific issue and most of them have resulted in a direct improvement to
the RFC.

Generally there was a lot of discussion of specific technical details that
we very rarely see in RFC discussions. Current RFC discussions on the
mailing list tend to be rather high level (which is fine in itself), with
nobody ever discussing the details (which is very bad).

Thinking back to https://wiki.php.net/rfc/engine_warnings, I think that RFC
could have really benefited from this discussion medium. While the mailing
list discussion ended up talking circles around more or less one single
question (undefined variables), pretty much none of the other parts of the
RFC have seen so much as a comment. I'm sure that there would be a lot more
discussion regarding specific classifications if this went up as a pull
request.

Another nice thing is that it's possible to mark a comment thread as
resolved, once the RFC has been adjusted to address the comments. That way
you don't have to see issues that were already addressed (though you can if
you like).

Having thumbs-up and thumbs-down reactions to comments was also helpful to
judge whether some comment represents a minority opinion or not, something
that is notoriously hard with current mailing list discussions (which are
almost dominated by "negative" opinions which mysteriously don't show up in
voting results).

However, while the inline comments were pleasantly insightful, the same
cannot be said for the top-level comments on the pull request. The majority
of them was borderline off-topic. While some in principle interesting
discussion happened there, it simply didn't belong in the RFC thread for
union types. The top-level comments also suffered from a lack of threading
-- I would have been less bothered about tangential discussions if they
were threaded. (To be fair: I use gmail, so I don't get threading on the
mailing list either.)

If this kind of discussion behavior is representative, then I would suggest
a workflow alone the following lines...

* RFCs are submitted as PRs on GitHub, but must be announced on the mailing
list.
* The PR description should have a fat warning that top-level comments
belong on the mailing list. We can mark all top-level comments on PRs as
"off-topic" as a matter of general policy.
* Top-level commentary stays on the mailing list.

This is a shift from what I originally had in mind (completely moving the
RFC process to GitHub), towards providing a way for more detailed and
specific feedback on the RFC text.

Regarding GitHub as a 3rd party. I think there are a few things to
considered:
 * We're already very heavily reliant on GitHub. Most of my day-to-day
interaction with PHP core development is via GitHub and most of the
day-to-day decisions also happen there. Only the major stuff everhits this
mailing list.
 * The RFC repo would of course be hosted on git.php.net as usual and only
be mirrored to GitHub.
 * GitHub would not be the exclusive venue for RFC discussion. All RFCs are
still announced on internals and the top-level discussion can and should
still happen here.

Disclaimer: I'm trying to draw conclusions here from an experiment with a
sample size of 1, which may not be representative. Union types are a pretty
significant proposal (and also the first one to be on GH), and other,
smaller proposals might well have different discussion dynamics.

Regards,
Nikita

On Thu, Sep 5, 2019 at 12:22 PM C=C3=B4me Chilliet <come@opensides.be> wrot=
e:

> Le jeudi 5 septembre 2019, 12:04:55 CEST Brent a =C3=A9crit :
> > > Huge "no" from me on using github for discussing RFCs.
> >
> > Care to elaborate why? The majority seems to like it. Though I am also
> curious about Nikita's experience with it, as he is the one having to
> process the feedback.
>
> Because the PHP project should avoid depending on a privately owned
> centralized service for its technical discussions, and should not encoura=
ge
> (some would say force) people to use such platforms.
>
> PHP is already on github but it=E2=80=99s only a mirror, the main git rep=
ository
> is at git.php.net .
>
> C=C3=B4me
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--000000000000c836e30591e3863f--