Issues regarding the Last Call documents produced by the QA Working Group (QAWG) should be reported to the QAWG using the forms that are linked from the status sections of those documents. As a last resort, if you cannot use the forms for some reason, you can send mail to www-qa@w3.org (public archives). (The forms will put a copy on this email list and in the archives.)
Comments on this issues list should be sent to the www-qa@w3.org mailing list (Archives).
In this document,
num | Status | Spec | Topic | Class | Date | Title |
---|---|---|---|---|---|---|
LC-71 | Active | IntroGuide | IntroGuide | Substantive | 2003-03-15 | Collected substantive & editorial comments |
LC-68 | Active | IntroGuide | IntroGuide | Editorial | 2003-03-14 | Intro draft |
LC-69 | Active | IntroGuide | IntroGuide | Editorial | 2003-03-15 | Several comments on various parts of Introduction |
LC-3 | Active | OpsGuide | OpsGuide | Substantive | 2003-02-23 | Committment Table and its CPs |
LC-43 | Active | OpsGuide | OpsGuide | Substantive | 2003-03-12 | OpsGL Appendix 1 - Process Document Template |
LC-57 | Active | OpsGuide | OpsGuide | Substantive | 2003-03-12 | GL and timeline of a document |
LC-58 | Active | OpsGuide | OpsGuide | Substantive | 2003-03-12 | Process Document requirement is too specific |
LC-60 | Active | OpsGuide | OpsGuide | Substantive | 2003-03-14 | Structure/Organization of Guidelines |
LC-70 | Active | OpsGuide | OpsGuide | Substantive | 2003-03-15 | Checklist format issue |
LC-72 | Active | OpsGuide | OpsGuide | Substantive | 2003-03-15 | Collected substantive & editorial comments |
LC-59 | Active | OpsGuide | OpsGuide | Editorial | 2003-03-12 | Testability concerns |
LC-1 | Active | SpecGuide | SpecGuide | Substantive | 2003-02-28 | require a "Security Considerations" section |
LC-5 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | Ck 2.2 list of classes |
LC-8 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | checkpoint 1.1 |
LC-9 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | INTRODUCTION section 1.1, second bullet |
LC-11 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | CK 2.3 Category of object: clarification |
LC-13 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | Section 3.3 Conformance and TAs |
LC-15 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | extensions |
LC-16 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | CP 8.4 clarify conformance requirement |
LC-17 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | CP 7.1 deprecated features |
LC-18 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | GL 5 non-hierarchiacal modules |
LC-19 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | CP 4.4 explanation clarification |
LC-21 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | CP 2.4 - relationships of DOV - clarify |
LC-23 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | CP 1.4 vague |
LC-28 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | document organization suggestions |
LC-29 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | questions and suggestions |
LC-30 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | Profile, module, level |
LC-37 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | CP 9.3 |
LC-38 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | CP 9.1 and 9.2 combine |
LC-39 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | CP 8.4 policies for discretionary choices |
LC-40 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | GL7 add obsolete features |
LC-41 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-11 | CP 4.4 derived profile |
LC-55 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-13 | Accessibility |
LC-56 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-13 | Accessibility |
LC-61 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-14 | document product class |
LC-66 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-14 | edition and version DoVs |
LC-67 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-14 | limits of RFC 2119 key words |
LC-73 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-15 | Collected substantive & editorial comments |
LC-74 | Active | SpecGuide | SpecGuide | Substantive | 2003-03-15 | Simplify & consolidate the guidelines of SpecGL |
LC-4 | Active | SpecGuide | SpecGuide | Editorial | 2003-02-19 | no definition for unconditional conformance |
LC-2 | Active | SpecGuide | SpecGuide | Editorial | 2003-02-25 | Grammatical error in Scope |
LC-6 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | Guideline 2, typo |
LC-7 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | Checkpoint 1.2 |
LC-10 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | Section 7 |
LC-12 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | section 3.4 Conformance definition |
LC-14 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | CP 14.1 - clarify conformance requirement |
LC-20 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | CP 3.1 Conformance Requirements - clarify |
LC-22 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | CP 2.3 placement of Checkpoint |
LC-24 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | Introduction, Sect 1.4 |
LC-25 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | Introduction: scope and goals |
LC-26 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | Multiple CPs - It is not applicable |
LC-27 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | Typos, grammar, etc. |
LC-31 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | general |
LC-32 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | 4. Definitions |
LC-33 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | 4. Definitions |
LC-34 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | Section 3.4 Conformance definition |
LC-35 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | Section 3.2 Extensibility |
LC-36 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | Section 3.1 Normative sections |
LC-42 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-11 | GL3: contradiction? regarding examples |
LC-44 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-13 | Grammatical errors |
LC-45 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-13 | Design goal of guidelines |
LC-46 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-13 | Ambiguity |
LC-47 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-13 | Spelling error in Example and Techniques |
LC-48 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-13 | Categories of object not previously clearly defined |
LC-49 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-13 | Complexity in explanation |
LC-50 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-13 | Ambiguity or error? |
LC-51 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-13 | GLs 4, 5 and 6 |
LC-52 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-13 | NOT ? |
LC-53 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-13 | Ambiguity |
LC-54 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-13 | GLs 3, 10, 11, 12 and 13 |
LC-62 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-14 | typos |
LC-63 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-14 | Table of Contents |
LC-64 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-14 | conformance terms |
LC-65 | Active | SpecGuide | SpecGuide | Editorial | 2003-03-14 | sentences and paragraphs (section 3.1) |
num | Spec | Date | Topic | Class | Status | Raised By | Owner |
---|---|---|---|---|---|---|---|
LC-1 | SpecGuide | 2003-02-28 | SpecGuide | Substantive | Active | Alex Rousskov | Lynne Rosenthal |
Title: require a "Security Considerations" section | |||||||
Description: comment about "Overall" :
Any spec SHOULD have a Security Consideration section. Protocol or behavioral specs MUST have a Security Consideration section. Security sections make spec authors think about potential vulnerabilities and address at least some of them before the bad guys can exploit them. These sections are also a great place to warn implementors and users about most security-sensitive areas of the spec and, perhaps, common exploits. IETF's Internet Architecture Board has published the following Internet Draft that may be of use to SpecGL authors: http://www.ietf.org/internet-drafts/draft-iab-sec-cons-03.txt |
|||||||
Proposal: Require "Security Considerations" sections just like we already require conformance sections. | |||||||
Resolution: | |||||||
LC-2 | SpecGuide | 2003-02-25 | SpecGuide | Editorial | Active | Stephanie Troeth | Lynne Rosenthal |
Title: Grammatical error in Scope | |||||||
Description: comment about "Abstract, Status,..." :
"Section 3 defines explains how to make conformance claims that W3C TRs satisfy the requirements of section 2. It defines
conformance for this document"
It seems as if either 'defines' or 'explains' is meant, not both. The first sentence is grammatically incorrect, thus the intended meaning is unclear. The second sentence might seem superfluous, depending on the intended meaning of the first. |
|||||||
Proposal: | |||||||
Resolution: | |||||||
LC-3 | OpsGuide | 2003-02-23 | OpsGuide | Substantive | Active | lynne rosenthal | Lofton Henderson |
Title: Committment Table and its CPs | |||||||
Description: comment about "Guideline 1: Integrate Quality Assurance into Working Group
activities." :
Remove the Committment Table and CP1.1, 1.2, 1.3. These items do not add information and are redundant. To satisfy Level 3 (5 or 7), you must satisfy other checkpoints in the OpsGL. In fact, if we did our jobs right, Level 3 should equal Conformance Level A (satifying all P1), Level 5 should equal Level Double A, and Level 7 = Triple A. Isn't it a goal to get WGs to conform to the OpsGL? That would mean that they must satisfy all the P1 checkpoints. Thus, they must have a committment level to P1. So, why do we use a new term - Level 3. The Table introduces a DOV - called committment level. The OpsGL does not conform to the SpecGL's CPs that require DoVs to address the relationship to conformance, to other DoVs, etc. |
|||||||
Proposal: Remove the Table and CP1.1, 1.2, 1.3. An alternative to removing the Table is to amend it and move it to either the Introduction section (prior to Guideline section) or an Appendix. It should be amended by adding an additional column called, 'checkpoint'. For each row, indicate the checkpoint that applies. | |||||||
Resolution: | |||||||
LC-4 | SpecGuide | 2003-02-19 | SpecGuide | Editorial | Active | Olivier Thereaux | Lynne Rosenthal |
Title: no definition for unconditional conformance | |||||||
Description: comment about "Overall" : In the QAframe-spec glossary (http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/#definitions) there is no definition for the unconditional conformance term. | |||||||
Proposal: add one? :) | |||||||
Resolution: | |||||||
LC-5 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Marc Hadley | Lynne Rosenthal |
Title: Ck 2.2 list of classes | |||||||
Description: comment about "2.1 Identify all classes of product. " : second conformance requirement refers to list of classes but its not clear which list it is referering to. If its the list under guideline 2 then that list is non-exhaustive so requiring people to use that list is somewhat limiting | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-6 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Marc Hadley | Lynne Rosenthal |
Title: Guideline 2, typo | |||||||
Description: comment about "Guideline 2 Identify what needs to conform and how. " : thrid para - typo 'as either or produceser' remove 'or' | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-7 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Marc Hadley | Lynne Rosenthal |
Title: Checkpoint 1.2 | |||||||
Description: comment about "1.2 Illustrate what is in scope" : Can use cases and examples be in a separate document from the main spec? | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-8 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Marc Hadley | Lynne Rosenthal |
Title: checkpoint 1.1 | |||||||
Description: comment about "1.1 Include the scope of the specification" : rather wooly conformance requirements | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-9 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Marc Hadley | Lynne Rosenthal |
Title: INTRODUCTION section 1.1, second bullet | |||||||
Description: comment about "Abstract, Status,..." : Second sentence implies that all checkpoints must be satisfied to comply with the guidelines wherease only priority 1 checkpoints are mandatory. | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-10 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Marc Hadley | Lynne Rosenthal |
Title: Section 7 | |||||||
Description: comment about "Overall" : date for LC WD is in the future (or it was when the doc was published). | |||||||
Proposal: Reviewer used the WG version of the document and not the LC version of the SpecGL. Moot point. | |||||||
Resolution: | |||||||
LC-11 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Marc Hadley | Lynne Rosenthal |
Title: CK 2.3 Category of object: clarification | |||||||
Description: comment about "2.3 Identify which of the categories of object..." : What is a category of object? The same as a class of product | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-12 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Marc Hadley | Lynne Rosenthal |
Title: section 3.4 Conformance definition | |||||||
Description: comment about "Overall" : Example - not true, see comment on 3.3 | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-13 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Marc Hadley | Lynne Rosenthal |
Title: Section 3.3 Conformance and TAs | |||||||
Description: comment about "Overall" : amusing that this section doesn't meet checkpoint 14.1 and therefore renders the document as only A-conforming to itself. Would be better if the document were AAA-conforming to itself IMO. | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-14 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Marc Hadley | Lynne Rosenthal |
Title: CP 14.1 - clarify conformance requirement | |||||||
Description: comment about "14.1 Provide test assertions" : conformance requirements - is a separate document OK or does this have to be in the same doc a the rest of the spec? | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-15 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Marc Hadley | Lynne Rosenthal |
Title: extensions | |||||||
Description: comment about "Guideline 9 Allow extensions or NOT!" : A very will thought out section IMO. | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-16 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Marc Hadley | Lynne Rosenthal |
Title: CP 8.4 clarify conformance requirement | |||||||
Description: comment about "8.4 Promote consistent handling of discretionary choices." : conformance requirements not clear, what does 'document the identified policies for handling discretionary choices' mean? | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-17 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Marc Hadley | Lynne Rosenthal |
Title: CP 7.1 deprecated features | |||||||
Description: comment about "7.1 Identify each deprecated feature. " :
conformance requirements imply a single section for deprecated features -
is it not OK to include deprecations where they occur without a summary section?
(See subsequent email discussion.) |
|||||||
Proposal: | |||||||
Resolution: | |||||||
LC-18 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Marc Hadley | Lynne Rosenthal |
Title: GL 5 non-hierarchiacal modules | |||||||
Description: comment about "Guideline 5 Address the use of modules to divide the technology." :
Modules are non-hierarchiacal - can modules have dependencies on other modules?
If so, isn't this a hierarchy?
(See subsequent email discussion.) |
|||||||
Proposal: | |||||||
Resolution: | |||||||
LC-19 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Marc Hadley | Lynne Rosenthal |
Title: CP 4.4 explanation clarification | |||||||
Description: comment about "4.4 If profiles are chosen, address rules for profiles." : 'experience shows ... meets all the pertinent checkpoints of this document' - what experience? As this is not yet a crecommendation this seems like a rather strong statement. | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-20 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Marc Hadley | Lynne Rosenthal |
Title: CP 3.1 Conformance Requirements - clarify | |||||||
Description: comment about "3.1 any universal requirements for minimum functionality." : conformance requirements - only one section for this or are multiple O.K? | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-21 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Marc Hadley | Lynne Rosenthal |
Title: CP 2.4 - relationships of DOV - clarify | |||||||
Description: comment about "2.4 If there are several classes of products, define their relationships..." : 'define their relationships and interaction with other dimensions of variability' this is a confusing checkpoint that is repeated in each successive guideline. It's really not clear exactly what is intended. | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-22 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Ian Jacobs | Lynne Rosenthal |
Title: CP 2.3 placement of Checkpoint | |||||||
Description: comment about "2.3 Identify which of the categories of object..." : This checkpoint includes a requirement for "where in your specification," even though the intro says those requirements are limited to GL1 and GL10-14. | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-23 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Ian Jacobs | Lynne Rosenthal |
Title: CP 1.4 vague | |||||||
Description: comment about "1.4 Provide examples. " :
I think this checkpoint is too vague. Is it possible to break it down into a few more concrete requirements that are more verifiable? For instance:
While you may miss some cases, I think spec editors will find this more helpful than the general goal to "provide examples." |
|||||||
Proposal: | |||||||
Resolution: | |||||||
LC-24 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Ian Jacobs | Lynne Rosenthal |
Title: Introduction, Sect 1.4 | |||||||
Description: comment about "Overall" : last para: Pubrules and the MoS aren't really specifications. What about "resources?" | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-25 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Ian Jacobs | Lynne Rosenthal |
Title: Introduction: scope and goals | |||||||
Description: comment about "Overall" :
Section 1.1 Last paragraph
I think the previous paragraph doesn't belong here; it could be deleted or moved to the status section (after some editorial fixes). |
|||||||
Proposal: | |||||||
Resolution: | |||||||
LC-26 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Ian Jacobs | Lynne Rosenthal |
Title: Multiple CPs - It is not applicable | |||||||
Description: comment about "Overall" :
CP 2.4, 4.1, 4.2, 4.3, 4.4, 5.1, 5.2, 6.1, 7.1, 7.2, 7.4, 7.5, 8.1, 8.3, 9.2, 9.4, 9.5, 9.6,
Suggest that the statment "It is not applicable if..." be labeled as "Normative inclusion/exclusion" as in UAAG 1.0 |
|||||||
Proposal: | |||||||
Resolution: | |||||||
LC-27 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Ian Jacobs | Lynne Rosenthal |
Title: Typos, grammar, etc. | |||||||
Description: comment about "Overall" :
GL 3, 2md para, Remove: "Overall, the intent of the WG should be clear" This doesn't add anything
CP 7.1, 7.4, 7.5 ConfReq, last sentence: change 'is' to 'are' in "...if there is no deprecated feature" CP8.4 Rationale: change 'identifying' to 'identify' CP9.1, last para: "This is strict conformance" is a repeat of text in intro of GL9 CP 11.4, last para: modify "proper use of the conformance icons" to "proper use of any conformance icons" GL13, last para: suggest switching the order of Manual of Style and PubRules |
|||||||
Proposal: | |||||||
Resolution: | |||||||
LC-28 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Ian Jacobs | Lynne Rosenthal |
Title: document organization suggestions | |||||||
Description: comment about "Overall" : Adopt the UAAG 1.0 approach of separating requirements from applicability exclusions (called "normative inclusions/exclusions" in UAAG 1.0). Use style sheets to hide links (e.g., to examples and techniques) for printed version. | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-29 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Ian Jacobs | Lynne Rosenthal |
Title: questions and suggestions | |||||||
Description: comment about "Overall" :
|
|||||||
Proposal: | |||||||
Resolution: | |||||||
LC-30 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Ian Jacobs | Lynne Rosenthal |
Title: Profile, module, level | |||||||
Description: comment about "Overall" : I am struggling to understand a sharp distinction between profile, module, and level. They are all mechanisms for defining and labeling a set of technical requirements. I have the feeling guidelines 4, 5, and 6 could be combined, and the requirements rephrased "Whatever subsetting mechanism you use..." | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-31 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Ian Jacobs | Lynne Rosenthal |
Title: general | |||||||
Description: comment about "Overall" :
General comments/conformance model I think the document is well-organized, clearly written, and very helpful. Having spent a lot of time thinking about conformance issues (notably for UAAG 1.0), I thought it covered a lot of ground and did so well. I like the distinction between requirements that relate to the conformance model and those that involve implementing the model in the spec. |
|||||||
Proposal: | |||||||
Resolution: | |||||||
LC-32 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Ian Jacobs | Lynne Rosenthal |
Title: 4. Definitions | |||||||
Description: comment about "Overall" : unconditional conformance -- This is used in HTTP. It means "all requirements met." | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-33 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Ian Jacobs | Lynne Rosenthal |
Title: 4. Definitions | |||||||
Description: comment about "Overall" :
"deprecated --
An existing feature that has become outdated by a newer construct or is no longer viable.
Deprecated features should not be used"
Hmm, "used" may not be a specific enough term. A spec may encourage a UA to support a feature, but discourage an author from producing it. and may be removed in some future version. |
|||||||
Proposal: | |||||||
Resolution: | |||||||
LC-34 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Ian Jacobs | Lynne Rosenthal |
Title: Section 3.4 Conformance definition | |||||||
Description: comment about "Overall" : " A checkpoint is satisfied by satisfying all of the individual @@conformance requirements@@. Failing one individual mandatory requirement means that the checkpoint is not satisfied." Is previous sentence required? | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-35 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Ian Jacobs | Lynne Rosenthal |
Title: Section 3.2 Extensibility | |||||||
Description: comment about "Overall" : "...to this specification MUST not contradict nor negate the requirements of this specification." Delete previous statement per comment in checkpoint 9.3. | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-36 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Ian Jacobs | Lynne Rosenthal |
Title: Section 3.1 Normative sections | |||||||
Description: comment about "Overall" : Is the glossary normative? | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-37 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Ian Jacobs | Lynne Rosenthal |
Title: CP 9.3 | |||||||
Description: comment about "9.3 Prevent extensions from contradicting the specification." : I think checkpoint 9.3 should be deleted. I think that it's straightforward that if the spec says "A" and someone else says "not A," then anyone that does "not A" doesn't conform. | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-38 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Ian Jacobs | Lynne Rosenthal |
Title: CP 9.1 and 9.2 combine | |||||||
Description: comment about "9.1 Indicate if the specification is extensible." : I think checkpoints 9.1 and 9.2 should be combined into one. | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-39 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Ian Jacobs | Lynne Rosenthal |
Title: CP 8.4 policies for discretionary choices | |||||||
Description: comment about "8.4 Promote consistent handling of discretionary choices." : Can "document the identified policies" be simplified? | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-40 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Ian Jacobs | Lynne Rosenthal |
Title: GL7 add obsolete features | |||||||
Description: comment about "Guideline 7 Identify the relation between deprecated features and conformance." : I think it's also important to identify obsolete features and provide althernatives to them. E.g., HTML 4.0 obsoleted a few elements. | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-41 | SpecGuide | 2003-03-11 | SpecGuide | Substantive | Active | Ian Jacobs | Lynne Rosenthal |
Title: CP 4.4 derived profile | |||||||
Description: comment about "4.4 If profiles are chosen, address rules for profiles." : What is the definition of a derived profile? | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-42 | SpecGuide | 2003-03-11 | SpecGuide | Editorial | Active | Ian Jacobs | Lynne Rosenthal |
Title: GL3: contradiction? regarding examples | |||||||
Description: comment about "Guideline 3 Specify conformance policy. " : last para, last sentence: Does "possibly provide examples" conflict with MUST provide examples of 1.4? | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-43 | OpsGuide | 2003-03-12 | OpsGuide | Substantive | Active | Peter Fawcett | Lofton Henderson |
Title: OpsGL Appendix 1 - Process Document Template | |||||||
Description: comment about "Overall" :
|
|||||||
Proposal: | |||||||
Resolution: | |||||||
LC-44 | SpecGuide | 2003-03-13 | SpecGuide | Editorial | Active | Stephanie Troeth | Lynne Rosenthal |
Title: Grammatical errors | |||||||
Description: comment about "1.1 Include the scope of the specification" :
"
This document is applied and conformance (to this document) achieved as new TRs are being written." (grammatically incorrect, intended meaning unclear) This document applies to new TRs and conformance (to this document) is achieved as they are being written. As for legacy specification, they may indirectly comply with the spirit or intent of some checkpoints, without actually satisfying all requirements in those checkpoints. (grammatical/spelling error) "legacy specifications" Within this Specification Guidelines document, the term "specifications' is specifically limited to W3C Technical Reports, even though these guidelines could be applied to other documents. (unbalanced quote marks) |
|||||||
Proposal: | |||||||
Resolution: | |||||||
LC-45 | SpecGuide | 2003-03-13 | SpecGuide | Editorial | Active | Stephanie Troeth | Lynne Rosenthal |
Title: Design goal of guidelines | |||||||
Description: comment about "1.2 Illustrate what is in scope" : 1.2 Class of Product and Audience -- "It is a design goal of these guidelines the WGs can apply them in a common-sense and workable manner." | |||||||
Proposal: These guidelines are designed so that the WGs can apply .... | |||||||
Resolution: | |||||||
LC-46 | SpecGuide | 2003-03-13 | SpecGuide | Editorial | Active | Stephanie Troeth | Lynne Rosenthal |
Title: Ambiguity | |||||||
Description: comment about "Guideline 2 Identify what needs to conform and how. " :
I'm finding it difficult to follow which terms are reserved for 'classes of products'. The word 'consumer' is used to describe the classes of products, and itself is listed within the classes of products. For example, I find the following sentence semantically confusing: "For a processor-type specification, the processor is the consumer of an XML vocabulary defined in the specification." "For content-type specifications, there may be one or more consumers that take the content and 'play' it in some way." "Play" refers to a media player, or play refers to "process" ? Divide this (enumerated) list into processor, consumer, or content? Make the terminology in this area unique, so that there will be no ambiguity? (It could be that the terminology is already unique, but in its current format, I can't be sure.) |
|||||||
Proposal: | |||||||
Resolution: | |||||||
LC-47 | SpecGuide | 2003-03-13 | SpecGuide | Editorial | Active | Stephanie Troeth | Lynne Rosenthal |
Title: Spelling error in Example and Techniques | |||||||
Description: comment about "2.2 For each class of product, define the conformance requirements. " : Spelling error in corresponding example and techniques: http://www.w3.org/QA/WG/2003/02/qaframe-spec-extech-20030203#Ck-define-scope "XHTML", not "XHML" :) | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-48 | SpecGuide | 2003-03-13 | SpecGuide | Editorial | Active | Stephanie Troeth | Lynne Rosenthal |
Title: Categories of object not previously clearly defined | |||||||
Description: comment about "2.3 Identify which of the categories of object..." : "Checkpoint 2.3. Identify which of the categories of object are specified in the document as a whole. [Priority 3]" Reader should be able to understand what 'categories of object' are upon reference - this is the first instance that this phrase is used in this document. Even though a URI is provided to the applicable definition of 'categories of object', the definition itself should introduce the list with this phrase. Eg: "Most specifications can be classified into one of the following categories of object ..." | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-49 | SpecGuide | 2003-03-13 | SpecGuide | Editorial | Active | Stephanie Troeth | Lynne Rosenthal |
Title: Complexity in explanation | |||||||
Description: comment about "Guideline 4 Address the use of profiles to divide the technology." : I can't understand what 'profile' means by this explanation; this should perhaps be simplified? | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-50 | SpecGuide | 2003-03-13 | SpecGuide | Editorial | Active | Stephanie Troeth | Lynne Rosenthal |
Title: Ambiguity or error? | |||||||
Description: comment about "4.1 Indicate whether or not
the use of profiles is mandatory..." :
"For example, is content required to conform to one
of the profiles, or is there a concept of conformance of content
independent of conformance to one of the profiles?"
Ambiguity or error? (I count four 'of's in the second clause! :D) |
|||||||
Proposal: | |||||||
Resolution: | |||||||
LC-51 | SpecGuide | 2003-03-13 | SpecGuide | Editorial | Active | Stephanie Troeth | Lynne Rosenthal |
Title: GLs 4, 5 and 6 | |||||||
Description: comment about "Overall" : Explanations for profiles, modules and functional levels are vague. Use diagrams for examples ? | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-52 | SpecGuide | 2003-03-13 | SpecGuide | Editorial | Active | Stephanie Troeth | Lynne Rosenthal |
Title: NOT ? | |||||||
Description: comment about "Guideline 9 Allow extensions or NOT!" : 'NOT!' seems rather uncharacteristic and out of line with regards to the remaining document. What about simply "Not" ? | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-53 | SpecGuide | 2003-03-13 | SpecGuide | Editorial | Active | Stephanie Troeth | Lynne Rosenthal |
Title: Ambiguity | |||||||
Description: comment about "Overall" : 1.3 Motivation and Expected Benefits (Introduction) -- "Providing requirements and definitions about conformance topics, as well as guidance in the structure and anatomy of specifications, will foster a mutual understanding among developers of specifications, implementations, and conformance test materials." (Comment: meaning is ambiguous) "foster a mutual understanding among developers about ..." | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-54 | SpecGuide | 2003-03-13 | SpecGuide | Editorial | Active | Stephanie Troeth | Lynne Rosenthal |
Title: GLs 3, 10, 11, 12 and 13 | |||||||
Description: comment about "Overall" : These are all guidelines which refer specifically to conformance. Would it make more sense to number these sequentially (in order to group them together), rather than having the big gap between 3 and 10 ? | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-55 | SpecGuide | 2003-03-13 | SpecGuide | Substantive | Active | Jon Gunderson | Lynne Rosenthal |
Title: Accessibility | |||||||
Description: comment about "Overall" : Specifications should have a section or the ability to highligh the features of the specification that benefit people with disabilities | |||||||
Proposal: Include a requirement that a specification have a section summarizing the accessibility features of the specification | |||||||
Resolution: | |||||||
LC-56 | SpecGuide | 2003-03-13 | SpecGuide | Substantive | Active | Jon Gunderson | Lynne Rosenthal |
Title: Accessibility | |||||||
Description: comment about "Overall" : QA test suites should also include tests that test the accessibility features of a specification based on the accessibility requirements found in other W3C documents. This may require having a specific person in charge of defining and monitoring the inclusion of accessibility features. | |||||||
Proposal: Include a requirement in the Operation Guidelines for a person to be responsible for accessibility tests of a specification | |||||||
Resolution: | |||||||
LC-57 | OpsGuide | 2003-03-12 | OpsGuide | Substantive | Active | Dominique Hazael-Massieux | Lofton Henderson |
Title: GL and timeline of a document | |||||||
Description: comment about "Overall" : most guidelines are only applicable at some point in the WG's life, but the GL don't identify this aspect: this is something that absolutely needs to be stressed, and could even be used as a strategy to organize the GL as a whole, e.g. what you need to do before starting a WG, what needs to be done when you start developing a new spec, what needs to be done when you envision building a test suite, etc. | |||||||
Proposal: at least, provide a section (an image?) linking the GL or the CP to the milestones of a WG life | |||||||
Resolution: | |||||||
LC-58 | OpsGuide | 2003-03-12 | OpsGuide | Substantive | Active | Dominique Hazael-Massieux | Lofton Henderson |
Title: Process Document requirement is too specific | |||||||
Description: comment about "Overall" : a WG should still be able to comply to a CP without having a QA Process Document. | |||||||
Proposal: replace QA process document references by a documented WG decision? | |||||||
Resolution: | |||||||
LC-59 | OpsGuide | 2003-03-12 | OpsGuide | Editorial | Active | Dominique Hazael-Massieux | Lofton Henderson |
Title: Testability concerns | |||||||
Description: comment about "Overall" :
The following expressions seemed either hard to apply or to test:
|
|||||||
Proposal: | |||||||
Resolution: | |||||||
LC-60 | OpsGuide | 2003-03-14 | OpsGuide | Substantive | Active | Patrick Curran | Lofton Henderson |
Title: Structure/Organization of Guidelines | |||||||
Description: comment about "Overall" :
Comments on the structure and organization of the guidelines
and checkpoints of SpecGL.
Overall, I think we have the right checkpoints, but I think they would be easier to understand if they were grouped chronologically. Start with what needs to be done when the WG is formed, and proceed through the spec and test development cycle to the maintenance phase, as we have tried to do with the restructuring of TestGL. Guideline 1: I find checkpoints 1.1 - 1.3 very confusing. These are "compound checkpoints" that incorporate multiple other checkpoints. We don't use this structure anywhere else in our docs - why here? The document states "This seven-point enumeration is derived from the proposal to the QA mail list, after the 4/2001 QA Workshop", but how we got here is not really interesting to the reader. The 'sub-checkpoints' on the 'left hand side' of the table are all spec-related. Either these duplicate checkpoints from SpecGL, or they should be incorporated into that document. Those on the 'right hand side' are operations-related, but they seem to overlap with other checkpoints specified in this document. Recommendation: drop the compound structure, make sure that all the spec-related sub-checkpoints are covered by SpecGL, and move the 'test materials' sub-checkpoints into the body of this doc. The remaining checkpoints under guideline 1 are different kinds of beasts (not compound) and as such, the transition to them seems somewhat abrupt. Guideline 2: I'd say "Allocate resources..." rather than "Define resources..." Guideline 3 begins with some text ("The benefits of....") that seems to be a rationale. Other Guidelines jump straight into the Conformance requirements - this one should too. How is checkpoint 3.1 different from 1.5? Checkpoint 3.2 doesn't seem to be directly related to the Guideline under which it's classified. The Note for 3.2 points out that checkpoint 8.2 is related - doesn't this suggest that the overall structure should be re-worked (if they're related, why are they so far apart numerically?) Guideline 4 Probably should be #1 (it's the first chronologically). When we summarized this document in our outreach presentation we made checkpoint 4.1 the first bullet item... Checkpoints 4.1 and 4.2 would seem to belong in Guideline 2 (define/allocate resources) rather than here? The Discussion for checkpoint 4.3 says "To summarize...". This implies that somewhere there's a more detailed description of what the QAPD must address, but I don't think there is. This checkpoint really seems to amount to "document how you meet these other checkpoints", yet the list of "other checkpoints" that must be implemented is incomplete. Why doesn't this simply require that *all* checkpoints be documented? Checkpoint 4.5 uses the ambiguous term "framework" (we tried to avoid this in our re-write of OpsGL). Checkpoint 4.6 addresses branding - another argument for a chronological rather than a 'logical' grouping (this should be at the end). Guideline 5 Checkpoint 5.2 - Define a contribution process. Why only priority 2? Without a contribution process you have nothing, surely? Guideline 6 Checkpoint 6.1 contains a mixture of stuff. The guideline addresses "publication" but much of this checkpoint addresses "management". Moreover, the bullet items in the Discussion section don't seem to relate to repositories at all. Checkpoint 6.2 (defining the license for published test materials) is closely related to 5.3 (defining the license for submissions). Should these be grouped together (under a guideline that addresses submission processes)? Guideline 7 This guideline is labelled "plan the transfer of test materials to W3C if needed", and explicitly states "all of the checkpoints... are not applicable if the WG does not transfer..." (should be "none of the checkpoints are applicable if..."). However, all the checkpoints seem to apply whether or not the materials are "transferred". It's obviously important to review the quality of submitted tests, to ensure that we have the staffing to deal with submissions, and to resolve IPR issues. |
|||||||
Proposal: I think we have approximately the right checkpoints, but I
think they would be easier to understand if they were grouped chronologically.
A possible set of guidelines might be:
|
|||||||
Resolution: | |||||||
LC-61 | SpecGuide | 2003-03-14 | SpecGuide | Substantive | Active | Susan Lesch | Lynne Rosenthal |
Title: document product class | |||||||
Description: comment about "Guideline 2 Identify what needs to conform and how. " : Guideline 2 could give "document" and "resource" either as product classes or as examples of the "content" class. (Checkpoint 2.1 does finally mention "document.") | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-62 | SpecGuide | 2003-03-14 | SpecGuide | Editorial | Active | Susan Lesch | Lynne Rosenthal |
Title: typos | |||||||
Description: comment about "Overall" :
In section 3.3, s/This Operational Guidelines document/This
Specification Guidelines document/
In the guideline title and table of contents entry for Guideline 12 and in 3.4 last par., "pro forma" is two words. The table of contents link to section 3.1 is broken. (These probably have been reported by now but just in case.) |
|||||||
Proposal: | |||||||
Resolution: | |||||||
LC-63 | SpecGuide | 2003-03-14 | SpecGuide | Editorial | Active | Susan Lesch | Lynne Rosenthal |
Title: Table of Contents | |||||||
Description: comment about "Overall" : Would the table of contents in QA Framework specs that have guidelines be easier to follow if non-Guideline sections all appeared by number in the table of contents? E.g. "3. Conformance" could be followed by "3.1 Normative sections" rather than by "1. Normative sections"? The difference between for example "checkpoint 1.1" and "section 1.1" (both about scope) then would be distinct and easier to talk about. | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-64 | SpecGuide | 2003-03-14 | SpecGuide | Editorial | Active | Susan Lesch | Lynne Rosenthal |
Title: conformance terms | |||||||
Description: comment about "3.2 If special conformance terms are used, include a definition..." : Checkpoint 3.2 says: "the specification MUST be defined, either by reference or by including the definition in the text." Did you mean to say that the whole spec is considered to be "defined" through references and definitions? In that case, please ignore this comment. | |||||||
Proposal: Could read something like: "terms used to describe conformance MUST be defined, either by reference or by including the definition in the text." (I'm afraid "conformance terms..." might mean you'd have to define "terms.") | |||||||
Resolution: | |||||||
LC-65 | SpecGuide | 2003-03-14 | SpecGuide | Editorial | Active | Susan Lesch | Lynne Rosenthal |
Title: sentences and paragraphs (section 3.1) | |||||||
Description: comment about "Overall" : In section 3.1, "sentences" becomes "typically, one paragraph...." Is a sentence containing an RFC 2119 key word a unit of being normative, or do you mean that a paragraph containing such a sentence is or can be the unit? I'm not sure if it is important to draw a line. Section 4's definition of normative says "text in a specification which is prescriptive or contains conformance requirements" which seems to mean any text with no boundaries (for example, like section, chapter, slice). | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-66 | SpecGuide | 2003-03-14 | SpecGuide | Substantive | Active | Susan Lesch | Lynne Rosenthal |
Title: edition and version DoVs | |||||||
Description: comment about "Overall" : Guidelines 4-6 and the section 4 definitions are great descriptions of profiles, modules, and levels, thanks. Are "editions" and "versions" DoVs? If for example, a requirement changed between Version 1.0 and Version 1.1 of some specification, so that a 1.0 processor could not read 1.1, that might be a "variability." | |||||||
Proposal: If you think edition and version do matter, they could be addressed in section 1.8, or in a separate Guideline. | |||||||
Resolution: | |||||||
LC-67 | SpecGuide | 2003-03-14 | SpecGuide | Substantive | Active | Susan Lesch | Lynne Rosenthal |
Title: limits of RFC 2119 key words | |||||||
Description: comment about "13.1 Use conformance key words." :
"the specification MUST use RFC 2119 keywords to denote whether
or not requirements are mandatory, optional, or suggested" is Priority 1.
Must all testable statements and or test assertions (sorry I'm not clear on
the difference between them and maybe that needs to be clarified, too)
contain RFC 2119 key words?
RFC 2119 [1] section "6. Guidance in the use of these Imperatives" puts limits their use. (I mentioned this to the QAWG about a year ago.) They musn't be used only to ask implementers to do something a Working Group would like to see. |
|||||||
Proposal: One way to solve this is to quote or paraphrase and link to the RFC.
"Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability." [1] http://www.rfc-editor.org/rfc/rfc2119.txt |
|||||||
Resolution: | |||||||
LC-68 | IntroGuide | 2003-03-14 | IntroGuide | Editorial | Active | Susan Lesch | Lofton Henderson |
Title: Intro draft | |||||||
Description: comment about "General: miscellaneous & other" :
I found Ian Jacob's SpecGL edits [1] in your archive and would like
to send ideas for the QA Framework Introduction. I expect they will
be ready at [2] by 14 March 24:00 Pacific.
|
|||||||
Proposal: Use or not, as you see fit. As this is my last Last Call comment, I just want to say that it must have been a monumental task to put the framework together. You've made it look elegant, and easy to use. Best wishes for your project. | |||||||
Resolution: | |||||||
LC-69 | IntroGuide | 2003-03-15 | IntroGuide | Editorial | Active | Colleen Evans | Lofton Henderson |
Title: Several comments on various parts of Introduction | |||||||
Description: comment about "General: miscellaneous & other" : [Entered into form by LH. Some are significant editorial, but all are classified as "Editorial" because there are no conformance implications or suggestions for major document reorganization.] Review comments: In general it provides useful guidance on how to use the Framework, defining audience and WG activity applicability for each document. Is this a Working Draft or Last Call Working Draft? Title indicates the former. Interspersed usage of the terms 'document', 'guideline', and 'specification' to describe the QA Framework documents could be confusing. E.g., paragraph 4 of Status: "... It is anticipated that this specification will eventually progress, along with its Operational Guidelines and Specification Guidelines companions, to Candidate Recommendation (CR) and beyond. The timing of progression of this specification will be determined by the progression of the companion guidelines documents." Similarly, 'TR', 'standard', 'specification', and 'recommendation' are used interchangeably to describe the output of WGs. Section 1.3, first sentence: "The last underscores a key reality of improved quality practices associated with W3C technical reports". Not clear what 'the last' is (previous section?). Section 1.4, paragraph 3, first sentence incomplete? "While some might perceive QA projects as a regrettable drain on WG resources, there is ample experience, both within W3C as well as other standards venues, that shows significant improvement to the products of the WGs." Sections 1.3 (paragraph 1) and 1.4 (paragraphs 2 and 3) contain general justification arguments for QA efforts in WGs - may be more appropriate content for Section 1.2. Section 3.1 Application Domain - does this belong in Section 3 (Structure and content of Framework documents)? Seems more like Section 1 (Overview) content where target audience is covered. Sections 3.5.2 - 3.5.5 describe each document - information on content, audience, and objective. It may help readability to use a consistent order for presenting this information across sections. Section 3.5.4 Single item bullet list? Section 4.1.3 Useful breakout of document relevance by role within a WG. Section 4.2 Provides a good life cycle view of the relationship between Framework documents and WG activities. A table summary might be useful as well. Section 4.1.3 "WG-TS moderator" - Section 4.2.2 "test materials (QA) moderator". Same role? Section 4.2.3, paragraph 4, second sentence is unclear: "Normally, this should not be considered as a good time to bring a specification for 'Specification Guidelines' conformance, as the latter could significantly disrupt and restructure the specification.". Is 'the latter' referring to bringing a spec to specification guidelines conformance, or something in a previous sentence? Section 4.2.5. Intra-WG build of test materials calls for an acceptance procedure for the individual bits. Import and assemble only call for quality assessment and assessment criteria - is an acceptance procedure required / implied? Editorial Usage of Working Group vs. WG inconsistent throughout Inconsistent bullet list punctuation (';' vs. ',' vs. nothing at line end, etc.) Section 1.2, paragraph 1 "...." at end of first sentence Section 4.2.5, paragraph 2 "? -- as " in middle of second sentence | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-70 | OpsGuide | 2003-03-15 | OpsGuide | Substantive | Active | Phill Jenkins | Lofton Henderson |
Title: Checklist format issue | |||||||
Description: comment about "Overall" : [Entered into form by LH. Comment applies to Checklists of SpecGL and TestGL as well OpsGL.] I have noticed a number of "checklists" being proliferated on the W3C pages. I have a strong recommendation for improving the adaptability of the checklist format - namely the number of column in the layout. For example, today most have a column for the number of the checkpoint, the description of the checkpoint, and then a number of columns for YES, NO, N/A. Please consider adapting the following format: Top matter: Version, date, owner, etc Column 1 10% Checkpoint number Column 2 40% Description Column 3 10% YES, NO, N/A, Planned Column 4 40% Comments Bottom matter: Footnotes, exceptions, references, etc. an example we find useful is at http://www-3.ibm.com/able/accesssoftware.html [[Following is (unarchived) comment from Ian Jacobs: We redesigned the UAAG 1.0 checklist [1] based on earlier comments from you [1]. We don't specify fixed widths for table columns. - Ian [1] http://www.w3.org/TR/2002/REC-UAAG10-20021217/uaag10-chktable.html [2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0137.html ]] | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-71 | IntroGuide | 2003-03-15 | IntroGuide | Substantive | Active | Leonid Arbouzov | Lofton Henderson |
Title: Collected substantive & editorial comments | |||||||
Description: comment about "General: miscellaneous & other" : [Entered into form by LH.] Six substantive and editorial issues on "QA Framework: Introduction" are included in the document at http://www.w3.org/QA/WG/2003/03/qareview20030314.html , which was submitted to QA on 14 Mar 2003: http://lists.w3.org/Archives/Public/www-qa/2003Mar/0079.html | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-72 | OpsGuide | 2003-03-15 | OpsGuide | Substantive | Active | Leonid Arbouzov | Lofton Henderson |
Title: Collected substantive & editorial comments | |||||||
Description: comment about "Overall" : [Entered into form by LH.] Thirteen (13) substantive and editorial issues on "QA Framework: Operational Guidelines" are included in the document at: http://www.w3.org/QA/WG/2003/03/qareview20030314.html , which was submitted to QA on 14 Mar 2003: http://lists.w3.org/Archives/Public/www-qa/2003Mar/0079.html | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-73 | SpecGuide | 2003-03-15 | SpecGuide | Substantive | Active | Leonid Arbouzov | Lynne Rosenthal |
Title: Collected substantive & editorial comments | |||||||
Description: comment about "Overall" : [Entered into form by LH.] Nine substantive and editorial issues on "QA Framework: Specification Guidelines" are included in the document at: http://www.w3.org/QA/WG/2003/03/qareview20030314.html , which was submitted to QA on 14 Mar 2003: http://lists.w3.org/Archives/Public/www-qa/2003Mar/0079.html | |||||||
Proposal: | |||||||
Resolution: | |||||||
LC-74 | SpecGuide | 2003-03-15 | SpecGuide | Substantive | Active | Lofton Henderson | Lynne Rosenthal |
Title: Simplify & consolidate the guidelines of SpecGL | |||||||
Description: comment about "Overall" :
If the 14 specification guidelines can be clearly summarized in 6 bullets, as we claim is done in the QA Outreach Kit, http://www.w3.org/2003/Talks/qa-outreach/slide5-0.html , then perhaps the guidelines themselves ought to be consolidated and reduced in number. I believe that most of the checkpoints are appropriate, but perhaps should be repackaged. Six bullets:
I think the first 4 are almost right for guidelines. The later ones don't seem to me to be quite right.
So at best, we would have 7 guidelines. At worst, 9 (if the new GL5 wouldn't stick together, and we couldn't find a new GL6 that was satisfactory). |
|||||||
Proposal: | |||||||
Resolution: |