Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120010
Message-ID: <acf8591f-ce94-4014-39d3-ab4f7afe11ad@bastelstu.be>
Date: Thu, 13 Apr 2023 01:01:46 +0200
MIME-Version: 1.0
To: PHP Developers Mailing List <internals@lists.php.net>
References: <CABigaAUZAC-UgcajT5anUFJOxzTxMzNip34Jcst16A23ogpSLQ@mail.gmail.com>
 <CAGBsUreRuvZUPbjH-q_qkLyHv2PQHWe2VVg=uLrNNign9mtG=g@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAGBsUreRuvZUPbjH-q_qkLyHv2PQHWe2VVg=uLrNNign9mtG=g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Moving PHP internals to GitHub
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 4/12/23 23:39, Kamil Tekiela wrote:
> I love this idea. Although GitHub is not perfect, it would be so much
> better than a mailing list. [...]
>
> But unfortunately, if it came to a vote, I would vote NO. The mailing list
> must remain IMHO. It's terrible and annoying but it's also very simple and
> ubiquitous. And that's what is needed for inclusivity. A lot of senior
> developers prefer this kind of communication method so if we asked them to
> switch over we could lose them. Not to mention people who have no access to
> GitHub because of sanctions. It's the ubiquitousness of email that makes it
> the best tool for the job even if it's actually terrible for technical
> discussions.
> 

If the comparison is between "Mailing List" vs "GitHub Discussions", I 
agree with you. Both of these options are "extremes", though. A possible 
middle-ground option that also was mentioned on GitHub would be a modern 
web forum software.

First things first in the interest of disclosure: I'm employed by 
WoltLab, a company that develops commercial (PHP-based) apps for 
community management ("forum software"). My first PHP RFC 
(SensitiveParameter for 8.2) was developed on company time. After that 
successful RFC I continued participating on the list, mostly in my 
personal time. I'm writing this email in my personal time.

Personally I'm fine with participating on mailing lists. I also 
contribute regularly to another project (HAProxy) that primarily works 
with a mailing list. In fact when contributing external patches, the 
project doesn't use pull requests or some other software assistance. 
Instead patches are mailed around, like it is done with the Linux 
kernel. For the longest time they didn't even have an issue tracker, but 
they are now using GitHub Issues after I was sufficiently

However while my coworkers read the list via externals, I've been 
unsuccessful in encouraging them to also participate directly. Their 
area of expertise is different than mine and they would likely be able 
to also add valuable information that I am not able to add myself. Their 
reasons for non-participation are similar to the reasons already given: 
They don't feel comfortable with the email-based process.

Looping back to the initial paragraph of this email and because several 
participants expressed that one should not just look at the perceived 
advantages of a new solution I used the opportunity to summarize 
existing arguments (and adding my own). For the forum software, I'm 
using my employer's forum software feature set as a specific example, 
depending on the software the feature set might differ. Whether a 
specific point is a plus or minus might be debatable for some of the 
points YMMV :-) Points are listed in no particular order except for the 
prefix. Of course each of the points needs to be weighted with regard to 
importance.

Mailing List:
+ The mailing list already exists and it does the job ("No migration 
effort").
+ Emails can be read offline and replies can reasonably be composed offline.
+ Everyone with an email address is technically able to participate.
+ Users are free to choose an interface / MUA of their choice.
+ Full data Ownership (Message history is stored on PHP's infrastructure).
+ Easy to keep track of unread messages.

~ Search dependent on whether the email is in your local inbox (the 
archives are not easy to search)
~ A tree-based structure is the best option to discuss different 
subthreads, without everything being mixed, however some common MUAs do 
not support threading well, resulting in confusing threading for everyone.
~ The functionality is limited to plaintext emails. This prevents 
annoying stuff like colored emails, but at the same time forces folks to 
send "+1" emails for agreement or to not share their agreement at all.

- No categorization of different topics.
- Little to no moderation functionality.
- Messages cannot be edited.
- Very hard to reply to existing threads when newly subscribing.
- The common problems of emails apply (e.g. bogus rejections by 
overzealous spam filters).
- High barrier of entry (e.g. to set up proper filters).

GitHub Discussions:
+ PHP does not need to provide the infrastructure.
+ "Emoji Reactions" (as a weak signal to gauge agreement without 
creating notifications).
+ Polls (as a stronger signal to gauge opinions without creating 
notifications)
+ Messages can be edited (with edit history).
+ Low barrier of entry (many folks already have a GitHub account)
+ Threads can be grouped in categories.
+ Rich text formatting.
+ GitHub is not likely to go anywhere.

~ Search is not great (at least I often do not find the issues I am 
searching for, using Google does not really work either).
~ Supports sending notifications via email (it's not great, though)
~ Supports replying via email (it's not great, though)
~ Limited support for threading / response trees.
~ Limited moderation functionality.

- Cannot be used offline.
- Referring back to quoted messages becomes unwieldy in long discussions.
- Hard to keep track of unread messages.
- Not everyone is able to participate (US sanctions).
- Walled garden (specifically no useful way to migrate off GitHub 
without losing data and also no useful way to import existing history).

Web Forum Software (with "WoltLab Suite" as an example):
+ Full data ownership (Allows migration to a different solution and 
possibly allows importing existing history)
+ Everyone with a web browser and email address is able to participate.
+ Emoji Reactions (see GitHub)
+ Polls (see GitHub, but responses can also have a poll)
+ Advanced moderation functionality
+ Advanced categorization (Categories, Labels, Tags)
+ Rich text formatting
+ Messages can be edited (optionally time-limited with edit history)
+ Easy to keep track of unread messages
+ Good search (both integrated as well as via Google)
+ Role-based access-control
+ Can be extended with custom functionality

~ Lower barrier of entry (separate account is needed, social login is 
possible).
~ Supports sending notifications via email (limited compared to the web 
variant and only one email per subscribed thread until the thread is 
read within the browser).

- No tree / threading support (but quotes link to the original message).
- Dependent on smaller vendors (compared to GitHub / OSS mailing list 
software).
- No support for replying via email.
- Cannot be used offline.

? Running your own infrastructure is possible, but not required 
(software is available both on-premise and as a SaaS)

Best regards
Tim Düsterhus