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