[Bug 12992] Editorial comments on Decision Policy, Part 1

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12992

Maciej Stachowiak <mjs@apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Maciej Stachowiak <mjs@apple.com> 2011-06-20 06:46:37 UTC ---
(In reply to comment #0)
> Here are some editorial comments on Revision 1.29 of the Decision Policy:
> http://dev.w3.org/cvsweb/~checkout~/html5/decision-policy/decision-policy-v2.html?rev=1.29;content-type=text%2Fhtml 
> 
> I read the V2 Decision Policy very closely this morning.   One of my major
> comments is that the word "issue" is used both to mean a "comment" and to mean
> a "tracker issue".  Before I complete my suggested list of editorial comments I
> would like Maciej to let me know if/how he is willing to process this first
> part of my comments that covers Section 1 thru 4 in the document.
> 
> 1. Global suggested changes:
> 
> a) Change "chairs" to "Chairs" or "WG Chairs".
> b) Change "bugzilla" to "Bugzilla".
> c) Change "working group" to "Working Group" or "HTML Working Group".
> d) Change "Group" to "Working Group" IFF "Group" is NOT preceded by "Working".

Did all four of these.

> 
> 2. Introduction
> 
> a) I would like to propose that we re-word the following sentence:
> "Second, some comments will not be satisfactory as initially fielded by the
> editor, and will need to be resolved by a decision of the Working Group."
> to the following:
> "Second, some commenters may not be satisfied by how their Last Call or
> pre-Last Call comment is initially process by the editor and the comment will
> need to be resolved by a decision of the Working Group."

Done with s/process/processed/:

"Second, some commenters may not be satisfied by how their Last Call or
pre-Last Call comment is initially proceed by the Editor, and the
commentwill need to be resolved by a decision of the Working
Group. Third, it needs to be very clear to commenters how to get their
input formally considered."

> 
> b) Use the term "comment" instead of "issue".  Change the following text:
> "5. Escalation Process - The tracker-based process by which commenters can
> escalate issues for consideration by the full Working Group."
> to the following:
> "5. Escalation Process - The tracker-based process by which reviewers can
> escalate comments for consideration by the full Working Group.

Changed to:

"The Tracker-based process by which commenters can escalate comments to Issues
for consideration by the full Working Group."

> 
> 3.  Policies Defined in this Document
> 
> a) Change the following text:
> " The policy for enhanced change control and revert requests after pre-LC
> cutoff dates and during LC review."
> to the following:
> "The policy for enhanced change control and revert requests after specific LC
> and pre-LC cutoff dates."

I did not make this change because we are applying the revert policy even
during the Last Call comment period, where the cutoff hasn't passed yet. I did
add the word "specific".

> 
> 4. Overview of Comment Processing
> 
> a) I propose that we REMOVE the following paragraph since it no longer applies:
> "While the primary purpose of this process is for Last Call, we'd like to start
> on the process of migrating the Working Group over to the process right away.
> We've already informally been asking commenters to follow some of these steps."

Done.

> 
> b) The document is very loose about the use of the word "issue".  Sometimes it
> is used as a normal English word where "comment" would be more consistent with
> the rest of the document.
> Change the last sentence below:
> "The Basic Process works primarily through Bugzilla; we believe most comments
> on drafts can be addressed this way, without the need to involve the full
> working group. For some issues though, the input of the full Working Group will
> be needed."
> to  the following:
> "For some comments though, the input of the full Working Group will be needed."

Done.

> 
> c) Change the following text to refer to "Tracker issues":
> "Tracker Issues: These record that an editor's resolution was not satisfactory,
> and so the full Working Group must address the issue. Action items and
> informational updates go here. If you are unhappy with the way an editor
> addressed a bugzilla bug, you should be prepared to request escalation to a
> tracker issue."
> to the following:
> "Tracker Issues: These record that an editor's resolution was not satisfactory,
> and so the full Working Group must address the comment. Action items and
> informational updates go here. If you are unhappy with the way an editor
> addressed a bugzilla bug, you should be prepared to request escalation to a
> tracker issue."

Done.

> 
> d) Avoid using the confusing phrase "issue tracker issue".  Change the
> following:
> "Change Proposals: These documents will describe and justify a particular
> proposed spec change. They are needed to make progress on resolving issue
> tracker issues. If you want to have an issue addressed after escalation, you
> should expect that you will have to write a Change Proposal, or convince
> someone else to do so."
> to the following:
> "Change Proposals: These documents will describe and justify a particular
> proposed spec change. They are needed to make progress on resolving tracker
> issues. If you want to have an comment addressed through escalation to a
> tracker issue, you should expect that you will have to write a Change Proposal,
> or convince someone else to do so."

Done.

> 
> 5. Basic Process
> 
> a) Use the term "comment" instead of "issue" consistently.
> Change the following:
> "The Basic Process describes the overall handling of an issue;"
> to the following:
> "The Basic Process describes the overall handling of a comment;"

Done.

> 
> b) Use the term "comment" or "problem" instead of "issue" consistently.
> Change the following:
> "Issues can be brought up initially by email, if discussion is needed before
> the issue is clear enough to file a bug. Commenters may go directly to the next
> step if they are very clear on their issue already."
> to the following:
> "Comments can be brought up initially by email, if discussion is needed before
> the problem is clear enough to file a bug. Commenters may go directly to the
> next step if they are very clear on their problem already.

Done.

> 
> c) Use the term "comment" or "problem" instead of "issue" consistently.
> Change the following:
> "Issues should be filed as bugs in W3C Bugzilla to be formally considered."
> to:
> "Comments should be filed as bugs in W3C Bugzilla to be formally considered."

Done.

> 
> d) Use the term "comment" or "problem" instead of "issue" consistently.
> Change the following:
> " Although editors may field issues through other forums if they wish, we will
> require editors to address all bugzilla bugs."
> To:
> "Although editors may field comments through other forums if they wish, we will
> require editors to address all bugzilla bugs."

Done.

> 
> e) Use the term "comment" or "problem" instead of "issue" consistently.
> Change the following:
> "Only one issue—please use separate bugs for separate issues."
> To:
> " Only one problem—please use separate bugs for separate comments."

I changed it to:

"Only one specific problem&mdash;please use separate bugs for separate problems
with the spec."

> 
> e) Use the term "comment" or "problem" instead of "issue" consistently.
> Change the following:
> "A resolution may be entered by someone other than the editor if they can
> explain why the spec already addresses the issue."
> To:
>  "A resolution may be entered by someone other than the editor if they can
> explain why the spec already addresses the comment."

Done.

> 
> f) Change the following:
> "Bug is the same issue as another bug. Does not require a full editor's
> response."
> To:
> ""Bug is the same comment as another bug. Does not require a full editor's
> response."

Made it: "Bug is reporting the same problem as another bug."

> 
> g) Change the following:
> "Once reopened, the issue returns to step 1. 5.d. No: Escalate to Issue"
> To:
> "Once reopened, the comment returns to step 1. 5.d. No: Escalate to Issue"

Done.

> 
> h) Change the following:
> ===
> If the commenter is dissatisfied with the resolution and does not believe it is
> productive to ask the editor to reconsider, he or she may ask to escalate the
> issue to the issue tracker. A commenter with Tracker access can raise an Issue
> directly. A commentor without tracker access should apply the TrackerRequest
> keyword, and should suggest a title and text for the tracker issue. Team
> contacts or other volunteers with access will move TrackerRequest issues into
> the tracker. Note: A bug may be escalated by anyone who is dissatisfied with
> the resolution, not just the original commenter. 
> 
> The issue tracker issue should reference the original bugzilla bug. The
> bugzilla bug will reference the issue and have the TrackerIssue keyword added.
> ===
> To:
> ===
> If the commenter is dissatisfied with the resolution and does not believe it is
> productive to ask the editor to reconsider, he or she may ask to escalate the
> comment to the issue tracker. A commenter with Tracker access can raise an
> Issue directly. A commentor without tracker access should apply the
> TrackerRequest keyword, and should suggest a title and text for the tracker
> issue. Team contacts or other volunteers with access will move TrackerRequest
> issues into the tracker. Note: A bug may be escalated by anyone who is
> dissatisfied with the resolution, not just the original commenter. 
> 
> The tracker issue should reference the original bugzilla bug. The bugzilla bug
> will reference the tracker issue and have the TrackerIssue keyword added.
> ===

Done.

> 
> i) Change the following:
> "If the commenter is unsatisfied with the editor's response, but does not wish
> to pursue the issue further by escalating or reopeneing, the commenter should
> indicate that by changing the bug state to CLOSED and add the Disagree
> keyword."
> To:
> "If the commenter is unsatisfied with the editor's response, but does not wish
> to pursue the comment further by escalating or reopeneing, the commenter should
> indicate that by changing the bug state to CLOSED and add the Disagree
> keyword."

Done.

> j) Change the following:
> "Editor has addressed issue, waiting for review by verifier.*"
> To:
> "Editor has addressed comment, waiting for review by verifier.*"

Done.

> k) Change the following:
> ===
> The issue is settled, and reporter formally objected to WG. 
> The issue is settled, and the reporter disagreed, but not as Formal Objection
> The issue is settled, and the reporter agreed with the final outcome.
> ===
> To the following:
> ===
> The tracker issue is settled, and reporter formally objected to WG. 
> The tracker issue is settled, and the reporter disagreed, but not as Formal
> Objection The tracker issue is settled, and the reporter agreed with the final
> outcome.
> ===

Done.


In addition to these changes, I capitalized occurrences of "Tracker", "Tracker
Issue", "Editor", and "Editor's Resolution".

Diff can be seen here:

http://dev.w3.org/cvsweb/html5/decision-policy/decision-policy-v2.html.diff?r1=1.32&r2=1.33&f=h

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 20 June 2011 06:46:40 UTC