Documentation priority values

[Sheppy]

One nice feature to Florian's doc tracker that we've been using
(http://beta.elchi3.de/doctracker) is that it lets us prioritize bugs.
We have not established a real meaning to the priority scale, and I'd
like to propose one. This is a five-point scale, with 1 being the most
important and 5 being the least. I'm inviting discussion on this
proposal:

1: Must be documented no later than 1 week after arriving on Aurora.

2: Must be documented no later than 1 week after arriving on Beta.

3: Must be documented no later than 1 week after release.

4: Must be documented before the next release.

5: Meh. Whenever.

Any thoughts on this?

Eric Shepherd
Developer Documentation Lead
Mozilla
http://www.bitstampede.com/

[David Bruant]

Le 27/03/2012 17:23, Sheppy a écrit :
> One nice feature to Florian's doc tracker that we've been using
> (http://beta.elchi3.de/doctracker) is that it lets us prioritize bugs.
> We have not established a real meaning to the priority scale, and I'd
> like to propose one. This is a five-point scale, with 1 being the most
> important and 5 being the least. I'm inviting discussion on this
> proposal:
>
> 1: Must be documented no later than 1 week after arriving on Aurora.
>
> 2: Must be documented no later than 1 week after arriving on Beta.
>
> 3: Must be documented no later than 1 week after release.
>
> 4: Must be documented before the next release.
>
> 5: Meh. Whenever.
>
> Any thoughts on this?

I agree. Reading your blog post [1] and the idea of coordinating with
evangelists and engineer, I realized that:
* Regarding the top priority, I think it should not be "no later than 1
week after arriving on Aurora", but rather "before th Hacks post" since
there is always one on Aurora. Assuming there are few of these, we can
focus on these and the evangelists can review the different articles and
make sure it's of sufficient quality before posting on hacks.
I'm not sure people go read the doc when there is an Aurora per se, but
I'd guess that the post on hacks brings in decent traffic to the
features in the blog post.
* Likewise for Beta and Release

Communication-driven documentation in a way :-)
It also shares the responsibility of the quality of the doc to the
evangelists.

David

[1]
http://www.bitstampede.com/2012/03/29/documenting-the-important-stuff-first/