Earlier quoted context omitted.
Well, if you want to be more likely to get reaction from any one of 10 or so odd people the typical patch series goes to directly (sometimes simply because they may have contributed some code to some file you're also modifying now) + hundreds more on a bunch of subsys and more general mailing lists, forcing them to register on some random web service of your choice and then monitor it for further communication and re…
I'm not sure why you think I have a problem with mailing lists or not (I regularly use them myself), when the point of this discussion is about starting points for interested folks in Linux kernel or OS development in general. I just made a simple comparison on how different projects do code reviews from an outsiders perspective. The clear misinterpretation happens when I said 'beginners eyes' to assume that I'm some…
I contributed various things to the Linux kernel over the years across many subsystems. Each time I only had to prepare a list of recipients and send the patch series to all of them. Often times the patch series involved multiple subsystems.
In the world where one maintainer is using github, the other his private gitlab instance, one is using gerrit, and the third gitea or whatever, and some holdout still accepts only mailing list contributions,... contributing for people like me who don't get paid for most of their work would be so convoluted, that I would not.
While learning how to send a patch series via e-mail, while it takes some time to learn, allows me to contribute to any part of the Linux kernel via a single workflow, that is easy to replicate.