Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119996
Message-ID: <d76cbc26-e657-5fa2-1086-2e69b7aaebfb@gmail.com>
Date: Wed, 12 Apr 2023 21:05:28 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.1
Content-Language: en-GB
To: internals@lists.php.net
References: <CABigaAUZAC-UgcajT5anUFJOxzTxMzNip34Jcst16A23ogpSLQ@mail.gmail.com>
 <20230412140920.GD2480@phcomp.co.uk>
 <CABigaAWR6cn735WKY7G0EpYucJ49qoX=WrTw3uR_vHooy8Pr2Q@mail.gmail.com>
 <CALKiJKoWexu8vOYqtEFnRnz1=+O1_srkLgfgCEz6bSDDnpNSkQ@mail.gmail.com>
 <1f0773ce-5d3c-ae8c-d908-7489d580d0ba@processus.org>
 <CABigaAWJXJaxAbkax1=G4UyHpo5OOdzrSjSVbMWO=8fayOivSg@mail.gmail.com>
 <CAO__Xv5oEpFPVr3reNew63C7xna58ufwhBSgtvUWTFgXv=VZDA@mail.gmail.com>
 <001701d96d68$a4cbb420$ee631c60$@roze.lv>
 <CAO__Xv7asMe0J_p8kt6LGV=Ut+Pi4vHhotjN1_U5_Dy3-1ig8Q@mail.gmail.com>
 <31518116-53ca-ca6a-a54d-032d9d2e0b91@gmail.com>
 <CAO__Xv7Ksx_F=D1fgRgnB2wtNzGRHo8uZmWCOCGL7CH=-7pYiw@mail.gmail.com>
In-Reply-To: <CAO__Xv7Ksx_F=D1fgRgnB2wtNzGRHo8uZmWCOCGL7CH=-7pYiw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Moving PHP internals to GitHub
From: rowan.collins@gmail.com (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]