RE: Editor's TODO list

On Mon, 2002-10-07 at 06:42, Martin Gudgin wrote:
> If we talk nicely to Philippe he may be able to get CVS to send out mail
> automatically. Philippe?

Sure it's possible. Our mirroring system is in fact using a similar way
to propagate the changes. I'm going to talk nicely to Ted since he is
the one behing our mirroring system setup.
So the plan is:
the cvs system sends a spa^H^H^Hmessage for each update of
dev.w3.org:2002/ws/desc/wsdl12/edtodo.html
to a mailing list specific to the editors.
Is that ok?

> 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 ).

That's the part I like with CVS. You cannot blame me for the merge
troubles :)

Philippe

> 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
> > 
> > 
> > 
-- 
Philippe Le Hegaret - http://www.w3.org/People/LeHegaret/
World Wide Web Consortium (W3C), Technical staff

Received on Thursday, 10 October 2002 10:21:40 UTC