This charter is written in accordance with of the W3C Process.
The mission of the QA Working Group is to solidify and extend current W3C quality practices regarding operational functions, specification editing, production of validation tools and test suites, and coordination efforts within W3C. The emphasis of this second phase of the QA activity (2003-2005) is on implementability of the QA OpsGL and SpecGL (CR phase for both of them) production of quality test materials by the W3C WGs (TestGL).
The main objective of the QA Working Group is to foster the development of usable and useful test suites endorsed by the W3C, and ensure that the validating tools of the W3C are fully operational, useful and educational.
As a step in performing this task, the QA Working Group will need to work on conformance testing methodology, on the quality of the W3C specifications with respect to conformance and clarity, and the tracking of issues related to specification ambiguity and evolution.
The scope of the QAWG includes:
In its operations, specifications, and test materials the QAWG will achieve at least the quality levels:
The QAWG is the decision making body for the QA activity.
This Working Group is scheduled to last 24 months, from August 2003 through August 2005.
The main criterion of success for the QAWG is that W3C Recommendations released during the operation of the WG are of better quality of those released before, and that validators and test suites are available for each technology (we note that this criterion for success is dependent on the success of communications with other W3C working groups).
Timely delivery of the materials mentioned above (including our own quality commitments) is a criteria for judging the quality of the work of the group.
For the first year only:
The Working Group and the Activity resources in general are publicly accessible.
All documentations, test suites, validating tools produced inside this Activity will have to be defined under a license. There are still questions about the kind of license to use (for instance we have two licenses at W3C: one for document and one for software, the document license being more restrictive for the change control, which may be of interest to ensure the integrity of QA tools). This will be discussed in the QA Activity.
In any case, we expect the tools to be freely usable, runnable, and downloadable and the group to operate under a Royalty Free licensing mode (RF).
Prior disclosure of intellectual property rights pertaining to QA applied to W3C technology will be required, following the IPR requirements defined in the W3C Process.The QAWG will adhere to the new patent policy adopted by W3C.
The QAWG is heavily dependent on the participation of other W3C groups for its success.
This is particularly important for the production of good quality specification and the resolution of issues between external test developers and specification editors pertaining to ambiguity in specifications.
See the note in the Participation section below for details.
QA will also need to coordinate with other W3C activities doing reviews, like WAI, I18N, Device Independence and the TAG.
Finally, since the quality of the specs is today in the hands of the Comm team (pubrules - Member-only document), a good coordination with this W3C team is very important.
We expect coordination with external groups to happen in both the QAWG and the QAIG. QAIG is where issues about outside activities are raised and discussed and QAWG is where partnership will actually happen.
The archived mailing list www-qa-wg@w3.org is the primary means of discussion within the group.
The group maintains a public page.
At the time of this renewall, the QAWG meets every week by phone on Monday at 10am Boston time, for one hour to one hour and a half.
Face to face meetings will be arranged 3 to 4 times a year, rotating location between US west coast, east coast, Europe, and occasionally Asia/Pacific/Australia. Meeting details are made available on the W3C Member Calendar and on the QAWG home page.
The QAWG home page is the primary way of communicating the group's progress to the public.
The Group works by consensus. In the event of failure to achieve consensus, the Group may resort to a vote as described in the Process Document. All group participants in good standing are allowed to vote.
Escalation: Appeals from Working Group decisions are made first to the W3C team following the procedures established by the W3C Process Document (first the domain leader and then the director).
W3C also funds Lofton Henderson part-time to lead the QAWG as chair.
Note: In addition to this core team, it's important to point that most of the W3C technical staff acting as staff contact for a technology will end up working "part time" for QA, when their technology is up on the QA agenda. E.g. X is not in the QA team, but when the QA team starts looking closely at a test suite for the specification he or she is dealing with, we expect X to free up some time/resource to coordinate with us, interface with people in the group, help us promote whatever W3C test guidelines we have come up with during WG meetings, if needed, etc.
All W3C group participants should realize that QA is to be considered a natural overhead of any WG, even if it's not written down in our process yet. QA will succeed only if every person inside W3C participates in it.
For participation in the QA Working Group, the requirements for meeting attendance and timely response are described in the W3C Process document. This participation (attending meetings, reviewing documents, preparing drafts or tools) is expected to consume between one half to one day per week.
We expect and will be welcoming different communities to contribute to the Activity:
As this Activity has a clear multi-stakeholder approach, we expect to use multiple approaches to reach our goals, and not a fixed set of rules that would not be applicable to all participants.
Information about how to join the Working Group is available on a separate howtojoin page.
