RE: Editor's TODO list

If we talk nicely to Philippe he may be able to get CVS to send out mail
automatically. Philippe?

That said, we should all be running CVS update before any editing
session anyway, so it will be easy to see if anything has changed since
the last sync. And the change log in the spec should contain the details
( for SOAP I tend to put more detail into the spec change log than the
CVS change log ).

Gudge

> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@us.ibm.com] 
> Sent: 07 October 2002 04:05
> To: Martin Gudgin
> Cc: W3C Public Archive; Jean-Jacques Moreau; 
> roberto.chinnici@sun.com; Jeffrey Schlimmer
> Subject: 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 Monday, 7 October 2002 06:43:03 UTC