RE: [w3c sml] Action 108 - tracking bugs

I only meant that, for a 'needsAgreement' bug, there must be agreement
about what the group intends and sometimes discussion/agreement is
easier if some general text is proposed and sometimes the person doing
that is not an editor. (E.g., the group may ask the bug submitter to
propose text.)  In this case, editorialWithReview will not be
appropriate (at that point).
At any rate, it appears that we need a new keyword to be used when the
group sends the bug to the editors but definitely wants to review the
text before it is committed. If everyone agrees, I'll document this in
the process diagram. 
Let me know.


From: [] On
Behalf Of John Arwe
Sent: Friday, August 24, 2007 11:31 AM
Subject: RE: [w3c sml] Action 108 - tracking bugs

Sure, if we defined update review process to be part of the
needsAgreement process then editorial+review would be redundant.  I was
assuming we were using a schema-like model where we arrived at
ideological consensus through discussion and at that point the
transition into editorial happened (and even in Schema, if I heard right
not all editorials actually come back to the group for review so the
same bifurcation occurs).  If drafting all the changes is part of
needsAgreement, that makes it sound like the editor(s) just cut and
paste ... which I think is a gross oversimplification vs current
reality, no?  Or am I thinking of it too black/white, and the
needsAgreement phase gets it say 80% there but the editor when
incorporating the agreed to ideas is expected to look for other areas of
the spec that need to be hit (like the "schema profile" case, where a
section got removed but another half dozen similar bits of text live on
to mislead readers)?  We can do it pretty much any way as long as we are
all working off the same understanding. 

I am positive with some of the changes in the pipe like aligning with
Schema terminology that we will need to carefully review some changes.
Their terms are a complete world unto themselves, and what looks like a
simple immaterial improvement can drastically alter the semantics. 

Best Regards, John

Street address: 2455 South Road, Poughkeepsie, NY USA 12601
Voice: 1+845-435-9470      Fax: 1+845-432-9787 

"Smith, Virginia (HP Software)" <> 

08/24/2007 01:53 PM 

John Arwe/Poughkeepsie/IBM@IBMUS, <> 
RE: [w3c sml] Action 108 - tracking bugs


The original intent was to leave the requirement for review up to the
editor after making an editorial change. 
I think a key point here is that anyone may be asked to come up with
proposed text, not just editors. 
My preference is that, in the case where the group wants to see some
text before approving, it is not really an 'editorial' task. Anyone in
the group with the appropriate expertise could be asked to come up with
proposed text that explains a point. (I believe we've asked non-editors
to do this a few times already.) This person should be assigned the bug
while it is still in 'needsAgreement'. Then after the text is submitted
and agreed upon by the group, it is moved to 'editorial'. In my mind, an
editorial task is a editing task where that task is reasonably
well-defined. The editor still has the option to move it to needsReview
if he/she feels verification is needed before resolving. 
We could still have an 'editorialWithReview' keyword. This could cover
an in-between case. 


From: [] On
Behalf Of John Arwe
Sent: Friday, August 24, 2007 9:55 AM
Subject: Re: [w3c sml] Action 108 - tracking bugs

Reading through this, it confirms we have a process "bug".  There are
two exits from Editorial, one needing review by the group of the
proposed change (needsReview) and the other going straight to resolved
w/o that review.  We already encountered this once in practice, where
Kumar had to put a comment in the bug so he wouldn't forget to review
the proposed change with the group. 

Seems to me we need to separate the two, eg editorial and
editorialReview or some such. 

Best Regards, John

Street address: 2455 South Road, Poughkeepsie, NY USA 12601
Voice: 1+845-435-9470      Fax: 1+845-432-9787 

"Smith, Virginia (HP Software)" <> 
Sent by: 

08/02/2007 04:52 PM 

[w3c sml] Action 108 - tracking bugs


Please review the attached diagram. This is a proposal from the editors
to track the state of bugs. The ovals are actions performed by the WG
and the rectangles represent keywords we can use to track the bug
status. This proposal is a (very) simplified version of what the schema
group is doing. 

Keywords (they are lower case / camel case):

No keyword - the bug is new and ready for triage.

'needsAgreement' - the bug is being discussed or otherwise waiting on
some action and not yet ready for the editors.

'editorial' - the bug is ready for an editor to take it and perform the
required editorial action based on the resolution agreed upon by the WG.
Note that anyone entering a simple 'typo' bug should add this keyword
when they submit the bug so we don't spend time on triage for typos.

'needsReview' - the editorial change is complete but the editor would
like the WG to review the change. This state may be skipped. That is,
the editor may choose to move the bug directly to 'resolved' if she
feels that no review is necessary. 

'resolved' - the bug is resolved.

I will change the bugs we reviewed today to add the appropriate keywords
- assuming I don't get any major objections to this proposal.

[attachment "BugzillaProcess.pdf" deleted by John Arwe/Poughkeepsie/IBM]

Received on Friday, 24 August 2007 20:07:24 UTC