Re: Editor's TODO list

Good man, thanks, i've missed it!

I'll be adding the 3 issues i've closed in the main issues list.

Jean-Jacques.

Martin Gudgin wrote:
> I've created a skeleton editor's TODO list and checked it into CVS[1].
> This is based on the SOAP 1.2 editor's TODO list, so Jean-Jacques should
> find it very familiar. For everyone elses benefit here is how I see it
> working.
> 
> Each row in the table has the following columns:
> 
> Issue - The issue number in our issues list that the editorial task
> relates to ( if any )
> 
> Spec Part - The part of the spec the task relates to. Either Part 1,
> Part 2 or Both.
> 
> Description - A description of the changes required in order to complete
> the task. This can be detailed information or it may just say something
> like 'Incorporate issue resolution'.
> 
> Resolution - A description of what was ACTUALLY done. Most often this
> will match the description column. In some cases, especially with
> editorial issues, it may vary somewhat from the description column.
> 
> Prority - One of High, Medium, Low. This is used to prioritize editorial
> tasks. Most will be medium. If we have a task which the WG is blocked on
> ( the group can't usefully discuss anything until we've made the changes
> ) then that would be High priority. Things which are classed as 'nice to
> have' are typically Low. For example, in XMLP during last call, most
> substantive issue resolutions were Medium. Issues classed as purely
> editorial by the WG were prioritized as Low.
> 
> Status - This is typically either Pending ( i.e. not done yet ) or Done,
> along with author initials and a date in CCCCMMYY form. There is usually
> a corresponding entry in the change log in the spec with the same date.
> Occasionally, where a task is large, this column may contain partial
> info ( e.g. "Updated Part 1, still need to update Part 2" or "Section 4
> has been deleted, still need to make changes to Section 5" ). You can
> also use this field to 'grab' a task  (e.g. Working on it now, MJG
> 20021004 ) although I would tend to send out mail to the editors anyway
> to tell them what I was about to do.
> 
> So each row in the table represents an editorial task, typically one
> which is self-consistent ( i.e. doing it on it's own doesn't leave the
> spec in a weird state ). It's OK to break up an issue resolution into
> multiple tasks where that makes sense although it's not necessary to do
> so. In the HTML markup each row has a class attribute. This can be one
> of:
> 
> Open - task is open and still needs to be completed
> 
> Closed - task is complete
> 
> Pending - task is awaiting input from WG. This is typically used when
> the editorial team have had difficulty incorporating an issue resolution
> for some reason.
> 
> Subsumed - task has been subsumed by another task. For example,
> sometimes one issue resolution will render another moot. The task it has
> been subsumed by should appear in the Resolution column. 
> 
> Cancelled - Task has been cancelled. A reason should be recorded in the
> Resolution column. 
> 
> Editorial - This class has been used in XMLP for tasks related to issues
> marked editorial. Tasks are marked open until the edits of the spec are
> complete and then the task is marked editorial to remind the editors to
> send closing text to the originator of the issue and our comments list.
> Once that mail has been sent the task is marked closed.
> 
> 
> Whenever a task moves from one class to another the Status column should
> be updated, typically with something like:
> 
> 	Done. MJG 20021004
> 
> 
> Currently the table is empty apart from one task for Part 2 which I
> remembered from talking to Jeff.
> 
> I plan to populate the table as appropriate over the next few days.
> Please add anything you are aware of that needs to be in there. I will
> be sweeping the minutes going back to February just to be sure. I will
> NOT be putting things in here that are already incorporated into the
> spec. We'll just use it going forward.
> 
> Hope this makes sense, if you have any comments, questions or
> suggestions please shout. In my experience over on XMLP maintaining this
> doc wasn't very much work and it did help us keep track of what needed
> doing. 
> 
> Gudge
> 
> P.S. remember to run "cvs update" often
> 
> [1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/edtodo.html

Received on Friday, 4 October 2002 15:06:48 UTC