The Problem of Acquiring Knowledge
To learn about a project, people don't read process manuals or language specifications. This is because they want to apply processes, not read about them. Moreover, they want different levels of detail at different times.
Processes are not just textual guidelines for reading pleasure. They need to be helpful and available when people are actually developing software.
Currently, the majority of existing processes are published as books and static web sites—shared resources that practitioners are expected to sit down and read. And we know that practitioners do not "read" per se—they will look the odd thing up on the Internet, but not read long, scrolling pages of text. When they are actively engaged in developing software they want succinct, focused, unambiguous guidance that will immediately help them undertake their work, and not long explanations, anecdotes, and academic treatises that justify the techniques they are trying to apply.
A consequence of this is that it doesn't make sense to write a lot of long and lengthy process descriptions. Process documentation needs to be presented in a new way, one that provides the practitioners with the information they need when they need it; leaving the books and knowledgebases to publish the academic foundations that the processes draw upon. Let the processes facilitate the active development of the software and the application of the practices the team selects.
