Please read Inclusion of Doc spec

[Daniel Robitaille]

> Please read and give feedback on the Inclusion of Docs spec before
> tomorrow (Montreal time) as it is likely to become an approved spec.
>
> https://launchpad.net/distros/ubuntu/+spec/inclusion-of-docs
>

A few comments on things in that spec:

"Karriane works in the doc team. She doesn't really know who to
contact to get documentation written on a specific goal.".

  Not sure why this user case is in there.  That's has nothing to do
with the docs themselves, and the schedule of their inclusion in
Dapper, but everything to do with their marketing; and the awareness
of the DocTeam efforts by the community
(https://wiki.ubuntu.com/DocumentationMarketing).  It seems to be two
totally different issues.


"Every Wednesday and Saturday, Daniel Holbach or another MOTU will
build and upload a new package. This will include both Ubuntu, Kubuntu
and Xubuntu docs.".

Personally I would say once a week is enough, plus once just before
the freeze of any milestones (do we have a name yet for Dapper? 
nests? flocks?).  Twice a week seems to be a lot for most of the
developmental cycle.  (unless it is dead easy for dholbach to produce
updated packages)


"The docteam should communicate with the distro team so that the best
possible docs are done for the each point release."

how is it going to be done on a technical point of view?  Are we
pushing docs to him manually for creating packages, or is he grabbing
them (manually or automatically)?  In any case, whatever is in the
repos is the latest and greatest we will have. So communication is
always good, but in this case communication doesn't really matter:
whatever is in the repo is whatever should be packaged and released at
that point in time.


"Another important measure to increase the quality of docs is to raise
awareness, during release cycle and at the end of it, so people can
report bugs in Malone."

again, different issue, should be in a different spec on how to raise
awareness. This spec is to get the docs out there in the distro during
the 6-month cycle. Awareness is outside all this and is a marketing
problem.


  "1. wait for the Dapper Release Schedule to evolve
   2. liaise with developer team regarding freezes, specifically the UI freeze
   3. push for fixed dates for the point releases"

Not sure I understand exactly what is #3.  Point releases of what? 
The docs?  Dapper?  The schedule is going to be fixed for Dapper, and
thus for the docs as well.  Not sure what it is to push since
everything will be fixed soon.

 So essentially the DocTeam has to come up with a list of docs it will
produce, a rough ideas of a timeline these docs should  be produced. 
Then wait for the Dapper Schedule, and stick the DocTeam release
schedule on top of their schedule as soon as it is released, and
that's our combined schedule.  And everyone want everything done as
soon as possible AND, all the deadlines as late as possible to allow
for more time to work on things :)

Not sure I will be able to make it to the meeting to discuss this, but
maybe the team should be very conservative in its scheduling, and
leave most of the heavy writing for quite before the end; and leave
the chaos of the few weeks before the release for  finetuning and
general QA of the to-be-shipped docs.  I know it sounds obvious, but
everytime I see a bug report like this
(http://bugzilla.ubuntu.com/show_bug.cgi?id=17768 ), I think it is a
sign we missed somewhere in the QA department of the docs  for Breezy
between the time things were really frozen in Breezy, and the time of
the release; and the quality of the docs suffered.


--
Daniel Robitaille