Re: A-2002-03-08-4 Process Document and Guidelines - Ongoing

Karl,

Thanks for this, it gives us a thorough exploration of the options.  For 
now, I have updated issue #71 ([1], mandatoriness) and issue #16 ([2], 
modify process document?) with a reference to this.

Eventually, will we (QAWG) have to reopen these issues, or a new one, and 
decide "how"?  (For issue #16 we have it "Closed" with a resolution of "For 
now, QAWG will not recommend [PD] changes.")

This might be useful also for the 7/18 team telcon for QAWG project 
review.  I'll include a reference.

-Lofton.

[1] http://www.w3.org/QA/WG/qawg-issues-html#x71
[2] http://www.w3.org/QA/WG/qawg-issues-html#x16

At 02:41 PM 6/27/02 -0400, you wrote:

>It's a first approach to identify the places for QA in the Process Document.
>I will try to find clear solution with regards to the QA Framework in a 
>next mail.
>If you have comments on this one you are welcome.
>
>There are different places along the life of an activity where official 
>documents are produced and actions are made.
>
>Activity
>         -> Activity Proposal (draft)
>                 nature of the activity (e.g., to track
>                 developments, create technical reports,
>                 develop code, organize pilot experiments,
>                 education, etc.)
>                 create test suites?
>         -> AC comments
>                 Some Members can ask for QA identification
>                 in the proposal like NIST for example
>         -> Activity Statement
>                 The Proposal has been modified with regards
>                 to the comments.
>         -> Activity Creation
>         -> Group Requirement
>                 See further.
>         -> Charter (draft)
>                 Written by someone from the Team, and reviewed
>                 by people of the Team.
>                 See further.
>         -> Review by the W3M
>                 the W3C Management decides if the charter is
>                 accepted.
>         -> Charter
>         -> Recommendation Track
>                 the different stage of the recommendation track
>                 must follow what has been defined in the charter
>                 for each individual stage.
>                 Entrance Criteria required.
>                 - Last Call: Must fulfill the charter
>                 - CR: not required 2 independant and interoperable
>                     implementations but encouragement for a report
>                     on present and expected implementation.
>                 - CR Implementation Period: there's a minimal duration
>                 - PR: each feature have been implemented. the WG SHOULD
>                     be able to demonstrate 2 interoperable implementations
>                     of each feature.
>
>
>My first approach is that if we want a charter more complete, we'll have 
>to have a mention in the process Document which says that the charter must 
>indicate the level of commitment of each Deliverables with regards to the 
>QA Framework. At the same time, the Process Document could impose others 
>requirements
>
>         - DI requirements
>                 See http://www.w3.org/TR/di-princ/
>         - I18N requirements
>                 See http://www.w3.org/TR/charmod
>         - QA requirements
>                 See http://www.w3.org/QA/WG/qaframe-intro
>         - WAI requirements
>                 See http://www.w3.org/TR/xmlgl
>                 http://www.w3.org/WAI/PF/
>                 No document about non XML technologies like CSS
>
>
>So you will have in the charter the list of documents, a schedule, level 
>of commitments.
>
>If it's not in the process document, the requirement could be the Charter 
>MUST be reviewed by DI, I18N, QA, WAI before to be accepted.
>
>
>* Requirement for Groups
>------------------------
>http://www.w3.org/Consortium/Process-20010719/groups.html#ReqsAllGroups
>  - must have a charter
>  - must have a Chair
>  - must have a Team Contact
>  - must have a mailing list
>  - may form task forces to carry out assignments.
>
>My reading of that is that the task forces could be detailed a bit with 
>Editors, QA Contact, Test Suite coordinator. The problem is that often 
>it's very difficult to fin these persons before the start of the working group.
>
>* Charter
>----------
>The process document on the charter impose a MUST for topics but do not 
>imply any formal organisation in the topics. It's in fact when you are 
>looking at it very loosy.
>I understand the fact that it's loosy to give space and possibility to 
>accomodate a large number of group types, but it must be more like a 
>modular thing with options.
>
>
> From http://www.w3.org/Consortium/Process-20010719/groups.html#WGCharter
>
>         A Working Group or Interest Group charter ***MUST*** include the 
> following information.
>
>- Group mission
>         - develop a technology process (good place for QA and TS)
>         - write the charter of another group (means QA can write the QA 
> section of other groups)
>- Criteria for Success
>         * a Test Suite for each Rec, could be imposed.
>
>- Any dependencies
>         * Here there's a place to say that they should have a QA contact
>
>
>
>
>--
>Karl Dubost / W3C - Conformance Manager
>           http://www.w3.org/QA/
>
>      --- Be Strict To Be Cool! ---
>

Received on Tuesday, 2 July 2002 13:07:51 UTC