For me, this is one of <i>the</i> most interesting aspects to the development of Linux, and one I've been studying for <i>years</i> at various levels.<p>Even though I don't understand a lick of most of the code, watching the lkml and the process itself is very quite interesting, however, there are a few ways to try and put the kernel in a better position in the future.<p>Each major release can be considered a "story", for example, the journey of WireGuard from inception to submitting it to the kernel, that's an <i>entire</i> process, involving many, many steps and employs an unlimited number of tools; meeting in person, email, VoIP, Slack and anything you can think of.<p>Conversations that turn into code are a vital part of kernel development, but I feel is less well known (after all, we just see code shuffling about git repos).<p>Each bit of code is possibly hours of work, represents many conversations, and yet, git cannot (and does not), preserve the history of how code reaches Linus' tree.<p>So, how can we improve this situation?<p>Document, document, document!!<p>I'd love to see someone like Greg Kroah-Hartman, David Miller, Stephen Rothwell et al document, extensively, how they do their work.<p>I'm talking about high resolution; screen captures, text, images, audio and anything else that we can preserve going forward, perhaps all neatly tucked away in a git repo and backed up many, many times.<p>Seriously, we're at risking of losing a core vital understanding of <i>how</i> people do their work, especially those who are core to the Kernel. Of course, people may develop new methods, but I feel the kernel is quite mature and the processes in theory are quite stable too (such as how Greg actually releases a stable kernel once a week).<p>Of course, not everything can be documented, older software gets older, and someone's favorite email client may not be transferable, but the general process can be.<p>So yes, this is something to think about and prepare for, otherwise it may hit the kernel quite hard.