Please read Inclusion of Doc spec

[Corey Burger]

On 11/2/05, Daniel Robitaille <robitaille at ubuntu.com> wrote:
> > 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.
>

In the beginning the spec did include stuff about marketing, but that
was split into the DocumentationMarketing spec you mentioned. You can
safely ignore the use case in inclusion of docs and the spec will be
cleaned up today.


>
> "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)
>
>

Mdz was explicitly asked about this twice-a-week schedule and he
approved, as long as something had changed. As for building, it should
become a cron job anyway, and dholbach did not object to it.

> "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.
>
>

Basically this is more of an advisory thing. We should try and sync up
with the devel process as much as possibly, but the world will not end
if we don't.

<snip> Already talked about marketing

>
>
>   "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.

The Colony/Array releases are not currently on a schedule. If
possibly, it would be nice if those were on a schedule.

>
>  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.

Absolutely. Why we need to discuss the division of labour very soon now.

Corey