3 ms·

> If you haven't even mastered sending a plaintext email, , I really wouldn't expect you to be able to constructively contribute to kernel development. That's

> If you haven't even mastered sending a plaintext email, , I really wouldn't expect you to be able to constructively contribute to kernel development. That's entirely BS. To contribute to these projects (my experience is contributing to Git), you need to respect a dozen conventions that seem to come from another age. Just subscribing to the mailing list is not trivial for somebody in their twenties that never had to do something like that: it's the sort of things that's easy in retrospect, but the UX is hard to discover and the lack of parallel with other tools we regularly use (such mailing lists aren't a thing that most devs use) adds a huge amount of friction. And then you need to find somewhere that explain the conventions to try and contribute and figure out how to configure your email client, how to get a patch for your commits, how to insert your patch in your email, how to write an acceptable email subject and an acceptable email body and how it relates to your commit message, who you should CC, how to handle multi-commits contributions, how to answer emails (while respecting another half-dozen conventions)... It's not impossible, but there's a dozen things you need to figure out, half of them you don't even _know_ you need to figure out, so it's a lot of friction. This friction might be a good thing (that's another debate), but saying "you just need to be able to send a plaintext email" is completely false and dismissive.

adwn 6y ago
> It's not impossible, but there's a dozen things you need to figure out [...] Most of those things don't go away if you send a pull request via the Github web interface, because they boil down to "follow the rules and guidelines of the Linux kernel developers". Oh, and not everyone is intimately familiar with the Github pull request interfaces.
u801e 6y ago
> That's entirely BS. To contribute to these projects (my experience is contributing to Git), you need to respect a dozen conventions that seem to come from another age. Just subscribing to the mailing list is not trivial for somebody in their twenties that never had to do something like that This belief that people aren't able to figure out things on their own is the problem. You're basically telling people that it's hard and they'll never figure it out. You're telling people that there are so many things they need to do that they'll never be able to do them. Have you ever considered that these statements themselves are ones that drive away potential contributors? Why not let people make their own judgment about the process after they've gone through it instead of adding your own bias to it? > And then you need to find somewhere that explain the conventions to try and contribute and figure out how to configure your email client, how to get a patch for your commits, how to insert your patch in your email, how to write an acceptable email subject and an acceptable email body and how it relates to your commit message, who you should CC, how to handle multi-commits contributions, how to answer emails (while respecting another half-dozen conventions) This is all described in the submitting patches[1] document in the source tree. It even links to an interactive tutorial regarding how to set up git-send-email[2] [1] https://github.com/torvalds/linux/blob/master/Documentation/process/submitting-patches.rst https://github.com/torvalds/linux/blob/master/Documentation/... [2] https://git-send-email.io/ https://git-send-email.io/

adwn 6y ago

> It's not impossible, but there's a dozen things you need to figure out [...] Most of those things don't go away if you send a pull request via the Github web interface, because they boil down to "follow the rules and guidelines of the Linux kernel developers". Oh, and not everyone is intimately familiar with the Github pull request interfaces.

u801e 6y ago

> That's entirely BS. To contribute to these projects (my experience is contributing to Git), you need to respect a dozen conventions that seem to come from another age. Just subscribing to the mailing list is not trivial for somebody in their twenties that never had to do something like that This belief that people aren't able to figure out things on their own is the problem. You're basically telling people that it's hard and they'll never figure it out. You're telling people that there are so many things they need to do that they'll never be able to do them. Have you ever considered that these statements themselves are ones that drive away potential contributors? Why not let people make their own judgment about the process after they've gone through it instead of adding your own bias to it? > And then you need to find somewhere that explain the conventions to try and contribute and figure out how to configure your email client, how to get a patch for your commits, how to insert your patch in your email, how to write an acceptable email subject and an acceptable email body and how it relates to your commit message, who you should CC, how to handle multi-commits contributions, how to answer emails (while respecting another half-dozen conventions) This is all described in the submitting patches[1] document in the source tree. It even links to an interactive tutorial regarding how to set up git-send-email[2] [1] https://github.com/torvalds/linux/blob/master/Documentation/process/submitting-patches.rst https://github.com/torvalds/linux/blob/master/Documentation/... [2] https://git-send-email.io/ https://git-send-email.io/