InclusionOfDocumentation

Differences between revisions 2 and 3
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 3 as of 2005-10-31 17:40:01
Size: 3250
Editor: 187_220_103_66-WIFI_HOTSPOTS
Comment:
Deletions are marked like this. Additions are marked like this.
Line 13: Line 13:
The last release was chaotic, and things didn't get written until late in the release cycle. The 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 16:

Michael installs a point release on his hard disk. He should be able to review the help files 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.
Line 17: Line 21:
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 24:

The most important instruments for this specification are
 * a doc team timeline, which will depict the actions, the docteam will take
 * a responsibility table, which will be decided on in a doc team meeting. It 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 21: Line 35:
The timeline currently looks like this:
 * ubz +1 week: docteam meeting (responsibilities)
 * ...
 * talking to developers, writing up, packaging, uploading (before CD release), get users review / bug reports (launchpad assignee (team name): 'ubuntu-doc')
 * ...
 * dapper release -7 weeks: UserInterfaceFreeze (supposedly)
 * dapper release -5 weeks: DocumentationStringFreeze (supposedly)`
 * dapper release -2 weeks: ArtworkDeadline (supposedly)


The responsibility table (on the Wiki) will be decided on in a doc-team meeting. According to it, 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 to 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 ({{{ubuntu-doc}}} team)

Line 22: Line 51:
 -
Line 24: Line 53:
 N/A
Line 27: Line 56:
 0. The current release schedule was not decided on yet, so for the moment there can't be predictable dates at all.
 0. Judging from the Breezy development cycle, it will be quite hard to predict dates of CD point releases (Colony N).
Line 28: Line 60:

 * 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

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 last release was chaotic, and things didn't get written until late in the release cycle. The 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 help files 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.

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, which will be decided on in a doc team meeting. It 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

The timeline currently looks like this:

  • ubz +1 week: docteam meeting (responsibilities)
  • ...
  • talking to developers, writing up, packaging, uploading (before CD release), get users review / bug reports (launchpad assignee (team name): 'ubuntu-doc')
  • ...
  • dapper release -7 weeks: UserInterfaceFreeze (supposedly)

  • dapper release -5 weeks: DocumentationStringFreeze (supposedly)`

  • dapper release -2 weeks: ArtworkDeadline (supposedly)

The responsibility table (on the Wiki) will be decided on in a doc-team meeting. According to it, 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 to 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 (ubuntu-doc team)

Code

  • -

Data preservation and migration

  • N/A

Outstanding issues

  1. The current release schedule was not decided on yet, so for the moment there can't be predictable dates at all.
  2. Judging from the Breezy development cycle, it will be quite hard to predict dates of CD point releases (Colony N).

BoF agenda and discussion

  • UBZ
    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

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