Re: Editor's TODO list

                                                                                                               
                                                                                                               
                                                                                                               


Hi Gudge,

Thanks for settign this up! I think it'll help us all be aware of what the
other editors are up to.

In addition, I would like us to send a note to each other when we change
the document - basically I'm saying that I'd rather a "push" of the info
rather than "pull" via updating the CVS repo and checking the document.

I will be very happy to send mail to all when I do make changes.

(We could get a mailing list set up in W3C I'm sure to make this easier.)

Sanjiva.


"Martin Gudgin" <mgudgin@microsoft.com> on 10/04/2002 11:49:48 PM

To:    "W3C Public Archive" <www-archive@w3.org>, "Jean-Jacques Moreau"
       <moreau@crf.canon.fr>, <roberto.chinnici@sun.com>, Sanjiva
       Weerawarana/Watson/IBM@IBMUS, "Jeffrey Schlimmer"
       <jeffsch@windows.microsoft.com>
cc:
Subject:    Editor's TODO list



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 Sunday, 6 October 2002 23:09:40 UTC