wiki-archive/twiki/data/TIPAdmin/DocumentationFundingPriorities.txt,v

head	1.2;
access;
symbols;
locks; strict;
comment	@# @;


1.2
date	2005.12.15.12.40.08;	author RogerHyam;	state Exp;
branches;
next	1.1;

1.1
date	2005.12.15.09.50.50;	author RogerHyam;	state Exp;
branches;
next	;


desc
@none
@


1.2
log
@none
@
text
@%META:TOPICINFO{author="RogerHyam" date="1134650408" format="1.1" version="1.2"}%
%META:TOPICPARENT{name="WebHome"}%
---+ Documenation Funding Priorities 2006

---++ 1. Introduction
We have to decide what we invest our documentation budget in. 
This is an _a la carte_ menu we can pick things off with some approximate costs. Some things are compulsory though! There is a table to track the actual things we are doing here DocumentationTracking2006

Basic principles:
   1 Don't want to pay for things that people will do anyway.
   1 Do want to pay to get things done quickly.

---++ Creating the 6+ initialisation standards
Each one of these is treated separately in the table but in general they all require feedback and consultation of some kind so could be stretched indefinitely!

|*Standard*|*Cost (days)*| *Owner* |*Notes* |
|File Formats| ? |Roger|Could need much discussion.|
|Layout Template| ? |Roger|May need discussion. Hopefully can just copy from another organisation.|
|Cover Page Spec| ? |Roger|XML Schema doc. Should be un controversial but may end up with people complaining...|
|Copyright Notice| ? |Roger?| I will put a very very straw version of this together but we need to find some one to hand ownership to. We at least need to have it checked by some one knowledgable|
|IP Statements| ? | Roger? | Not sure where to start with this. Same position as copyright notice.|
|Process | 2 + production of text | Process Groups | Just a matter of getting the document produced by the process group into the right format to be a standard.|
|Charters| 1 | Process Group | If the process group wants to create standards that define what should be in charters then they need to document them properly. Should be really straight forward| 

---++ Moving an Old Standard into the New System
Presuming the main normative form of the standard is in an acceptable form (e.g. the XML Schemas produced by the last 3 standards but also some of the old standards which are presumably just lists) then this will ‘just’ involve creating 4 documents and putting them in a package with the existing files. The possible costs of this can be broken down.

|*File*|*Cost (days)*|*Notes*|
|Cover Page|1|This should just be like filling in a form. Possibly only 1 hour!|
|Motivation|2|Why does this standard exist? Why was it created? Where does it fit in? Should only take day to write and a day to correct.|
|Rationale|5-10|Explanation of the design decisions taken. This is the difficult one to estimate. For a big complex standard like ABCD2 a picky author may want to work through every structure in it and justify it. This is a difficult thing to do in retrospect and there may be a good reason for not bothering – this doc should really be written when the standard is designed to be valid. A good policy to take for an existing standard may be to say “do as good a job as you can in X days”.|
|Change History|0-5|Most of the existing standards are in their first version so this should just be a holding page. ABCD2 is a second version but I believe they have a list of changes so it shouldn’t take the too long. There may be a case for not admitting changes here that happened prior to the new system in which case this is zero days for every standard.|

So it would seem reasonable to get an existing standard into the new system for the cost of about two weeks work.
One caveat on this is if the standard itself needs work. In this case each one will need to be estimated individually and then two weeks added for associated documents.


---++ Type 3 documents to support standards
These could potentially be a much greater sink for resources and possibly something that can be ‘outsourced’ in some form. 
The above really need to be done by the authors of the standard but a general readable guide could be written by a sympathetic 3rd party all be it with a big contribution from the standards creators.

---++ Specific Ideas for funding.
These are incorporated in DocumentationTracking2006


-- Main.RogerHyam - 15 Dec 2005
@


1.1
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="RogerHyam" date="1134640250" format="1.1" version="1.1"}%
d6 5
a10 2
We have to decide what we invest our documentation budget in. Basic principles:
   1 Don’t want to pay for things that people will do anyway.
d13 12
d31 1
a31 1
|Rational|5-10|Explanation of the design decisions taken. This is the difficult one to estimate. For a big complex standard like ABCD2 a picky author may want to work through every structure in it and justify it. This is a difficult thing to do in retrospect and there may be a good reason for not bothering – this doc should really be written when the standard is designed to be valid. A good policy to take for an existing standard may be to say “do as good a job as you can in X days”.|
d43 1
a43 4

   * Kevin Thealer has big back up - could he get some one to write a user guide to SDD.
   * How friendly is the stuff for ABCD?
   * How about a journalistic style summary of the new TDWG process?
@