Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119968
MIME-Version: 1.0
References: <CABigaAUZAC-UgcajT5anUFJOxzTxMzNip34Jcst16A23ogpSLQ@mail.gmail.com>
In-Reply-To: <CABigaAUZAC-UgcajT5anUFJOxzTxMzNip34Jcst16A23ogpSLQ@mail.gmail.com>
Date: Wed, 12 Apr 2023 17:45:10 +0300
Message-ID: <CAL0xaBHSGhLD8npPsNnaaz7SKk_rHWWTgs6uoBOX25BObQHCJQ@mail.gmail.com>
To: autaut03@gmail.com
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000038916d05f924a936"
Subject: Re: [PHP-DEV] Moving PHP internals to GitHub
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--00000000000038916d05f924a936
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 12 Apr 2023 at 16:53, Alex Wells <autaut03@gmail.com> wrote:

> Hey.
>
> PHP currently uses internals@lists.php.net for communication. That
> includes
> mostly RFCs (or their votings, or their pre-discussion) and sometimes
> questions about the implementation or possible bugs.
>
> While emailing definitely works, it's not the best UX out there. Here are
> some immediate flaws which make the process harder than it should be:
>  - having to subscribe to a mailing list to even see the discussions
>  - supporting public archives such as externals.io to expose discussions
> to
> the public for those who aren't subscribed and keep historical data
>  - having to learn the specific, uncommon rules of replying: bottom
> posting, word wrapping, removing footers. It's not to say any of those
> rules are complex or hard to follow; it's that they're basically
> inapplicable outside of emails, so they're usually not known by newcomers=
.
> Also popular emailing clients don't do any of that automatically, making
> each reply tedious.
>  - no way of editing a message. Mistakes will always be made, so being ab=
le
> to quickly fix them would be nice
>  - no formatting, especially code blocks. Sure, they are possible through
> HTML, but there's no single common way which all of the emailing clients
> will understand - like Markdown
>  - no reactions - it's hard to tell whether something is supported or not=
.
> This includes both the initiative being discussed and the replies that
> follow. Sure, you can usually kind of judge the general narrative based o=
n
> the replies, but it's not always clear what's in favor. There are usually
> many divergent branches of discussions and it's unknown what's supported
> the most.
>
> Based on those issues and PHP, I propose moving the discussions elsewhere=
 -
> to some kind of modern platform. Since this is quite a big change in the
> processes used, I imagine an RFC would be needed. But before I do that I
> want to measure the reactions. If it goes well, I'll proceed with an RFC
> draft.
>
> There are basically two choices here - a messenger-like platform (i.e.
> Slack, Teams) or a developer focused platform like GitHub. While messenge=
rs
> certainly work, they're more focused on working with teammates rather tha=
n
> actual discussions. They usually don't have a simple way to navigate
> publicly and are poor at separating multiple topics into threads. Some
> projects use them for that purpose, but it's usually a worse experience
> than what GitHub provides.
>
> GitHub is already used by PHP for both the source code and the issues, so
> that is a good candidate, especially since it's a platform designed to
> handle cases like this. Also, that should be a much easier transition now
> that the source and issues were moved to GitHub.
>
> Also, to be clear: I'm not proposing to remove all PHP mailing lists; som=
e
> of them are one way (i.e. notifications for something) so they should
> definitely stay that way. Some of them might not even be used anymore.
> However, I want this change to affect all two-way (discussion) mailing
> lists if possible. Also, this does not include moving RFCs themselves to
> GitHub, only the discussion that happens via email.
>
> What are your thoughts?
>

One major flaw is: Not everyone has a Github account. And never will.
Because to access the code on it one does not require an account on it.
And GitHub is owned by a corporation, a corporation is beholden to a lot of
laws and restrictions and which means they have to comply with all kinds of
things, including sanctions. Like there are people who write on this list
who are caught up in recent big sanctions and their GitHub accounts were
disabled/deleted because they can't have those. But they can access the
public side of the site and write on this email.
And speaking from experience I know from people I know directly who were
affected by it all - leaving the country did not save them from a lot of
their accounts being suspended. Even those who already lived outside those
countries for a while - because they were a citizen of a specific country
despite having a permit in a European country and living there for a few
years, their account was blocked anyway.

Any big OSS project should have control over its channels and infra to a
degree that if some platform goes away - it does not die overnight. GitHub
is a great place for feedback, and discussions, but not for the formal
process of the PHP Internals. It needs to be independent of any
organisation as much as possible.
--=20

Arv=C4=ABds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

--00000000000038916d05f924a936--