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?
FYI: https://externals.io/message/87501#87501
Also: wow, that was 7 years ago?! :O
Marco Pivetta
https://mastodon.social/@ocramius
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?
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.
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 |
+---------------------------------------------------------------------+
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
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.
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]
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
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.
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/
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
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
--
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.
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]
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.phpWhat 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]--
To unsubscribe, visit: https://www.php.net/unsub.php
Heh,
Hurrah,
another Slack workspace to separately sign into on every device!
From working at Automattic for nearly 6 years, I can say that they are
indeed, a very Slack-heavy organization. They used it very well
though, maybe too well ;)
- Rob
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.
I also see a lot of user about the signup process just not working (which
was also mentioned in this thread),
users may understand how to signup, but upon doing so, don't get signed up
at all.
I think a move to github discussions would be better than a mailing list,
benefits include
- Choosing discussions to take part in, mailing lists are just an all
or nothing deal. - XPosting between issues, PRs and discussions.
- You can reply to discussions, PRs, issues via email for those who
want to keep doing that. - Contrary to this mailing lists belief, a lot more PHP devs who are
wanting to contribute to PHP
have a github account already versus access to the mailing list. - Discussion categories
- General QoC, including code blocks, markdown, clean web interface and
choosing what discussions
you want to take part in and not get notifications for disicussions you
dont care about. - Moderation, What would happen if a user decided to spam or flame the
maillist?
Once the email is sent you cant delete it from everyone's inbox,
everyone would get it,
and how long would the response to ban the user be?
The only downside i can think of is threading, github only does level-2
threading.
On Wed, 12 Apr 2023 at 19:42, Rowan Tommins rowan.collins@gmail.com
wrote: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.I also see a lot of user about the signup process just not working (which
was also mentioned in this thread),
users may understand how to signup, but upon doing so, don't get signed up
at all.I think a move to github discussions would be better than a mailing list,
benefits include
- Choosing discussions to take part in, mailing lists are just an all
or nothing deal.- XPosting between issues, PRs and discussions.
- You can reply to discussions, PRs, issues via email for those who
want to keep doing that.- Contrary to this mailing lists belief, a lot more PHP devs who are
wanting to contribute to PHP
have a github account already versus access to the mailing list.- Discussion categories
- General QoC, including code blocks, markdown, clean web interface and
choosing what discussions
you want to take part in and not get notifications for disicussions you
dont care about.- Moderation, What would happen if a user decided to spam or flame the
maillist?
Once the email is sent you cant delete it from everyone's inbox,
everyone would get it,
and how long would the response to ban the user be?The only downside i can think of is threading, github only does level-2
threading.
Here's a question: Who is going to be in charge of maintaining the GitHub
org and administrating it?
As someone who does community management for a long long time, I forsee
someone needing that to be their life for a project of this scale. Probably
multiple people. Paid for their work, I might add.
While we can't really say for sure how it would turn out, drawing on my
experience with online communities of all sorts and seeing what others had
to deal with on Github, things can get our of control fast.
GitHub is also not a suitable space to have RFC discussions and all that -
it's just not the right medium for that. Feedback - yes, gaging a wider
community for some feedback - sure. And maybe some of the PHP's mailing
lists can be moved to Github, since there are many.
But internal development lists need to stay where they are. These lists are
not meant for the general public to drive by and throw in a question or
two. The noise-to-signal ratio already at times is too high on this list,
now imagine 10-20-30x the activity that Github will bring. It will become
unmanageable. You are also required to police your org.
You also ignore the biggest thing: Github is owned by Microsoft, and
Microsoft is an American company. It abides by US laws, politics and so on.
That has consequences and puts PHP project under the same umbrella, which
the mailing list is not under. Github (Microsoft) can't decide to ban
someone or ask for someone to be removed as a core developer from the
mailing list. On Github - they can.
If people want to mirror internals to GitHub and manage it all and then
feed back the information into the list with links and feedback -
personally be my guest. But let's get one thing clear - email has been and
is the most critical communication tool out there and that is not going to
change. All those Slacks, Discords, Githubs, Microsoft Teams (why MS sucks
at making any type of messaging platform so badly?) in the end do not
replace email at all. Your email client cannot go offline just because
Amazon US-WEST-1 has died again (yes, it dying is basically a meme now). Or
because your provider had a major outage, so now you can't open Github. Or
someone misconfigured a BGP route and took down half the internet with it.
You can't have a copy of github on your phone, laptop, desktop or any other
device stored locally on each one of them giving you resiliency not to lose
all that data. What if github gets hacked and someone goes and nukes a
bunch of data? Or some DMCA takedown gets claimed against the org and
Github is required to comply by law? It does not matter that it might have
been bogus or frivolous - unless you have the funds to hire a lawyer and
defend yourself in court from which jurisdiction the DMCA came, you are
stuffed as a Thanksgiving turkey.
Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius
On Wed, 12 Apr 2023 at 20:41, Arvids Godjuks arvids.godjuks@gmail.com
wrote:
Here's a question: Who is going to be in charge of maintaining the GitHub
org and administrating it?
As someone who does community management for a long long time, I forsee
someone needing that to be their life for a project of this scale. Probably
multiple people. Paid for their work, I might add.
I don't know, there are already 40+ members in the group, i don't know who
has what permissions though.
While we can't really say for sure how it would turn out, drawing on my
experience with online communities of all sorts and seeing what others had
to deal with on Github, things can get our of control fast.
GitHub is also not a suitable space to have RFC discussions and all that -
it's just not the right medium for that. Feedback - yes, gaging a wider
community for some feedback - sure. And maybe some of the PHP's mailing
lists can be moved to Github, since there are many.
But internal development lists need to stay where they are. These lists
are not meant for the general public to drive by and throw in a question or
two. The noise-to-signal ratio already at times is too high on this list,
now imagine 10-20-30x the activity that Github will bring. It will become
unmanageable. You are also required to police your org.
You also ignore the biggest thing: Github is owned by Microsoft, and
Microsoft is an American company. It abides by US laws, politics and so on.
That has consequences and puts PHP project under the same umbrella, which
the mailing list is not under. Github (Microsoft) can't decide to ban
someone or ask for someone to be removed as a core developer from the
mailing list. On Github - they can.Well there are plenty of mailing list that could be trailed on. PHP-DOCS
for example, could be moved to a discussion board on the php-docs
repository.
https://github.com/php/doc-en
RFCs dont have a repository to belong too.
If people want to mirror internals to GitHub and manage it all and then
feed back the information into the list with links and feedback -
personally be my guest. But let's get one thing clear - email has been and
is the most critical communication tool out there and that is not going to
change. All those Slacks, Discords, Githubs, Microsoft Teams (why MS sucks
at making any type of messaging platform so badly?) in the end do not
replace email at all. Your email client cannot go offline just because
Amazon US-WEST-1 has died again (yes, it dying is basically a meme now). Or
because your provider had a major outage, so now you can't open Github. Or
someone misconfigured a BGP route and took down half the internet with it.
You can't have a copy of github on your phone, laptop, desktop or any other
device stored locally on each one of them giving you resiliency not to lose
all that data. What if github gets hacked and someone goes and nukes a
bunch of data? Or some DMCA takedown gets claimed against the org and
Github is required to comply by law? It does not matter that it might have
been bogus or frivolous - unless you have the funds to hire a lawyer and
defend yourself in court from which jurisdiction the DMCA came, you are
stuffed as a Thanksgiving turkey.
The internet is still the internet and all those issues can still effect
email. I use gmail and if googles email servers go down email the mail
server that send the email doesnt have retry setup I wont get that email.
If my internet goes down I wont get the emails untill its back up. If the
server PHP used for the maillist server goes down nothing get sent/received.
The internet and everything connected to it can and will go down. Email
isn't magically unaffected by that fact.
On Wed, 12 Apr 2023 at 20:41, Arvids Godjuks arvids.godjuks@gmail.com
wrote:If people want to mirror internals to GitHub and manage it all and then
feed back the information into the list with links and feedback -
personally be my guest. But let's get one thing clear - email has been and
is the most critical communication tool out there and that is not going to
change. All those Slacks, Discords, Githubs, Microsoft Teams (why MS sucks
at making any type of messaging platform so badly?) in the end do not
replace email at all. Your email client cannot go offline just because
Amazon US-WEST-1 has died again (yes, it dying is basically a meme now). Or
because your provider had a major outage, so now you can't open Github. Or
someone misconfigured a BGP route and took down half the internet with it.
You can't have a copy of github on your phone, laptop, desktop or any other
device stored locally on each one of them giving you resiliency not to lose
all that data. What if github gets hacked and someone goes and nukes a
bunch of data? Or some DMCA takedown gets claimed against the org and
Github is required to comply by law? It does not matter that it might have
been bogus or frivolous - unless you have the funds to hire a lawyer and
defend yourself in court from which jurisdiction the DMCA came, you are
stuffed as a Thanksgiving turkey.The internet is still the internet and all those issues can still effect
email. I use gmail and if googles email servers go down email the mail
server that send the email doesnt have retry setup I wont get that email.
If my internet goes down I wont get the emails untill its back up. If the
server PHP used for the maillist server goes down nothing get sent/received.
The internet and everything connected to it can and will go down. Email
isn't magically unaffected by that fact.
A joke about "people who don't do backups and people who now do backups"
kinda fits.
Those who care - those have their clients configured to fetch and store
their emails locally constantly. I have my phone configured to grab all
emails and have them available offline. IMAP/POP3 hasn't gone anywhere
too. Having things available offline is something I appreciate more and
more. People have different workflows, and there is a surprising amount of
people I meet who purposefully avoid being constantly online for all kinds
of reasons.
Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius
Choosing discussions to take part in, mailing lists are just an all or
nothing deal.
It depends what you mean by "take part in", I guess. But yes, e-mail
forces you to have a local mirror of the active topics to choose from
and reply to, which isn't always what you want straight away.
XPosting between issues, PRs and discussions.
URLs do a pretty good job for that. Unless you mean literally posting
the same text to two places, which sounds like a terrible idea.
You can reply to discussions, PRs, issues via email for those who want
to keep doing that.
Possibly. Last time I tried, GitHub's notification e-mails were too
poorly designed to have a good idea of what I was replying to unless I
clicked through to the web UI.
Contrary to this mailing lists belief, a lot more PHP devs who are
wanting to contribute to PHP
have a github account already versus access to the mailing list.
As far as I know, you need an e-mail address to sign up to GitHub, so
logically every single person who has a GitHub account can also sign up
to this mailing list.
Which makes it, once again, about the on-boarding process, not the
actual list itself.
Discussion categories
Could be useful, maybe. I can't think of many ways to slice this list,
though; perhaps separating the more technical threads from the more
organisational ones like this.
General QoC, including code blocks, markdown,
A little bit of formatting might be useful occasionally.
I kind of hate markdown specifically, though. It re-purposes so much
punctuation, and has so many context-dependent effects, that you have to
preview every single post.
clean web interface
One man's "clean" is another man's "eugh, I have to put up with this". A
federated protocol like e-mail means we all get to choose; a centralised
forum means we at most get some config switches to twiddle.
choosing what discussions
you want to take part in and not get notifications for disicussions
you dont care about.
Maybe it's a matter of taste, but I have always found GitHub's
notification options - both by e-mail and in their web UI - to be
utterly unusable.
Then again, I don't really think about this list as having
"notifications" at all - I periodically check the folder containing all
the mailing list messages for new threads, or unread messages in
existing threads I'm interested in. It's extremely rare that there are
so many distinct threads, rather than messages within a single thread,
that I need anything more than that.
The only difference with a forum would be that I'd have to log into one
restrictive UI to do that, rather than my choice of mail client. To me,
that's a net negative.
Moderation, What would happen if a user decided to spam or flame the
maillist?
Once the email is sent you cant delete it from everyone's inbox,
everyone would get it,
and how long would the response to ban the user be?
This is a fair point. It does happen occasionally, but so far it's never
been more than a minor nuisance.
As Arvids says, there's a double-edged sword here too: a lower barrier
to entry will make this more likely, so volunteers will need to spend
more time wielding those powers. Or, we'll create explicit barriers to
access, which will lead us back to ... how we implement and document the
sign-up process.
I am totally willing to admit people's preferences will vary, but then I
see comments like this ...
The only downside i can think of is threading, github only does
level-2 threading.
... and I wonder if others really get that people aren't just defending
e-mail because we're old and stubborn, we actually like how it works, or
at least think it has pros as well as cons.
Regards,
--
Rowan Tommins
[IMSoP]
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.
I agree, and it's a common pattern, both here and in the earlier thread about deprecations/evolution.
Problems exist. Both with the mailing list setup we have, and the evolution/deprecation process. It's not reasonable to deny either.
But so often, people lead with "and here's why we should rm -rf and start over" or "and here's why you're all terrible" or other extremely not-helpful "suggestions." That poisons the well, and totally saps any energy for working on the things that can and should be improved incrementally.
It makes me very sad, because if someone were actually to volunteer to overhaul the mailing list signup process and verify that it actually, you know, works reliably, there's a good chance they'd be greeted with open arms. (And a fair amount of access skepticism I'm sure, but still, it's no secret that we'd benefit from that.) But that's not what happens.
--Larry Garfield
Hey all
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.I agree, and it's a common pattern, both here and in the earlier thread about deprecations/evolution.
Problems exist. Both with the mailing list setup we have, and the evolution/deprecation process. It's not reasonable to deny either.
But so often, people lead with "and here's why we should rm -rf and start over" or "and here's why you're all terrible" or other extremely not-helpful "suggestions." That poisons the well, and totally saps any energy for working on the things that can and should be improved incrementally.
It makes me very sad, because if someone were actually to volunteer to overhaul the mailing list signup process and verify that it actually, you know, works reliably, there's a good chance they'd be greeted with open arms. (And a fair amount of access skepticism I'm sure, but still, it's no secret that we'd benefit from that.) But that's not what happens.
I would like to take this as a first step:
As I already do have access to the lists-server I'm happy to work on
improving the lists usability.
So far I see three different things:
- Remove modification of the emails on the lists server so that DKIM
and DMARC will finally work - Improve/Update the interfaces of https://www.php.net/mailing-lists.php
- Update (or possibly completely remove?) https://www.php.net/unsub.php
The latest is linke in the added footer that would be removed by step 1
and that should be unnecessary anyhow as the list-unsubscribe header
already should provide the email-clients with a way to show an
unsubscribe button right in the email.
Any volunteers helping are welcome!
And please do voice concerns regarding point 1!!!!
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 |
+---------------------------------------------------------------------+
Hi
- Remove modification of the emails on the lists server so that DKIM
and DMARC will finally work
Yes, please, but for different reasons:
Filtering is much more reliably performed using the 'list-id' header
compared to a Subject prefix and not having the prefix in the Subject
makes the INBOX more tidy when also having the [RFC] or [VOTE] prefixes.
Also clients apparently can't decide whether to put the 'Re' before or
after the prefix.
DMARC is less of a concern, because the list apparently already performs
DMARC mangling for a policy that is not 'none'
Best regards
Tim Düsterhus
Hey
Hi
- Remove modification of the emails on the lists server so that DKIM
and DMARC will finally workYes, please, but for different reasons:
Filtering is much more reliably performed using the 'list-id' header
compared to a Subject prefix and not having the prefix in the Subject
makes the INBOX more tidy when also having the [RFC] or [VOTE] prefixes.
Also clients apparently can't decide whether to put the 'Re' before or
after the prefix.DMARC is less of a concern, because the list apparently already performs
DMARC mangling for a policy that is not 'none'
Apart from (possibly) modifying the body and the subject line which then
breaks the DKIM signature which then breaks DMARC ;-)
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 |
+---------------------------------------------------------------------+
Hi
DMARC is less of a concern, because the list apparently already performs
DMARC mangling for a policy that is not 'none'Apart from (possibly) modifying the body and the subject line which then
breaks the DKIM signature which then breaks DMARC ;-)
I understand how DKIM and DMARC works. For users with a DMARC policy of
quarantine or reject the list manager already performs DMARC mangling:
The 'From' header is changed from the original 'From' header and instead
the list address is put there. Now the DMARC policy of the original
sender no longer applies and instead the DMARC policy of the list is
used (which does not exist).
You can see happening with the email from "Mikhail Galanin via
internals" that was sent roughly 10 minute ago.
Best regards
Tim Dsüterhus
Hi
DMARC is less of a concern, because the list apparently already performs
DMARC mangling for a policy that is not 'none'Apart from (possibly) modifying the body and the subject line which then
breaks the DKIM signature which then breaks DMARC ;-)I understand how DKIM and DMARC works. For users with a DMARC policy of
quarantine or reject the list manager already performs DMARC mangling:The 'From' header is changed from the original 'From' header and instead
the list address is put there. Now the DMARC policy of the original
sender no longer applies and instead the DMARC policy of the list is
used (which does not exist).You can see happening with the email from "Mikhail Galanin via
internals" that was sent roughly 10 minute ago.
Then we should probably change that so that emails from a domain with
DMARC set to 'none' are also not changed.
As that just means that DMARC is enabled, the receiving mailserver
should just not quarantine or reject the message but instead inform the
sender about the problem.
With the current settings the sender receives issues and the clients
also report that the DKIM signature is invalid.
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 |
+---------------------------------------------------------------------+
Hey all
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.
I agree, and it's a common pattern, both here and in the earlier thread about deprecations/evolution.
Problems exist. Both with the mailing list setup we have, and the evolution/deprecation process. It's not reasonable to deny either.
But so often, people lead with "and here's why we should rm -rf and start over" or "and here's why you're all terrible" or other extremely not-helpful "suggestions." That poisons the well, and totally saps any energy for working on the things that can and should be improved incrementally.
It makes me very sad, because if someone were actually to volunteer to overhaul the mailing list signup process and verify that it actually, you know, works reliably, there's a good chance they'd be greeted with open arms. (And a fair amount of access skepticism I'm sure, but still, it's no secret that we'd benefit from that.) But that's not what happens.I would like to take this as a first step:
As I already do have access to the lists-server I'm happy to work on improving the lists usability.
So far I see three different things:
- Remove modification of the emails on the lists server so that DKIM and DMARC will finally work
- Improve/Update the interfaces of https://www.php.net/mailing-lists.php
- Update (or possibly completely remove?) https://www.php.net/unsub.php
The latest is linke in the added footer that would be removed by step 1 and that should be unnecessary anyhow as the list-unsubscribe header already should provide the email-clients with a way to show an unsubscribe button right in the email.
Any volunteers helping are welcome!
And please do voice concerns regarding point 1!!!!
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 |
+---------------------------------------------------------------------+
Hi Andreas,
As someone who rejoined this list in the last 12 months and went through the process I'm happy to volunteer to help.
Best wishes,
Matt
With regards to user interfaces for email itself, I'd like to mention that there are many hybrids out there that work for many communities. I'm not proposing this in any way. I'm quite happy for PHP to use mailing lists, and personally would recommend improving the existing web interface, and to perhaps prepare an FAQ/tips-n-tricks to get started, such as setting up the emails to go into a folder and linking to how to do this with popular email providers/apps.
To mention a few in case there is interest in migrating instead of improving:
-
Mailman. Probably the most of not one of the most popular softwares to manage mailing lists at scale (W3C, Curl, Python, Wikimedia, etc.). The latest version, Mailman3 features the "Hyperkitty", which presents the archive in an interactive read-write fashion rather than merely read-only. Effectively making it feel like a forum, discussion board, Discourse, etc from the web UI. This doesn't affect the backend, which remains fully email-based.
-
Topicbox. From the folks at Fastmail, this is marketed as a better interface for business/team email (they don't call it a "mailing list" or a "forum"), but it is effectively a mailing list server with a forum interface allowing you to create threads and reply from either your email app, or from the web interface. This one feels quite a bit more mature and polished than Hyperkitty and provides a less leaky abstraction (e.g. doesn't feel like a shim over top of email).
-
Google Groups. This is not freely licensed software obviously, but it is probably the second most common way to manage mailing lists at scale. It has a solid web interface where you can participate fully, including to turn off your own personal "email" side of things if you prefer not to be notified through there, or you can choose to sign up with digests where you might get a weekly summary as a way to be nudged back in. This is especially handy for people who do like email as a way to be notified, but perhaps have nothing else in their life using Google Groups so they're not likely to see messages there unless something links them there, which the weekly digets would accomplish.
-
Discourse. This is effectively the inverse of Google Groups and least like a "real" mailing list. I'd describe Discourse as a web discussion forum first, and mailing list second. Afaik it does offer full participation via email. By default you only get notified of replies to threads you've opted into to subscribing to but you can subscribe to a whole category/subforum for new threads, and can reply-by-email to post comments without using their web app.
Probably the most incremental step (after improving) is Mailman, assuming an import of the archive is possible with URL-compatible redirects. Again, I'm not proposing this, but might as well have it out there as a less bad option in case people are drawn to migrating.
-- Timo
Hey all
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.I agree, and it's a common pattern, both here and in the earlier thread about deprecations/evolution.
Problems exist. Both with the mailing list setup we have, and the evolution/deprecation process. It's not reasonable to deny either.
But so often, people lead with "and here's why we should rm -rf and start over" or "and here's why you're all terrible" or other extremely not-helpful "suggestions." That poisons the well, and totally saps any energy for working on the things that can and should be improved incrementally.
It makes me very sad, because if someone were actually to volunteer to overhaul the mailing list signup process and verify that it actually, you know, works reliably, there's a good chance they'd be greeted with open arms. (And a fair amount of access skepticism I'm sure, but still, it's no secret that we'd benefit from that.) But that's not what happens.
I would like to take this as a first step:
As I already do have access to the lists-server I'm happy to work on
improving the lists usability.So far I see three different things:
- Remove modification of the emails on the lists server so that DKIM
and DMARC will finally work- Improve/Update the interfaces of https://www.php.net/mailing-lists.php
- Update (or possibly completely remove?) https://www.php.net/unsub.php
The latest is linke in the added footer that would be removed by step 1
and that should be unnecessary anyhow as the list-unsubscribe header
already should provide the email-clients with a way to show an
unsubscribe button right in the email.Any volunteers helping are welcome!
And please do voice concerns regarding point 1!!!!
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 |
+---------------------------------------------------------------------+Attachments:
• OpenPGP_signature
- Discourse. This is effectively the inverse of Google Groups and least
like a "real" mailing list. I'd describe Discourse as a web discussion
forum first, and mailing list second. Afaik it does offer full
participation via email. By default you only get notified of replies to
threads you've opted into to subscribing to but you can subscribe to a
whole category/subforum for new threads, and can reply-by-email to post
comments without using their web app.
Discourse was actually one of the top recommendations from the reddit
discussion because of its easy of use and accessibility via frontend and
email. And acts more like a web forum.
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
discussionPosted 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
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
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
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]
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.
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.
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:
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]
What are your thoughts?
Not a chance. Also, who are you?
cheers
Derick
Hey Alex.
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 |
+---------------------------------------------------------------------+
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
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.
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.
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
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.
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
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.
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]
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.
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
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?
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.
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.
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.
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
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
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
beDon'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
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.
Hi
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
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.
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?
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