Developer review of documentation

[Matthew East]

> On Sat, Nov 25, 2006 at 07:55:02AM -0500, Eric Dunbar wrote:
>> On 25/11/06, Mario Vukelic <mario.vukelic at dantian.org> wrote:
>> > [sorry Matt, the pesky list reply again]
>> >
>> > On Fri, 2006-11-24 at 20:56 -0800, Matt Zimmerman wrote:
>> > > The official documentation *is* produced by the community.
>> >
>> > This starts to confuse the hell outta me. Now is it official or isn't
>> > it. By "official" I mean, can I trust as a user that the instructions
>> > given are reasonable correct? Matthew seems to say "no" [1]
>>
>> For me the concern is that an appropriate QAQC (quality
>> assurance-quality control) process has taken place before the info
>> gets posted. For example, for the upgrade path (which sparked this
>> discussion) you'd have expected someone who's "in the know" to have
>> checked over the post before proceeding without caveats (the caveats
>> being added after-the-fact).
>
> There is no formal process in place for this yet, as far as I know, but it
> is needed.  I can arrange developer resources to review documentation
> for correctness before it is published as official.
>
> Doc team: how do you want this to work?

We did some ad-hoc asking developers to review documentation during the
Dapper release cycle and it worked well. Here's what I propose we do.

The documentation team has a number of tasks which it needs to look at
shortly before string freeze. For example, proof reading, checking menu
entry consistency, and so on. Asking developers to review key
documentation for correctness could form part of this process. I suggest
we do it 2 or 3 weeks before string freeze.

We'd need to make a list of the key documentation to be reviewed (this
could include key system documentation, *and* key wiki pages), and
potentially identify the relevant developers who might be able to lend a
hand.

How does that sound as a vague plan?

Matt