Communicating requirements to kernel developers

It's very easy, as the CGL and TALPA experiences show, for the verdict of 'this is not suitable' to be pronounced on any definition. "It's too specific". "It's too general". "It's too prescriptive." "It's too vague." It's probably easy for a well-versed reader of the LKML to give examples where different kernel developers have given differing pronouncements on these scales. Having been a victim of the specification game - where each revision of the specs comes back from the review as being too far in some other direction - I would suggest an obvious way to correct this problem.

Kernel developers should get together and draw up some guidelines for submitting development requests. They should include examples of what they want to see as well as examples of the extremes that won't be accepted. This should be written in fairly simple english and should be as reasonable and useful as possible. Giving examples of what requests have worked and what haven't in the past would also be a good way of helping people or groups new to the process to understand what's needed to make something that will really work for everyone. No-one minds being told to RTFM if there's a F good M there to R.

It's not even obvious whether the LKML only allows subscribers to post - to state that "[t]hey know where LKML is" is just being cliquey.

OTOH, the one thing that the rest of the world needs to know about linux kernel developers is that they are always busy. It's not a case of them sitting around wondering what they're going to do next, there's always (AFAICS) something to work on. We can hardly go to them and say "here's a big spec, we expect it built by next Monday" and expect code, let alone a polite response.

Have fun,

Paul