InclusionOfDocumentation

Differences between revisions 2 and 20 (spanning 18 versions)
Revision 2 as of 2005-10-27 18:31:37
Size: 720
Editor: 204_220_103_66-WIFI_HOTSPOTS
Comment: added launchpad link and changed metadata to new LP system
Revision 20 as of 2008-08-06 16:33:47
Size: 2946
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
 * '''Created''': [[Date(2005-10-27T18:31:37Z)]] by JaneWeideman
 * '''Contributors''': JaneWeideman
 * '''Packages affected''':
 * '''Created''': <<Date(2005-10-27T18:31:37Z)>> by JaneWeideman
 * '''Contributors''': JaneWeideman, DanielHolbach, CoreyBurger
 * '''Packages affected''': `ubuntu-doc`
Line 9: Line 9:
Line 13: Line 14:
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.
Line 14: Line 17:

 * 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 wants to know who is working on specific goals.
Line 17: Line 24:
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.
Line 18: Line 27:

The most important instruments for this specification are:
 * a doc team timeline, which will depict the actions the doc team will take
 * a responsibility table (DocteamProjects), which will be decided on in a doc team meeting.
Line 21: Line 35:
=== Code === Every Wednesday and Saturday, somebody from the Distro team (Daniel Holbach agreed to do this for now) 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 23: Line 37:
=== Data preservation and migration === The responsibility 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).
Line 25: Line 42:
== Outstanding issues == The DocteamProjects will be decided on in a doc team meeting. Doc team members should coordinate with developers over specific items/features during writing.
Line 27: Line 44:
== BoF agenda and discussion == 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 - this makes sure that:
 * that typos are fixed,
 * misconceptions are cleaned out
 * and missing items are added.

As the dates of Milestone CDs are not determined yet, it was decided that in the timeframe of the last two milestone CDs (the last one will be RC), the documentation will incrementally
 0. stabilize
 0. don't change screenshots anymore
 0. don't change strings
 0. do the translations
----
CategorySpec

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 wants to know who is working on specific goals.

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 doc team will take
  • a responsibility table (DocteamProjects), which will be decided on in a doc team meeting.

Implementation

Every Wednesday and Saturday, somebody from the Distro team (Daniel Holbach agreed to do this for now) 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 responsibility 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).

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 - this makes sure that:

  • that typos are fixed,
  • misconceptions are cleaned out
  • and missing items are added.

As the dates of Milestone CDs are not determined yet, it was decided that in the timeframe of the last two milestone CDs (the last one will be RC), the documentation will incrementally

  1. stabilize
  2. don't change screenshots anymore
  3. don't change strings
  4. do the translations


CategorySpec

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