This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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". 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." 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. 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." 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." 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." 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." 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." 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;" 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. 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." 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." e) Use the term "comment" or "problem" instead of "issue" consistently. Change the following: "Only one issueplease use separate bugs for separate issues." To: " Only one problemplease use separate bugs for separate comments." 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." 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." 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" 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. === 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." j) Change the following: "Editor has addressed issue, waiting for review by verifier.*" To: "Editor has addressed comment, waiting for review by verifier.*" 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. ===
(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 issueplease use separate bugs for separate issues." > To: > " Only one problemplease use separate bugs for separate comments." I changed it to: "Only one specific problem—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