Re: [PHP-DEV] Moving PHP internals to GitHub

[Björn Larsson via internals]

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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

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

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

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

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

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

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


Links:

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


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

On Wed, Apr 12, 2023 at 2:53 PM Alex Wells  wrote:
>
> Hey.
>
> PHP currently uses internals@lists.php.net for communication. That includes
> mostly RFCs (or their votings, or their pre-discussion) and sometimes
> questions about the implementation or possible bugs.
>
> While emailing definitely works, it's not the best UX out there. Here are
> some immediate flaws which make the process harder than it should be:
>  - having to subscribe to a mailing list to even see the discussions
>  - supporting public archives such as externals.io to expose discussions to
> the public for those who aren't subscribed and keep historical data
>  - having to learn the specific, uncommon rules of replying: bottom
> posting, word wrapping, removing footers. It's not to say any of those
> rules are complex or hard to follow; it's that they're basically
> inapplicable outside of emails, so they're usually not known by newcomers.
> Also popular emailing clients don't do any of that automatically, making
> each reply tedious.
>  - no way of editing a message. Mistakes will always be made, so being able
> to quickly fix them would be nice
>  - no formatting, especially code blocks. Sure, they are possible through
> HTML, but there's no single common way which all of the emailing clients
> will understand - like Markdown
>  - no reactions - it's hard to tell whether something is supported or not.
> This includes both the initiative being discussed and the replies that
> follow. Sure, you can usually kind of judge the general narrative based on
> the replies, but it's not always clear what's in favor. There are usually
> many divergent branches of discussions and it's unknown what's supported
> the most.
>
> Based on those issues and PHP, I propose moving the discussions elsewhere -
> to some kind of modern platform. Since this is quite a big change in the
> processes used, I imagine an RFC would be needed. But before I do that I
> want to measure the reactions. If it goes well, I'll proceed with an RFC
> draft.
>
> There are basically two choices here - a messenger-like platform (i.e.
> Slack, Teams) or a developer focused platform like GitHub. While messengers
> certainly work, they're more focused on working with teammates rather than
> actual discussions. They usually don't have a simple way to navigate
> publicly and are poor at separating multiple topics into threads. Some
> projects use them for that purpose, but it's usually a worse experience
> than what GitHub provides.
>
> GitHub is already used by PHP for both the source code and the issues, so
> that is a good candidate, especially since it's a platform designed to
> handle cases like this. Also, that should be a much easier transition now
> that the source and issues were moved to GitHub.
>
> Also, to be clear: I'm not proposing to remove all PHP mailing lists; some
> of them are one way (i.e. notifications for something) so they should
> definitely stay that 

Re: [PHP-DEV] Moving PHP internals to GitHub

[Tim Düsterhus]

Hi

On 4/12/23 23:39, Kamil Tekiela wrote:

I love this idea. Although GitHub is not perfect, it would be so much
better than a mailing list. [...]

But unfortunately, if it came to a vote, I would vote NO. The mailing list
must remain IMHO. It's terrible and annoying but it's also very simple and
ubiquitous. And that's what is needed for inclusivity. A lot of senior
developers prefer this kind of communication method so if we asked them to
switch over we could lose them. Not to mention people who have no access to
GitHub because of sanctions. It's the ubiquitousness of email that makes it
the best tool for the job even if it's actually terrible for technical
discussions.



If the comparison is between "Mailing List" vs "GitHub Discussions", I 
agree with you. Both of these options are "extremes", though. A possible 
middle-ground option that also was mentioned on GitHub would be a modern 
web forum software.


First things first in the interest of disclosure: I'm employed by 
WoltLab, a company that develops commercial (PHP-based) apps for 
community management ("forum software"). My first PHP RFC 
(SensitiveParameter for 8.2) was developed on company time. After that 
successful RFC I continued participating on the list, mostly in my 
personal time. I'm writing this email in my personal time.


Personally I'm fine with participating on mailing lists. I also 
contribute regularly to another project (HAProxy) that primarily works 
with a mailing list. In fact when contributing external patches, the 
project doesn't use pull requests or some other software assistance. 
Instead patches are mailed around, like it is done with the Linux 
kernel. For the longest time they didn't even have an issue tracker, but 
they are now using GitHub Issues after I was sufficiently


However while my coworkers read the list via externals, I've been 
unsuccessful in encouraging them to also participate directly. Their 
area of expertise is different than mine and they would likely be able 
to also add valuable information that I am not able to add myself. Their 
reasons for non-participation are similar to the reasons already given: 
They don't feel comfortable with the email-based process.


Looping back to the initial paragraph of this email and because several 
participants expressed that one should not just look at the perceived 
advantages of a new solution I used the opportunity to summarize 
existing arguments (and adding my own). For the forum software, I'm 
using my employer's forum software feature set as a specific example, 
depending on the software the feature set might differ. Whether a 
specific point is a plus or minus might be debatable for some of the 
points YMMV :-) Points are listed in no particular order except for the 
prefix. Of course each of the points needs to be weighted with regard to 
importance.


Mailing List:
+ The mailing list already exists and it does the job ("No migration 
effort").

+ Emails can be read offline and replies can reasonably be composed offline.
+ Everyone with an email address is technically able to participate.
+ Users are free to choose an interface / MUA of their choice.
+ Full data Ownership (Message history is stored on PHP's infrastructure).
+ Easy to keep track of unread messages.

~ Search dependent on whether the email is in your local inbox (the 
archives are not easy to search)
~ A tree-based structure is the best option to discuss different 
subthreads, without everything being mixed, however some common MUAs do 
not support threading well, resulting in confusing threading for everyone.
~ The functionality is limited to plaintext emails. This prevents 
annoying stuff like colored emails, but at the same time forces folks to 
send "+1" emails for agreement or to not share their agreement at all.


- No categorization of different topics.
- Little to no moderation functionality.
- Messages cannot be edited.
- Very hard to reply to existing threads when newly subscribing.
- The common problems of emails apply (e.g. bogus rejections by 
overzealous spam filters).

- High barrier of entry (e.g. to set up proper filters).

GitHub Discussions:
+ PHP does not need to provide the infrastructure.
+ "Emoji Reactions" (as a weak signal to gauge agreement without 
creating notifications).
+ Polls (as a stronger signal to gauge opinions without creating 
notifications)

+ Messages can be edited (with edit history).
+ Low barrier of entry (many folks already have a GitHub account)
+ Threads can be grouped in categories.
+ Rich text formatting.
+ GitHub is not likely to go anywhere.

~ Search is not great (at least I often do not find the issues I am 
searching for, using Google does not really work either).

~ Supports sending notifications via email (it's not great, though)
~ Supports replying via email (it's not great, though)
~ Limited support for threading / response trees.
~ Limited moderation functionality.

- Cannot be used offline.
- Referring back to quoted 

Re: [PHP-DEV] Moving PHP internals to GitHub

[Kamil Tekiela]

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.

Re: [PHP-DEV] Moving PHP internals to GitHub

[Jakub Zelenka]

On Wed, Apr 12, 2023 at 9:37 PM Stanislav Malyshev 
wrote:

> Hi!
>
> > I think what could be proposed instead is to enable GitHub discussions
> for
> > discussing ideas before they are proposed on the mailing list. It could
> be
>
> Don't see any problem with that if somebody would be willing to keep an
> eye on it and do the moderator duties (unfortunately, any public forum
> requires that from time to time).
>
>
I think it's kind of the same as for mailing list and it is quite a rare
event when things need some moderation. But if that happens, I think it
should be actually easier as there are more people with access that can do
the actual moderation.

Cheers

Jakub

Re: [PHP-DEV] Moving PHP internals to GitHub

[Larry Garfield]

On Wed, Apr 12, 2023, at 6:42 PM, Rowan Tommins 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 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Stanislav Malyshev]

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
smalys...@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Jakub Zelenka]

On Wed, Apr 12, 2023 at 2:53 PM Alex Wells  wrote:

>
> Based on those issues and PHP, I propose moving the discussions elsewhere -
> to some kind of modern platform. Since this is quite a big change in the
> processes used, I imagine an RFC would be needed. But before I do that I
> want to measure the reactions. If it goes well, I'll proceed with an RFC
> draft.
>

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

Re: [PHP-DEV] Moving PHP internals to GitHub

[Rowan Tommins]

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


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



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

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


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Arvids Godjuks]

On Wed, 12 Apr 2023 at 23:05, tag Knife  wrote:

>
>
> On Wed, 12 Apr 2023 at 20:41, Arvids Godjuks 
> 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.godj...@gmail.com
Telegram: @psihius https://t.me/psihius

Re: [PHP-DEV] Moving PHP internals to GitHub

[Lynn]

On Wed, Apr 12, 2023 at 10:14 PM Stanislav Malyshev 
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.

Re: [PHP-DEV] Moving PHP internals to GitHub

[Stanislav Malyshev]

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
smalys...@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Lydia de Jongh]

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 :

> On Wed, 12 Apr 2023 at 14:53, Alex Wells  wrote:
>
> >
> > Based on those issues and PHP, I propose moving the discussions
> elsewhere -
> > to some kind of modern platform.
>
>
>
> This has been discussed before, many times, so I'll keep this brief and let
> you find the old discussions.
>
> I think "moving to a modern platform" presents a false dichotomy.
>
> Any move needs to be assessed on both the advantages and disadvantages of
> *both* (or all) options, not just what looks new and shiny if we move.
>
> Some starting points off the top of my head:
>
> * Ease of access (is subscribing to e-mail *really* harder than logging
> into Github?)
> * Notification of replies and new threads (I find Github pretty awful at
> controlling e-mails and giving useful activity overviews)
> * Handling of threads and sub-threads (at minimum, a tree view like a
> decent e-mail client; preferably, ability for trusted users to split and
> merge threads)
> * Spam control
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]
>

Re: [PHP-DEV] Moving PHP internals to GitHub

[tag Knife]

On Wed, 12 Apr 2023 at 20:41, Arvids Godjuks 
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.

Re: [PHP-DEV] Moving PHP internals to GitHub

[Rowan Tommins]

On 12/04/2023 20:07, tag Knife wrote:

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]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Robert Landers]

On Wed, Apr 12, 2023 at 9:54 PM Lynn  wrote:
>
> On Wed, Apr 12, 2023 at 9:36 PM Thomas Hruska 
> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[tag Knife]

On Wed, 12 Apr 2023 at 20:54, Lynn  wrote:

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

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

Re: [PHP-DEV] Moving PHP internals to GitHub

[Lynn]

On Wed, Apr 12, 2023 at 9:36 PM Thomas Hruska 
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.

Re: [PHP-DEV] Moving PHP internals to GitHub

[Arvids Godjuks]

On Wed, 12 Apr 2023 at 22:07, tag Knife  wrote:

> On Wed, 12 Apr 2023 at 19:42, Rowan Tommins 
> 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
>
>1. Choosing discussions to take part in, mailing lists are just an all
>or nothing deal.
>2. XPosting between issues, PRs and discussions.
>3. You can reply to discussions, PRs, issues via email for those who
>want to keep doing that.
>4. 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.
>5. Discussion categories
>6. 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.
>7. 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.godj...@gmail.com
Telegram: @psihius https://t.me/psihius

Re: [PHP-DEV] Moving PHP internals to GitHub

[Thomas Hruska]

On 4/12/2023 6:52 AM, Alex Wells wrote:

Hey.

PHP currently uses internals@lists.php.net for communication. That includes
mostly RFCs (or their votings, or their pre-discussion) and sometimes
questions about the implementation or possible bugs.

What are your thoughts?


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


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


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


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


--
Thomas Hruska
CubicleSoft President

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

What software are you looking to build?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[tag Knife]

On Wed, 12 Apr 2023 at 19:42, Rowan Tommins  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

   1. Choosing discussions to take part in, mailing lists are just an all
   or nothing deal.
   2. XPosting between issues, PRs and discussions.
   3. You can reply to discussions, PRs, issues via email for those who
   want to keep doing that.
   4. 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.
   5. Discussion categories
   6. 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.
   7. 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.

Re: [PHP-DEV] Moving PHP internals to GitHub

[Derick Rethans]

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

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

Cheers
Derick 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Robert Landers]

On Wed, Apr 12, 2023 at 8:42 PM Rowan Tommins  wrote:
>
> On 12/04/2023 19:05, tag Knife wrote:
> > I say this as someone who was trying to onboard themselves the other day
> > (web-php and php-docs).
> > The entire process is archaic and uses "tools" from 20 years ago.
> > Onboarding for anything you're interested in doesn't really give a
> > direction at all (unless you're a dev).
> > It mostly boils down "do this, do that, after that figure it out yourself".
>
>
> I'd like to draw attention to a non sequitur between the above, totally
> valid criticism, and the below:
>
>
> > It really shows php's age that you have to join a mailing-list to even get
> > generic user support, let alone participate in development.
>
>
> None of the above has anything to do with it being a mailing list per
> se. You could have just as bad an experience trying to sign up for a web
> forum, or a chat room, or something-something-blockchain-ai-javascript.
>
> But to repeat: the complaints about the sign-up process are totally
> valid. I don't know enough about the system involved to make them
> smoother, but there's no reason signing up for a mailing list can't be
> as simple as enter address, confirm address, done. By all accounts, the
> PHP ones are not.
>
>
> > Look at the "Make WordPress" page compared to php's "Get Involved" page and
> > the overall onboarding experience is so much nicer and improved.
> > People can get a general idea of how teams works, their goals, who's
> > leading who,
> > with helpful guides and direction to get people started.
>
>
> I agree to a point. My first impression of the Wordpress page you
> mention is that it's kind of overwhelming with the number of different
> teams, and it's mostly a directory of Slack channels, I think? (Hurrah,
> another Slack workspace to separately sign into on every device!) A more
> apt comparison is probably to https://www.php.net/mailing-lists.php
>
> What is probably lacking both there and the "Get Involved" page is a
> more direct statement that Internals is the central communication hub
> for the project. The mailing list page describes it as "A medium volume
> list for those who want to help out with the development of PHP" which
> is accurate but entirely unhelpful.
>
>
> Which brings me back to my earlier point: I wonder how much of the
> reaction is really about e-mail itself, and how much is just the
> documentation and sign-up forms you encounter *before* you hit the list.
> Because if it's the latter, migrating the entire community to a new
> platform won't help - we'll still suck at introducing anyone to that
> platform - and most of what we need is someone who's good with words to
> update some website copy.
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Rowan Tommins]

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

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



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




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



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


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




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



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


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



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


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[tag Knife]

On Wed, 12 Apr 2023 at 19:00, Reinis Rozitis  wrote:

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


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

Posted by HappyPenguin on reddit

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

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

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

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

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


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

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

Re: [PHP-DEV] Moving PHP internals to GitHub

[Robert Landers]

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

RE: [PHP-DEV] Moving PHP internals to GitHub

[Reinis Rozitis]

> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Claude Pache]

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 ?

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

Re: [PHP-DEV] Moving PHP internals to GitHub

[tag Knife]

On Wed, 12 Apr 2023 at 16:25, Alex Wells  wrote:

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

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

Re: [PHP-DEV] Moving PHP internals to GitHub

[Alex Wells]

On Wed, Apr 12, 2023 at 7:31 PM Stanislav Malyshev 
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.

Re: [PHP-DEV] Moving PHP internals to GitHub

[BohwaZ]

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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Stanislav Malyshev]

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
smalys...@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Lynn]

On Wed, Apr 12, 2023 at 4:16 PM Rowan Tommins 
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.

Re: [PHP-DEV] Moving PHP internals to GitHub

[Lynn]

On Wed, Apr 12, 2023 at 3:53 PM Alex Wells  wrote:

> What are your thoughts?
>

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

Re: [PHP-DEV] Moving PHP internals to GitHub

[Peter Kokot]

On Wed, 12 Apr 2023 at 15:53, Alex Wells  wrote:
>
> Hey.
>
> PHP currently uses internals@lists.php.net for communication. That includes
> mostly RFCs (or their votings, or their pre-discussion) and sometimes
> questions about the implementation or possible bugs.
>
> While emailing definitely works, it's not the best UX out there. Here are
> some immediate flaws which make the process harder than it should be:
>  - having to subscribe to a mailing list to even see the discussions
>  - supporting public archives such as externals.io to expose discussions to
> the public for those who aren't subscribed and keep historical data
>  - having to learn the specific, uncommon rules of replying: bottom
> posting, word wrapping, removing footers. It's not to say any of those
> rules are complex or hard to follow; it's that they're basically
> inapplicable outside of emails, so they're usually not known by newcomers.
> Also popular emailing clients don't do any of that automatically, making
> each reply tedious.
>  - 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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Alex Wells]

On Wed, Apr 12, 2023 at 6:15 PM Pierre  wrote:

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


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

Re: [PHP-DEV] Moving PHP internals to GitHub

[Pierre]

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Arvids Godjuks]

On Wed, 12 Apr 2023 at 16:53, Alex Wells  wrote:

> Hey.
>
> PHP currently uses internals@lists.php.net for communication. That
> includes
> mostly RFCs (or their votings, or their pre-discussion) and sometimes
> questions about the implementation or possible bugs.
>
> While emailing definitely works, it's not the best UX out there. Here are
> some immediate flaws which make the process harder than it should be:
>  - having to subscribe to a mailing list to even see the discussions
>  - supporting public archives such as externals.io to expose discussions
> to
> the public for those who aren't subscribed and keep historical data
>  - having to learn the specific, uncommon rules of replying: bottom
> posting, word wrapping, removing footers. It's not to say any of those
> rules are complex or hard to follow; it's that they're basically
> inapplicable outside of emails, so they're usually not known by newcomers.
> Also popular emailing clients don't do any of that automatically, making
> each reply tedious.
>  - 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.godj...@gmail.com
Telegram: @psihius https://t.me/psihius

Re: [PHP-DEV] Moving PHP internals to GitHub

[Andreas Heigl]

On 12.04.23 16:12, Alex Wells wrote:

On Wed, Apr 12, 2023 at 4:57 PM Marco Pivetta  wrote:


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

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

That was exactly my thought as well...




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

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


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


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


Just my 0.02€

Cheers

Andreas
--
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@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  |
+-+


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PHP-DEV] Moving PHP internals to GitHub

[Rowan Tommins]

On Wed, 12 Apr 2023 at 15:22, Alex Wells  wrote:

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


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

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

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

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] Moving PHP internals to GitHub

[Alex Wells]

On Wed, Apr 12, 2023 at 5:16 PM Rowan Tommins 
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.

Re: [PHP-DEV] Moving PHP internals to GitHub

[Andreas Heigl]

Hey Alex.

On 12.04.23 15:52, Alex Wells wrote:

Hey.

PHP currently uses internals@lists.php.net for communication. That includes
mostly RFCs (or their votings, or their pre-discussion) and sometimes
questions about the implementation or possible bugs.

While emailing definitely works, it's not the best UX out there. Here are
some immediate flaws which make the process harder than it should be:
  - having to subscribe to a mailing list to even see the discussions
  - supporting public archives such as externals.io to expose discussions to
the public for those who aren't subscribed and keep historical data
  - having to learn the specific, uncommon rules of replying: bottom
posting, word wrapping, removing footers. It's not to say any of those
rules are complex or hard to follow; it's that they're basically
inapplicable outside of emails, so they're usually not known by newcomers.
Also popular emailing clients don't do any of that automatically, making
each reply tedious.


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


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



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


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

  - no formatting, especially code blocks. Sure, they are possible through
HTML, but there's no single common way which all of the emailing clients
will understand - like Markdown


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



  - no reactions - it's hard to tell whether something is supported or not.
This includes both the initiative being discussed and the replies that
follow. Sure, you can usually kind of judge the general narrative based on
the replies, but it's not always clear what's in favor. There are usually
many divergent branches of discussions and it's unknown what's supported
the most.


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


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


Based on those issues and PHP, I propose moving the discussions elsewhere -
to some kind of modern platform. Since this is quite a big change in the
processes used, I imagine an RFC would be needed. But before I do that I
want to measure the reactions. If it goes well, I'll proceed with an RFC
draft.


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


There are basically two choices here - a messenger-like platform (i.e.
Slack, Teams) or a developer focused platform like GitHub. While messengers
certainly work, they're more focused on working with teammates rather than
actual discussions. They usually don't have a simple way to navigate
publicly and are poor at separating multiple topics into threads. Some
projects use them for that purpose, but it's usually a worse experience
than what GitHub provides.

GitHub is already used by PHP for both the source code and the issues, so
that is a good candidate, especially since it's a platform designed to
handle cases like this. Also, that should be a much easier transition now
that the source and issues were moved to GitHub.

Also, to be clear: I'm not proposing to remove all PHP mailing lists; some
of them are one way (i.e. notifications for something) so they should
definitely stay that way. Some of them might not even be used anymore.
However, I want this change to affect all two-way (discussion) mailing
lists if possible. Also, this does not include moving RFCs themselves to
GitHub, only the discussion that happens via email.

What are your thoughts?


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


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


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


Looking forward to your TL;DR

Cheers

Andreas

--
  

Re: [PHP-DEV] Moving PHP internals to GitHub

[Alex Wells]

On Wed, Apr 12, 2023 at 5:09 PM Alain D D Williams 
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.

Re: [PHP-DEV] Moving PHP internals to GitHub

[Derick Rethans]

On 12 April 2023 14:52:52 BST, Alex Wells  wrote:

>What are your thoughts?

Not a chance. Also, who are you? 

cheers 
Derick 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Rowan Tommins]

On Wed, 12 Apr 2023 at 14:53, Alex Wells  wrote:

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



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

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

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

Some starting points off the top of my head:

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

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] Moving PHP internals to GitHub

[Alex Wells]

On Wed, Apr 12, 2023 at 4:57 PM Marco Pivetta  wrote:

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

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

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

Re: [PHP-DEV] Moving PHP internals to GitHub

[Christian Schneider]

Am 12.04.2023 um 15:52 schrieb Alex Wells :
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Alain D D Williams]

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

> Based on those issues and PHP, I propose moving the discussions elsewhere -
> to some kind of modern platform. Since this is quite a big change in the
> processes used, I imagine an RFC would be needed. But before I do that I
> want to measure the reactions. If it goes well, I'll proceed with an RFC
> draft.

Please: No.

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

Your points:

* having to subscribe. An easy one off task.

* Archives: already done

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

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

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

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

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

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

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Marco Pivetta]

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

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

Marco Pivetta

https://mastodon.social/@ocramius

https://ocramius.github.io/


On Wed, 12 Apr 2023 at 15:53, Alex Wells  wrote:

> Hey.
>
> PHP currently uses internals@lists.php.net for communication. That
> includes
> mostly RFCs (or their votings, or their pre-discussion) and sometimes
> questions about the implementation or possible bugs.
>
> While emailing definitely works, it's not the best UX out there. Here are
> some immediate flaws which make the process harder than it should be:
>  - having to subscribe to a mailing list to even see the discussions
>  - supporting public archives such as externals.io to expose discussions
> to
> the public for those who aren't subscribed and keep historical data
>  - having to learn the specific, uncommon rules of replying: bottom
> posting, word wrapping, removing footers. It's not to say any of those
> rules are complex or hard to follow; it's that they're basically
> inapplicable outside of emails, so they're usually not known by newcomers.
> Also popular emailing clients don't do any of that automatically, making
> each reply tedious.
>  - no way of editing a message. Mistakes will always be made, so being able
> to quickly fix them would be nice
>  - no formatting, especially code blocks. Sure, they are possible through
> HTML, but there's no single common way which all of the emailing clients
> will understand - like Markdown
>  - no reactions - it's hard to tell whether something is supported or not.
> This includes both the initiative being discussed and the replies that
> follow. Sure, you can usually kind of judge the general narrative based on
> the replies, but it's not always clear what's in favor. There are usually
> many divergent branches of discussions and it's unknown what's supported
> the most.
>
> Based on those issues and PHP, I propose moving the discussions elsewhere -
> to some kind of modern platform. Since this is quite a big change in the
> processes used, I imagine an RFC would be needed. But before I do that I
> want to measure the reactions. If it goes well, I'll proceed with an RFC
> draft.
>
> There are basically two choices here - a messenger-like platform (i.e.
> Slack, Teams) or a developer focused platform like GitHub. While messengers
> certainly work, they're more focused on working with teammates rather than
> actual discussions. They usually don't have a simple way to navigate
> publicly and are poor at separating multiple topics into threads. Some
> projects use them for that purpose, but it's usually a worse experience
> than what GitHub provides.
>
> GitHub is already used by PHP for both the source code and the issues, so
> that is a good candidate, especially since it's a platform designed to
> handle cases like this. Also, that should be a much easier transition now
> that the source and issues were moved to GitHub.
>
> Also, to be clear: I'm not proposing to remove all PHP mailing lists; some
> of them are one way (i.e. notifications for something) so they should
> definitely stay that way. Some of them might not even be used anymore.
> However, I want this change to affect all two-way (discussion) mailing
> lists if possible. Also, this does not include moving RFCs themselves to
> GitHub, only the discussion that happens via email.
>
> What are your thoughts?
>