Comment by mmooss

Not sure if you've made this experience yet, but the one thing I've learned about being an involved maintainer of a sizeable open source project is that it's mostly about communicating.

You'll be talking to a lot of people and making sure that everyone is on the same page, and that's what's going on here, hopefully. If you just shut up and write code all day, you probably aren't gonna get there and there will be conflict, especially if other people are touching your systems and aren't expecting your changes.

tooling and practice.

First you use a tool designed around following mailing lists. text based mail readers. they represent the threads in a compact form, allow to collapse threads and have them only resurrect if new content shows up. they also allow for pattern based tagging and highlighting of content "relevant to you", senders of interest, direct mentioning of your name/email address, ... and minor UX niceties like hiding duplicate subject in responses (Re: yadda <- we know that, it's at the top of the thread already)

such tool ergonomics allow you to focus on what's relevant to you

Hint: Outlook doesn't cut it.

And then with the right tool you practice, you learn how to skim the thread view like you maybe learned to skim the newspaper for relevant content.

and with the right tool and practice in place you can readily skim mailing lists during the day when you feel like it and can easily catch up after vacation.

Writing code in large teams is maybe 20% of time spent working, guesstimating on average. There are great engineers writing absolutely nothing mergable for weeks.

This hacker news post has more comments than the mailing list thread that inspired it. A roughly comparable amount of text. It’s a lot, but certainly doable.

That + having a couple decades to refine your email client setup goes a long way.

I imagine this works just like it works for anyone: they prioritize what's important to them, and if they don't get to the things lower on their priority list, that's just life.

I don't think it would be necessary for most kernel developers to read that entire email thread. I feel like I could get through the entire thing in a half hour by ruthlessly skimming and skipping replies that don't tell me anything I care about, and only reading in full and in detail the handful or two of emails that really interest me.

And as a sibling says, a huge part of software development, especially when you're working with a large community of distributed developers, is communication. I expect most maintainers spend the majority of their time on communication, and less on writing code. And a lot of the contributors who write a lot of kernel code probably don't care too much about a lot of the organizational/policy-type discussion that goes on.

One possibility is that they only use a small amount of time, mental effort, and context size to go over all of the messages at a relatively shallow level. If there is anything that lets them send the ball back into somebody else's court without fully digesting a message or thread, they will go for it. That other person will then be responsible for the effort of replying at all, thinking about the subject matter, accounting for other peoples' messages, and composing the reply message itself. They also probably further minimize reading intellectual subthreads, and instead keep practical, concrete items at the top of their stack.

Overall, this means that they will sometimes err on the side of being deaf or dismissive.

First of all, this is what? A month or two of posts? Spreading the time to read out over that make the cost almost go away. You can do it while drinking coffee or whatever, and when reading in better formats (say, in your inbox), you will see what a mail is about and then skip it if you are not interested in this particular tangent.

But also, don't expect this kind of flame war to be a regular thing. Most discussions are a lot smaller and involve few people.