Everything

php

Home » Project » Newsgroups » php.internals » Moving PHP internals to GitHub »

Moving PHP internals to GitHub

php.internals

Alex Wells

3 years ago

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 able
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 on
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 messengers
certainly work, they're more focused on working with teammates rather than
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; some
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?

Marco Pivetta

3 years ago

FYI: https://externals.io/message/87501#87501

Also: wow, that was 7 years ago?! :O

Marco Pivetta

https://mastodon.social/@ocramius

https://ocramius.github.io/

On Wed, 12 Apr 2023 at 15:53, Alex Wells <autaut03@gmail.com> wrote:

Alex Wells

3 years ago

On Wed, Apr 12, 2023 at 4:57 PM Marco Pivetta <ocramius@gmail.com> wrote:

> FYI: https://externals.io/message/87501#87501
>
> Also: wow, that was 7 years ago?! :O
>

Thanks. I've completely missed this while searching for an alike thread :)

But as you mentioned, it's been 7 years. Many things and people have
changed. Particularly, PHP has already "vendor locked in" itself into
GitHub; and there's now a specific solution from them - GitHub discussions,
created specifically to tackle the issues with discussions in GitHub
issues. They're not perfect, but hey, neither are mailing lists.

Andreas Heigl

3 years ago

On 12.04.23 16:12, Alex Wells wrote:

> On Wed, Apr 12, 2023 at 4:57 PM Marco Pivetta <ocramius@gmail.com> wrote:
>
>> FYI: https://externals.io/message/87501#87501
>>
>> Also: wow, that was 7 years ago?! :O

That was exactly my thought as well...

>>
>
> Thanks. I've completely missed this while searching for an alike thread :)
>
> But as you mentioned, it's been 7 years. Many things and people have
> changed. Particularly, PHP has already "vendor locked in" itself into
> GitHub; and there's now a specific solution from them - GitHub discussions,
> created specifically to tackle the issues with discussions in GitHub
> issues. They're not perfect, but hey, neither are mailing lists.

The vendor lock-in is one of the biggest issues that I see with the
PHP-project.

Adding the main discussion platform to the locked resources is probably
not one of the best ideas.

Just my 0.02€

Cheers

Andreas

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org                                           |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas                               |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg                          |
+---------------------------------------------------------------------+

Alain Williams

3 years ago

On Wed, Apr 12, 2023 at 04:52:52PM +0300, Alex Wells wrote:

> 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.

Please: No.

The nice thing about email is that stuff just hits my mailbox and I deal with
it when I have time. I have my MUA (mutt) always running, I do not want to have
something else to monitor.

Your points:

* having to subscribe. An easy one off task.

* Archives: already done

* Having to learn rules, bottom posting. All communities have rules. As you
say: not hard

* Not way of editing: just send a follow up.

* No formatting. What is wrong with plain text, it is how PHP is written ?

* No reactions. If people are interested they will reply.

I agree that one flaw with email is that it is not good at remembering things,
that is why people do things like writing RFCs.

Note: I mainly lurk on this list, only occasionally making comments.

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>

Alex Wells

3 years ago

On Wed, Apr 12, 2023 at 5:09 PM Alain D D Williams <addw@phcomp.co.uk>
wrote:

> * Archives: already done

It is; however, there's no way to categorize it (except for creating even
more mailing lists), tag it, mark as resolved, close it or basically do
anything other than write a message.

> * Not way of editing: just send a follow up.
>

Well, an edit is certainly more convenient. On GitHub, it's also updated in
real time, so if you just sent it and someone's reading it, they can see
the change immediately, not having to "update" the view.

> * No formatting. What is wrong with plain text, it is how PHP is written ?
>

I'm not sure what you mean here by "is how PHP written". If you're
referring to PHP code, I doubt anyone's actually writing PHP without code
highlighting, style formatting, heredoc etc. It is formatted, although
technically it is still plain text. In that regard, so is markdown.

> * No reactions. If people are interested they will reply.
>

Well, you can't be replying to each reply you support - I don't think
spamming people with notifications is a good idea. Also on practice, I've
not seen such simple "Agreed" or "+1" kind of replies in the past few
discussions - probably because it's impractical.

Rowan Collins

3 years ago

On Wed, 12 Apr 2023 at 15:22, Alex Wells <autaut03@gmail.com> wrote:

>
> Well, you can't be replying to each reply you support - I don't think
> spamming people with notifications is a good idea. Also on practice, I've
> not seen such simple "Agreed" or "+1" kind of replies in the past few
> discussions - probably because it's impractical.
>

Reactions are a nice social media feature, but I don't think I've ever seen
them used to convey anything particularly meaningful.

If I write a comment that gets 3 smily faces, 4 angry faces, one rocket,
and one of those weird Japanese fireworks, all from people who haven't
otherwise participated in the conversation ... I'll just ignore them and
carry on.

It's certainly not a killer feature I'd uproot an entire community for.

Regards,

--
Rowan Tommins
[IMSoP]

Pierre

3 years ago

Le 12/04/2023 à 16:29, Rowan Tommins a écrit :

>
> Reactions are a nice social media feature, but I don't think I've ever seen
> them used to convey anything particularly meaningful.
>
> If I write a comment that gets 3 smily faces, 4 angry faces, one rocket,
> and one of those weird Japanese fireworks, all from people who haven't
> otherwise participated in the conversation ... I'll just ignore them and
> carry on.
>
> It's certainly not a killer feature I'd uproot an entire community for.
>
> Regards,

I sometime wish there was reactions thought. There's ton of message I
read I'd only wish to say "I agree" without sending a complete email
polluting the discussion for just this.

A simple up and down count would be great to visually assess how readers
receipt the message. For long and complex discussions about some
controversial RFC's this could have some kind of meaning.

It also could allow people to express they like an RFC independently of
any technical consideration, this could at least give some kind of
number of people interested in feature X or Y.

I'm not saying this list needs social network features, and I like it
being as it is, but yes, for RFC, it sure lacks public opinion surveys,
easy ones I mean, ones that anyone can stumble upon easily and say "I
want it", "I don't want it" or "I don't care". There are millions of PHP
developers, and nobody never reaches them to take temperature about how
useful would be X or Y feature, and that's sad.

I guess some RFC's would probably move faster if the developer that
tries to push it explicitly knows that hundreds or thousands of people
are supporting it. It would also give sense to some hard and ingrate
tasks, and some explicit gratitude, recognition for the work done, it
could be very positive, and simply nice for the few PHP developers doing it.

That was my 2 cents about all this. Maybe what the thread creator mean
is simply that the PHP development process is kind of hidden in this
list, and it's not that easy to reach or read for people, even when
using https://externals.io/

Best regards,

--

Pierre

Alex Wells

3 years ago

On Wed, Apr 12, 2023 at 6:15 PM Pierre <pierre-php@processus.org> wrote:

> That was my 2 cents about all this. Maybe what the thread creator mean
> is simply that the PHP development process is kind of hidden in this
> list, and it's not that easy to reach or read for people, even when
> using https://externals.io/

Pierre has voiced exactly my concerns. The reactions are important exactly
because they allow to measure the reaction of everyone (incl. daily PHP
developers like myself), not just the voting group. I'm in no way implying
that those reactions should actually decide anything; yet, it's a nice
starting point. In the end, that's kind of the point.

tag Knife

3 years ago

On Wed, 12 Apr 2023 at 16:25, Alex Wells <autaut03@gmail.com> wrote:

> On Wed, Apr 12, 2023 at 6:15 PM Pierre <pierre-php@processus.org> wrote:
>
> > That was my 2 cents about all this. Maybe what the thread creator mean
> > is simply that the PHP development process is kind of hidden in this
> > list, and it's not that easy to reach or read for people, even when
> > using https://externals.io/
>
>
> Pierre has voiced exactly my concerns. The reactions are important exactly
> because they allow to measure the reaction of everyone (incl. daily PHP
> developers like myself), not just the voting group. I'm in no way implying
> that those reactions should actually decide anything; yet, it's a nice
> starting point. In the end, that's kind of the point.
>

Oftentimes community discussions are happening in parallel to the internal
discussions on the PHP reddit.
As is the same for this discussion, reading it is often useful to get
community input.
https://old.reddit.com/r/PHP/comments/12jrc8j/the_discussion_on_the_mailing_list_about_moving/

Reinis Rozitis

3 years ago

> Oftentimes community discussions are happening in parallel to the internal discussions on the PHP reddit.
> As is the same for this discussion, reading it is often useful to get community input.
> https://old.reddit.com/r/PHP/comments/12jrc8j/the_discussion_on_the_mailing_list_about_moving/

Sadly, there isn't anything useful being discussed just some people being upset about why someone doesn't (immediately) want to move to their [favorite] platform what gives even more validation for those who are against it.

p.s. also excuses like "gmail is making me top-post and that why I can't write to internals" make me sad .. what have we come to / what's in the future ..

rr

tag Knife

3 years ago

On Wed, 12 Apr 2023 at 19:00, Reinis Rozitis <r@roze.lv> wrote:

>
> Sadly, there isn't anything useful being discussed just some people being
> upset about why someone doesn't (immediately) want to move to their
> [favorite] platform what gives even more validation for those who are
> against it.
>
>
> p.s. also excuses like "gmail is making me top-post and that why I can't
> write to internals" make me sad .. what have we come to / what's in the
> future ..
>
> rr
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php

Im going to post a reply from reddit which I think encapsulates this
discussion

Posted by HappyPenguin on reddit

I say this as someone who was trying to onboard themselves the other day
(web-php and php-docs).
The entire process is archaic and uses "tools" from 20 years ago.
Onboarding for anything you're interested in doesn't really give a
direction at all (unless you're a dev).
It mostly boils down "do this, do that, after that figure it out yourself".
It really shows php's age that you have to join a mailing-list to even get
generic user support, let alone participate in development.

Php needs to get with the times, even something as simple as a forum would
be better than mailing lists for discussions.

Reading those responses from people really does not show a welcoming
environment and only puts off people from participating.
The guy may have gone about proposing the change the wrong way, but the
spirit is the same.
Modern users and devs are not going to take the time to join the mailing
list, introduce themselves, and then get possibly 60+ emails a day that
don't pertain to them.

I used to play a star trek RPG that was PBeM, then moved to Yahoo! Groups,
then moved to a software suite called SMS (Sim Management Something)
and last I checked, the group seemed to have moved to an entirely central
wordpress system.
Email lists are outdated and are no longer the right tool for the job in
99.9% of applications.

Look at the "Make WordPress" page compared to php's "Get Involved" page and
the overall onboarding experience is so much nicer and improved.
People can get a general idea of how teams works, their goals, who's
leading who,
with helpful guides and direction to get people started.


Also alot of comments about the internals terrible attitude towards the
author and to general change.

Maybe some reflection on your selfs of how the community perceives these
discussions, after all they are public.

Rowan Collins

3 years ago

On 12/04/2023 19:05, tag Knife wrote:

> I say this as someone who was trying to onboard themselves the other day
> (web-php and php-docs).
> The entire process is archaic and uses "tools" from 20 years ago.
> Onboarding for anything you're interested in doesn't really give a
> direction at all (unless you're a dev).
> It mostly boils down "do this, do that, after that figure it out yourself".

I'd like to draw attention to a non sequitur between the above, totally
valid criticism, and the below:

> It really shows php's age that you have to join a mailing-list to even get
> generic user support, let alone participate in development.

None of the above has anything to do with it being a mailing list per
se. You could have just as bad an experience trying to sign up for a web
forum, or a chat room, or something-something-blockchain-ai-javascript.

But to repeat: the complaints about the sign-up process are totally
valid. I don't know enough about the system involved to make them
smoother, but there's no reason signing up for a mailing list can't be
as simple as enter address, confirm address, done. By all accounts, the
PHP ones are not.

> Look at the "Make WordPress" page compared to php's "Get Involved" page and
> the overall onboarding experience is so much nicer and improved.
> People can get a general idea of how teams works, their goals, who's
> leading who,
> with helpful guides and direction to get people started.

I agree to a point. My first impression of the Wordpress page you
mention is that it's kind of overwhelming with the number of different
teams, and it's mostly a directory of Slack channels, I think? (Hurrah,
another Slack workspace to separately sign into on every device!) A more
apt comparison is probably to https://www.php.net/mailing-lists.php

What is probably lacking both there and the "Get Involved" page is a
more direct statement that Internals is the central communication hub
for the project. The mailing list page describes it as "A medium volume
list for those who want to help out with the development of PHP" which
is accurate but entirely unhelpful.


Which brings me back to my earlier point: I wonder how much of the
reaction is really about e-mail itself, and how much is just the
documentation and sign-up forms you encounter *before* you hit the list.
Because if it's the latter, migrating the entire community to a new
platform won't help - we'll still suck at introducing anyone to that
platform - and most of what we need is someone who's good with words to
update some website copy.

Regards,

--
Rowan Tommins
[IMSoP]

Derick Rethans

3 years ago

On 12 April 2023 19:05:56 BST, tag Knife <fenniclog@gmail.com> wrote:

>On Wed, 12 Apr 2023 at 19:00, Reinis Rozitis <r@roze.lv> wrote:
>
>>
>> Sadly, there isn't anything useful being discussed just some people being
>> upset about why someone doesn't (immediately) want to move to their
>> [favorite] platform what gives even more validation for those who are
>> against it.
>>
>>
>> p.s. also excuses like "gmail is making me top-post and that why I can't
>> write to internals" make me sad .. what have we come to / what's in the
>> future ..
>
>Im going to post a reply from reddit which I think encapsulates this
>discussion
>
>Posted by HappyPenguin on reddit
>
>I say this as someone who was trying to onboard themselves the other day
>(web-php and php-docs).
>The entire process is archaic and uses "tools" from 20 years ago.

PHP is 27 years old and the language it is written in is 51 years old. Lay it off with the ageism.

Cheers
Derick

Robert Landers

3 years ago

Hello,

Just dropping my unsolicited 2 cents...

A lot of big software development is done via email and not on
discussion boards like GitHub.

Here are some of the ones I lurk on:

- Chrome-dev

- Various linux kernel mailing lists

- Some random Mozilla one

- A NASA one from when I was doing some GPS stuff

- This list

If this list managed to move over to GitHub, it'd be the first 'big
list' I'm aware of to move to GitHub (does Alex work for GitHub? jk).
Email is one of the first and last forms of 'free, as in free speech'
types of communication on the internet and to give it up for 'likes'
and emojis would be kinda sad.

I enjoy reading my email on the train every morning and evening, and I
hope this list will stay in my email.

Cheers,

Rob Landers
Utrecht Netherlands

Christian Schneider

3 years ago

Am 12.04.2023 um 15:52 schrieb Alex Wells <autaut03@gmail.com>:

> 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.

…

> What are your thoughts?

Also see the recent thread at
https://externals.io/message/119757#119786
where there are some thoughts on the UX points (e.g. editing of messages).

Regards,
- Chris

Rowan Collins

3 years ago

On Wed, 12 Apr 2023 at 14:53, Alex Wells <autaut03@gmail.com> wrote:

>
> Based on those issues and PHP, I propose moving the discussions elsewhere -
> to some kind of modern platform.

This has been discussed before, many times, so I'll keep this brief and let
you find the old discussions.

I think "moving to a modern platform" presents a false dichotomy.

Any move needs to be assessed on both the advantages and disadvantages of
*both* (or all) options, not just what looks new and shiny if we move.

Some starting points off the top of my head:

* Ease of access (is subscribing to e-mail *really* harder than logging
into Github?)
* Notification of replies and new threads (I find Github pretty awful at
controlling e-mails and giving useful activity overviews)
* Handling of threads and sub-threads (at minimum, a tree view like a
decent e-mail client; preferably, ability for trusted users to split and
merge threads)
* Spam control

Regards,

--
Rowan Tommins
[IMSoP]

Alex Wells

3 years ago

On Wed, Apr 12, 2023 at 5:16 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> I think "moving to a modern platform" presents a false dichotomy.
>
> Any move needs to be assessed on both the advantages and disadvantages of
> *both* (or all) options, not just what looks new and shiny if we move.
>
> Some starting points off the top of my head:
>
> * Ease of access (is subscribing to e-mail *really* harder than logging
> into Github?)
> * Notification of replies and new threads (I find Github pretty awful at
> controlling e-mails and giving useful activity overviews)
> * Handling of threads and sub-threads (at minimum, a tree view like a
> decent e-mail client; preferably, ability for trusted users to split and
> merge threads)
> * Spam control
>

Agreed. Notifications might not be the strong side of GitHub, but there's a
way to filter discussion notifications (same as subscribing to the mailing
list) and subscribe/unsubscribe to a specific discussion only. There are
also threads with replies, although there are no sub-threads.

Lynn

3 years ago

On Wed, Apr 12, 2023 at 4:16 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> * Ease of access (is subscribing to e-mail *really* harder than logging
> into Github?)
>

Took me over a year and poking people on twitter before my mailing-list
sign-up worked, so I'd say that's a yes. I feel like this mailing list is
mainly a thing that works for people who have been using it a while and
have everything set up the way it works for them. Maybe I'm wrong, I just
don't consider the nature of mailing lists very accessible nor user
friendly.

In the end it seems to work for the current core contributors, not sure if
it works for future core contributors.

Lydia de Jongh

3 years ago

Hi,

Interesting discussion....
I do prefer a good organised forum above a mailinglist:

- better overview
- better searchable
- quicker to read
- less mail
- possibility to give likes

As a newcomer here, it is hard to find previous information. Even on
externals.io.

That signing on to the mailinglist is a little difficult is an advantage
for a list like this and at the other hand should not be a problem for a
developer...;-p

But Github would not be my choice for a forum.

Greetz,
flexJoly



Op wo 12 apr 2023 om 16:16 schreef Rowan Tommins <rowan.collins@gmail.com>:

Derick Rethans

3 years ago

On 12 April 2023 14:52:52 BST, Alex Wells <autaut03@gmail.com> wrote:

>What are your thoughts?

Not a chance. Also, who are you?

cheers
Derick

Andreas Heigl

3 years ago

Hey Alex.

On 12.04.23 15:52, Alex Wells 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.

Those rules are written down in
https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md and
are in essence a modified version of one of the main rules of the
internet https://www.rfc-editor.org/rfc/rfc1855

Yes: Most web-based mailinterfaces do not care about those basic rules
of the internet - why that is is a separate discussion - but there are a
lot of email-clients around that do care about those.

>   - no way of editing a message. Mistakes will always be made, so being able
> to quickly fix them would be nice

Email is no quickly written chat. You should read what you wrote, use
your spell-checker and be 100% sure that that is what you want to
express. That allows a much more clear and focused discussion as people
will make sure they have expressed what they wanted with enough time. It
also reduces the possibility of heated discussions (reduces! not
eliminates! (-; )

>   - 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

What do you need formatting for? And most of us can read markdown in
plaintext emails as well...

>   - 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 on
> 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.

It's a discussion. A :thumbs-up: is not helpful. And if you want to do
that: Send an email with exactly that.

The discussion lives from meaningful interaction. Not a thumbsup/down
echochamber

>
> 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 have been a number of discussions over the years and all came to
the conclusion that no other medium provided the means that the list
wanted - at that time. Apart perhaps from NNTP (Did I mention that the
mailinglists are available via NNTP? or at least should be. If not I
might have to check the colobus integration...)

>
> There are basically two choices here - a messenger-like platform (i.e.
> Slack, Teams) or a developer focused platform like GitHub. While messengers
> certainly work, they're more focused on working with teammates rather than
> 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; some
> 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?

I assume you already checked the mailinglist-archive and stumbled upon
https://externals.io/message/87501#87643

I might have missed the new takes that weren't discussed there or that
might have changed since that discussion.

At least apart from "there are a lot of new people around" and "the new
people don't want to learn the rules"

Looking forward to your TL;DR

Cheers

Andreas

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org                                           |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas                               |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg                          |
+---------------------------------------------------------------------+

Arvids Godjuks

3 years ago

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 able
> 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 on
> 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 messengers
> certainly work, they're more focused on working with teammates rather than
> 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; some
> 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.

--

Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

Peter Kokot

3 years ago

On Wed, 12 Apr 2023 at 15: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 able
> 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 on
> 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 messengers
> certainly work, they're more focused on working with teammates rather than
> 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; some
> 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?

I also prefer mailing lists in addition to 3rd party GitHub
environment. Professional and large open source projects all use such
mailing lists. These mailing lists include two decades of discussions
which is respectable to continue in such direction.

Lynn

3 years ago

On Wed, Apr 12, 2023 at 3:53 PM Alex Wells <autaut03@gmail.com> wrote:

> What are your thoughts?
>

I'd simply give you a thumbs up and 100 reaction if I could, but instead
I'm giving everyone an unread notification just showing that I 100% agree.

Stas Malyshev

3 years ago

Hi!

>   - having to subscribe to a mailing list to even see the discussions

Not really, there are archives.

>   - having to learn the specific, uncommon rules of replying: bottom

If learning a couple of very simple rules is too much for you, maybe you
are too busy to take on yourself another responsibility such as
participating in PHP development. Encouraging drive-by commentary is not
something that is a goal here.

>   - 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

If you have code to contribute, feel free to use pull requests. The list
is for discussion, and the short blocks appropriate in a discussion
would do fine with simple copy-paste.

>   - no reactions - it's hard to tell whether something is supported or not.

It's not Instagram. Collecting likes is not the goal. If the vote needs
to be held, we have the RFC process.

> Based on those issues and PHP, I propose moving the discussions elsewhere -

I am not really very active anymore on the development side but I would
say it would make it strictly worse to move the discussion. Especially
on Github which is not very suitable for such things - it is suitable
for sharing and managing code.

Also, there already are Slack channels for PHP - and you can create
another one if you feel like it (or a group on any other social
platform, if many existing groups are not enough).

> What are your thoughts?

Not a good idea.

--
Stas Malyshev
smalyshev@gmail.com

Alex Wells

3 years ago

On Wed, Apr 12, 2023 at 7:31 PM Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> If learning a couple of very simple rules is too much for you, maybe you
> are too busy to take on yourself another responsibility such as
> participating in PHP development. Encouraging drive-by commentary is not
> something that is a goal here.
>

I'm not sure why it's assumed that participating in discussions is the
same as actually developing PHP. I'm sure there are plenty of folks
subscribed to this list who have zero knowledge of C to actually help with
PHP development. However, that doesn't mean that their opinion, concerns or
proposals on some topics is invalid, invaluable or unneeded; at least, I
hope it isn't. Those are people who use PHP daily so it's fair to state
that they're inevitably a part of PHP, even though they might not be
directly helping with the source code. Is this the reason why internals
mails list is open to the public? So they the public can actually
collaborate on the open source product they're using?

> It's not Instagram. Collecting likes is not the goal. If the vote needs
> to be held, we have the RFC process.
>

"Likes" wasn't my intention. There's no point in wasting countless hours on
an RFC if it's clear ahead of time that it's not going to pass; and right
now, even within this thread, it's hard to predict that. And, voting aside,
there's no metric PHP can use to measure how relevant something is to PHP
as a project, regardless of the voting group's choice. While not perfect in
any sense, reactions provide a meaningful simple way of communicating this
relevance with a simple thumbs up/down.

Stas Malyshev

3 years ago

Hi!

>   I'm not sure why it's assumed that participating in discussions is the
> same as actually developing PHP. I'm sure there are plenty of folks

Right. And participating meaningfully requires some level of commitment
and investment. For example, willingness to familiarize oneself with
some very simple rules and follow them. If that's not for you, that's
fine - there are many other interesting things to do on the internet.
But it's not a problem.

> why internals mails list is open to the public? So they the public can
> actually collaborate on the open source product they're using?

Yes. And "collaborate" means mutual labor. Part of the labor on the site
of the new participant is to get familiar with the rules of the
community. They are not very hard, extensive or complicated. Very little
effort is required. But yes, non-zero effort - that's the
"collaboration" part.

> "Likes" wasn't my intention. There's no point in wasting countless hours
> on an RFC if it's clear ahead of time that it's not going to pass; and
> right now, even within this thread, it's hard to predict that. And,

Don't predict - just ask people. If it's any good, you're guaranteed
plenty of engagement, if anything, frequently too much of it.

> choice. While not perfect in any sense, reactions provide a meaningful
> simple way of communicating this relevance with a simple thumbs up/down.

Simple? Yes. Meaningful? Meh.

--
Stas Malyshev
smalyshev@gmail.com

Lynn

3 years ago

On Wed, Apr 12, 2023 at 10:14 PM Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Right. And participating meaningfully requires some level of commitment
> and investment. For example, willingness to familiarize oneself with
> some very simple rules and follow them. If that's not for you, that's
> fine - there are many other interesting things to do on the internet.
> But it's not a problem.
>

The rules and etiquette are detached from the mailing list, so it's not
obvious that they even exist.

Rowan Collins

3 years ago

On 12/04/2023 21:19, Lynn wrote:

>
> The rules and etiquette are detached from the mailing list, so it's not
> obvious that they even exist.
>

See https://externals.io/message/119955#119987

The etiquette rules would need to exist even if we moved to a different
technology, and fixing the documentation to signpost them better is
something that can happen right now, whether we move or not.

Regards,

--
Rowan Tommins
[IMSoP]

BohwaZ/PHP

3 years ago

Please no, I want to read e-mails when I want, with my own software,
leaving to me the freedom to mark things as important, or read, or
unread, or sort them in folders.

An important point : not all people in the world have access to the
internet at all time. Some people have to fetch the messages and read
them offline later. Also being able to be offline to write an e-mail is
much better.

Besides, there's already https://externals.io for people who prefer a
web interface.

Claude Pache

3 years ago

Hi ,

You made some good points, but please, avoid including statements that are plainly false: it lessens your arguments. I am specifically thinking of:

> - having to subscribe to a mailing list to even see the discussions

Have you never heard about externals.io <http://externals.io/>?

> - having to learn the specific, uncommon rules of replying: bottom posting, ...

Quoting relevant portion of previous messages and posting below them, is also a convention I’ve observed on other platforms, including github.

> ... word wrapping, ...

Really? I always thought that email clients are able to automatically wrap text in incoming messages. At least, I never manually wrap text when writing emails, and I have never received any complain that my emails are unreadable, If you have an issue with my reply, please complain.

> Also popular emailing clients don't do any of that automatically, making
> each reply tedious.

Maybe *some* popular emailing clients make it difficult... Those that I have used so far (which are decently popular) have never had problems.

Now to the point:

> What are your thoughts?

I prefer the mailing list for various reasons already mentioned by others (which I won’t repeat).

—Claude

Thomas Hruska

3 years ago

On 4/12/2023 6:52 AM, Alex Wells 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.
>
> What are your thoughts?

The subject line reads as if the mailing list is actually moving.


This is the second major mailing list in the past few weeks that I'm on
where this exact topic has arisen.  On the other list, the developers of
the project were the ones who proposed it and the idea was universally
and unilaterally rejected by all participants.

Communication on GitHub is awkward at best.  GitHub works well as an
issue tracker for bugs and hosting source code in a central location in
a way that allows merges to get done without driving everyone up a wall.
It's largely terrible at everything else.

As someone who maintains an email server, I completely understand that
maintaining a functioning email server today has intentionally been made
prohibitively difficult by Google, Microsoft, and major telecoms in
their overzealous and extremely misguided attempts to bounce block all
incoming messaging even from properly configured servers.  And those
same companies are also to blame for creating broken-by-design email
clients that no one should be using.  But the IETF shares the majority
of the blame for _actively_ not fixing numerous issues with email at the
protocol level.  Running away from email isn't the right solution though.

--
Thomas Hruska
CubicleSoft President

CubicleSoft has over 80 original open source projects and counting.
Plus a couple of commercial/retail products.

What software are you looking to build?

Lynn

3 years ago

On Wed, Apr 12, 2023 at 9:36 PM Thomas Hruska <thruska@cubiclesoft.com>
wrote:

>
>
> This is the second major mailing list in the past few weeks that I'm on
> where this exact topic has arisen.  On the other list, the developers of
> the project were the ones who proposed it and the idea was universally
> and unilaterally rejected by all participants.
>
>

Was this topic discussed only on the mailing list? Asking mailing list
users if they like the mailing list is obviously going to skew the opinion
into a direction of people being in favor of the mailing list.

tag Knife

3 years ago

On Wed, 12 Apr 2023 at 20:54, Lynn <kjarli@gmail.com> wrote:

>
> Was this topic discussed only on the mailing list? Asking mailing list
> users if they like the mailing list is obviously going to skew the opinion
> into a direction of people being in favor of the mailing list.
>

I use the mailing list (rarely) to get a strong opinion out and personally
hate it, But by taking part in this email chain there is an obvious skew
towards keeping it.

Robert Landers

3 years ago

On Wed, Apr 12, 2023 at 9:54 PM Lynn <kjarli@gmail.com> wrote:

>
> On Wed, Apr 12, 2023 at 9:36 PM Thomas Hruska <thruska@cubiclesoft.com>
> wrote:
>
> >
> >
> > This is the second major mailing list in the past few weeks that I'm on
> > where this exact topic has arisen.  On the other list, the developers of
> > the project were the ones who proposed it and the idea was universally
> > and unilaterally rejected by all participants.
> >
> >
> Was this topic discussed only on the mailing list? Asking mailing list
> users if they like the mailing list is obviously going to skew the opinion
> into a direction of people being in favor of the mailing list.

If you want to move the mailing list, you have to discuss it with the
mailing list, otherwise, the mailing list will move but people will
keep emailing each other and then it will be even harder to join a
mailing list without a mailing list.

Jakub Zelenka

3 years ago

On Wed, Apr 12, 2023 at 2:53 PM Alex Wells <autaut03@gmail.com> wrote:

>
> 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.
>

As can be seen from the reactions, this is very unlikely to be accepted if
proposed.

I think what could be proposed instead is to enable GitHub discussions for
discussing ideas before they are proposed on the mailing list. It could be
helpful for new people to get reactions without a need to subscribe the
mailing list and it would be also easier for searching, linking previous
ideas, tagging people as well as doing quick polls. It could potentially
bring more people to contribute to PHP. I think this could be also good for
the mailing list as it could potentially reduce a bit of volume especially
for things that are constantly repeating.

Regards

Jakub

Stas Malyshev

3 years ago

Hi!

> I think what could be proposed instead is to enable GitHub discussions for
> discussing ideas before they are proposed on the mailing list. It could be

Don't see any problem with that if somebody would be willing to keep an
eye on it and do the moderator duties (unfortunately, any public forum
requires that from time to time).

--
Stas Malyshev
smalyshev@gmail.com

Jakub Zelenka

3 years ago

On Wed, Apr 12, 2023 at 9:37 PM Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > I think what could be proposed instead is to enable GitHub discussions
> for
> > discussing ideas before they are proposed on the mailing list. It could
> be
>
> Don't see any problem with that if somebody would be willing to keep an
> eye on it and do the moderator duties (unfortunately, any public forum
> requires that from time to time).
>
>

I think it's kind of the same as for mailing list and it is quite a rare
event when things need some moderation. But if that happens, I think it
should be actually easier as there are more people with access that can do
the actual moderation.

Cheers

Jakub

Kamil Tekiela

3 years ago

I love this idea. Although GitHub is not perfect, it would be so much
better than a mailing list. Mailings lists are annoying: they have very
poor searching capabilities, you can't unsubscribe from a thread you are
not interested in, you can't follow the conversation easily because it's
not always obvious what is a quote and what is not, there is this annoying
rule about bottom posting that makes messages more difficult to read, there
is no code formatting, no editing, no tagging or organizing of message in
any way, and a lot more smaller annoyances. It's the same as SMS or any
other simple chat application. It's just too limited.

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.

Tim Düsterhus

3 years ago

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

Unnamed Person

3 years ago

Hello good people,

Looks like another hot discussion on the list, isn't it?

Just wanted to share my notice about the initial idea.

7 years ago there were people considering NNTP as an option. Nowadays,
it's pretty clear that it isn't the way to go. It doesn't mean that
technology is bad (although, someone can share their negative
experience with that one) but instead, we hardly we can find a person
who still uses it.
If we switch to the News protocol, it is highly likely that we not
just won't engage new members but instead, we'll lose those who are
here.

I reckon that this thread isn't about Github per se, it is rather a
shout that the technology is declining. It happens slowly, hence it's
hard to notice if you use it but suddenly you realise that people
don't even know what a "mailing list" is.

If we look at other projects (I will exclude Linux here: they still
discuss patches over emails), many of them started using online tools
(links below):

* Firefox devs actively use Matrix (a free platform) as well as maillist
* Kotlin doesn't use mail at all, they opted in using Slack + bug
tracker + KEEPs (something like RFCs).
* Docker does have a mailing list but it contains only spam over the last year

PHP switched to Git and Github as the code repository, I believe for
the same reason: it is a more popular and well-known tool these days.
So, the tooling for me isn't the toy with new fancy features
(personally, I'm happy with SVN and email: I'm an old codger), it's
rather about engaging new people, and making their life simpler.

Moreover, if we don't want to make a sharp move, we can try
introducing a new tool and see the activity there (or even introduce
this for other topics, like "PHP users", "Extension developers",
etc...).


Links:

https://wiki.mozilla.org/Matrix
https://github.com/JetBrains/kotlin/blob/master/docs/contributing.md
https://groups.google.com/g/docker-dev


Not trying to force any decision, just thought this was something that
could be considered as well.
Thanks and have a great day.

On Wed, Apr 12, 2023 at 2:53 PM Alex Wells <autaut03@gmail.com> wrote:

Unnamed Person

3 years ago

Den 2023-04-13 kl. 10:38, skrev Mikhail Galanin via internals:

> Hello good people,
>
> Looks like another hot discussion on the list, isn't it?
>
> Just wanted to share my notice about the initial idea.
>
> 7 years ago there were people considering NNTP as an option. Nowadays,
> it's pretty clear that it isn't the way to go. It doesn't mean that
> technology is bad (although, someone can share their negative
> experience with that one) but instead, we hardly we can find a person
> who still uses it.
> If we switch to the News protocol, it is highly likely that we not
> just won't engage new members but instead, we'll lose those who are
> here.
>

Hem, I actually use the builtin NNTP client in Thunderbird connecting to
news.php.net to follow PHP Internals. It's nice and it works :-)

Cheers //Björn L