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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php