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

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 Thursday, 27 June 2002 15:06:05 UTC