| Prev | Next |
There's too much raw information. It needs to be processed. This is an editorial function.
An editor wades through a slush pile of submissions to find publishable material, cleans it up, and stitches it together to form the next issue.
All editors do this, from book publishers to open source project maintainers. The decide what does and does not belong in their project by exercising veto power, and in doing so they fight off sturgeon's law.
"90% of everything is crap" - Theodore Sturgeon
"A maintainer's job is to say no." - Alan Cox
Writing new code/documentation is a luxury a busy maintainer rarely gets to do. All their time is taken up reviewing other people's submissions.
Aside on how rejection can be good: bouncing your submission back isn't the end, it just means it needs more work. This is normal. If it was worth the editor's time to explain what's wrong with it rather than just "hell no" (or a form letter, or no reply at all), this is a good sign. (If they want to discourage you, they'll let you know.)
Which 90% do you throw out, and how do you polish up the rest?
That's the hard part...
In our case, focusing on the kernel. Not userspace. (Let the Linux Documentation Project handle userspace. It's important to know what your project isn't. Feature creep.)