I appreciate the effort here, but in the proposed workflow are missed steps with subscribing to a mailing list. Without proper subscriptions and confirming subscription, your mails with patches will go to trash.
That's not true in general. Many mailing lists accept emails from unsubscribed users, some moderate them (requiring moderator approval for the first post), but I don't know of any which outright rejects such emails.
> Configuring git send-email is trivial, definitively faster than creating an account at some web UI from a "source forge" <snipped>.
You forgot that mailing list requires subscription and in some cases it could be a tricky. Without proper subscriptions and confirming subscription, your mails with patches will go to trash.
In what cases is it tricky? I find that most projects use some version of mailman (like QEMU - https://lists.nongnu.org/mailman/listinfo/qemu-trivial) and then it's just a question of filling out the form and hitting "Subscribe". I cannot remember project I wanted to contribute to, I had to use git+email and it was difficult to subscribe to the mailing list they want me to use.
That’s because Microsoft GitHub is a proprietary monolith. Compare that to the open core & self-hosting of GitLab the more FOSS-positive space where each server (without federation) requires a new sign up, confirmation emails (meaning you already had to go thru email), CAPTCHAs, setting up new keys, etc. That said, you will need to get your email filters in place or you can get a lot of new, unwanted mail (assuming you are required to sign up which often isn’t the case).
Personally, it's not. I'm using GitHub and I also sometimes send patches in emails.
I'm asking specifically what part of subscribing to mailing lists is the tricky part, as that's what parent mentioned. I'm not saying it's easier/harder than GitHub's workflow.
And then every so often mailman hits you up with "I'm receiving all these bounces from your email server!" because all the various garbage anti-spam techniques were not quite thought out with mailing lists in mind or people have lots of misconfigured servers and servers with different acceptance criteria, and it's all a big mess.
Configuring git send-email is only half the battle, anyway - chances are you want to participate in the discussion of your patch, so better figure out how to make sure your email client will not send the forbidden HTML email.
This sounds like hyperbolic brought on by dislike, not a real indicator of time cost/effort. You've already spent more time complaining, than the work done to do these things!
This. You just To: the mailing-list and depending on the project CC: the maintainers.
No subscribing needed. Standard policy on all mailing lists is to reply-to-all so you'll get always CC'ed on replies. This also makes it very easy to pull in more people into a discussion, even across different projects.
Many mailing lists today reject posts from non-subscribers.
Of those that allow posts from non-subscribers, you will find that many are configured such that you will not get a reply, due to "reply-to munging". Your message will go to the list, but with a Reply-to: header designating that list, instead of (or in addition to) setting the more modern mailing-list-related headers.
Reply-to-all isn't a list policy; it's a behavior of the individuals. Some people don't reply to all. They think they are, but only the post author gets their reply. That is one of the motivations behind the Reply-to.
The CC part is highly conflicted. Most maintainers hate double emails, whilst some loudly insist to be CC'd, esp. the Linux kernel folks. So you need to read beforehand the preferred etiquette.
And nevertheless, the tone on mailinglists is entirely different (and mostly extremely childish and unprofessional) than on ticket trackers.
Thats not even close to up to date and is incorrect.
They're only just moving from their 2009 Kernel fork to a fork of Kernel 3.10 which was released in 2013...
Edit: In fact, on second inspection, a lot of the items in that table are either wrong or straight out lies (although I'm assuming the former). I'd hate to think what the community around the product is like but I can only assume they live in a bubble similar to those in the Drupal community that thinks for whatever reason that the product they're using is the one and only / best solution rather than truly evaluating the best tool for the job, as far as I can see it unless that page you linked to truly isn't maintained thats the only way you could end up with that quality of information / misinformation available.
https://github.com/kedder/ofxstatement