InclusionOfDocumentation

Differences between revisions 9 and 11 (spanning 2 versions)
Revision 9 as of 2005-11-02 04:10:23
Size: 3105
Editor: 243_220_103_66-WIFI_HOTSPOTS
Comment: answer mpt
Revision 11 as of 2005-11-03 09:35:59
Size: 2667
Editor: dsl-202-52-55-156
Comment:
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
{{{XXX: MatthewPaulThomas:
 * Are there other packages affected?
  - No
 * How will the raising awareness be achieved?
   See DocumentationMarketing
 * Does the timeline need to be produced before this spec can be approved?
    - No, because the build is a fixed schedule, regardless of release or status of docs }}}
Line 27: Line 20:
  * How does this relate?
Line 45: Line 39:
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. 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. Building on a fixed schedule will make certain that whatever happens during development, point releases contain a package no more than 3 days old.
Line 51: Line 45:
Daniel Holbach will take care of the packaging and get changes in, so that the docs make it into the ISOs. 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. Daniel Holbach will take care of the packaging and get changes in, so that the docs make it into the ISOs. Making people know about the docs during development is part of DocumentationMarketing
Line 53: Line 47:
== Outstanding issues == == Other packages affected ==
Line 55: Line 49:
== BoF agenda and discussion ==

 * UBZ
  0. wait for the Dapper Release Schedule to evolve
  0. liaise with developer team regarding freezes, specifically the UI freeze
  0. push for fixed dates for the point releases
None

Summary

Inclusion of Documentation WIP in milestone releases - have the documentation team map out internal milestones that coincide with distro milestones, instead of doing much of the integration work a few weeks before release.

Rationale

The Breezy release was chaotic, and things didn't get written until late in the release cycle. The ubuntu-doc package didn't get included until right at the end, which left us with less public review than we should have had.

Use cases

  • Michael installs a point release on his hard disk. He should be able to review the online help, and report back if he observes inconsistencies.
  • Karriane works in the doc team. She doesn't really know who to contact to get documentation written on a specific goal.
    • How does this relate?

Scope

The outcome of this spec affects different groups in the Ubuntu development. The doc team heavily relies on this schedule and the Ubuntu developers will have to respect the various Freeze dates that are decided on.

Design

The most important instruments for this specification are:

  • A doc team timeline, which will depict the actions, the docteam will take
  • a responsibility table (DocteamProjects), which will be decided on in a doc team meeting.

The reponsibility table will represent:

  • the different goals for Dapper
  • who of the doc team will write documentation on them
  • who serves as a contact for the documentation author (this will most likely be the assignee of the spec).

Implementation

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. Building on a fixed schedule will make certain that whatever happens during development, point releases contain a package no more than 3 days old.

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

The DocteamProjects will be decided on in a doc team meeting. Doc team members should coordinate with developers over specific items/features during writing.

Daniel Holbach will take care of the packaging and get changes in, so that the docs make it into the ISOs. Making people know about the docs during development is part of DocumentationMarketing

Other packages affected

None

InclusionOfDocumentation (last edited 2008-08-06 16:33:47 by localhost)