- From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
- Date: Wed, 11 Apr 2007 16:58:56 +0200
- To: public-wai-ert-tsdtf@w3.org
Hi, At 20:59 10/04/2007, Shadi Abou-Zahra wrote: >Please find the minutes for the TSD TF teleconference on 10 April, 2007: > <http://www.w3.org/2007/04/10-tsdtf-minutes> > >Next meeting is next *Tuesday 17 April, 2007* (to compensate several >skipped teleconferences we will meet next week again). ... and Carlos Velasco and I will not be available on 24 April because of project reviews (BenToWeb, WAB Cluster). Below are some additional notes on yesterday's discussion. Carlos Iglesias said we needed a mechanism to vote on or approve "issues" for the WCAG WG. My understanding is that this would be covered by Shadi's proposal [1] for the addition of an "issue" status as an additional outcome of step 5 (Task force decision). There were no objections to this proposal, and the discussion led to the question when an issue is actually written up (i.e. using the Issues Template [2])? I can think of two approaches: 1. write the issue after step 5, based on the comments in the Content Review page where the issue was raised and on the discussion of the straw poll results in step 4; 2. write the issue during the Content Review, add it to the straw poll in step 4 and discuss changes etc during the telecon. So far, we have assumed that issues only result from reviews of test samples. It was pointed out that issues may also be found before test samples are created. In other words, if we can't create a test samples because we think there is an issue with a technique or failure, where do we document this? This would require a separate list (i.e. separate from the last column of the Test Sample Status List). Vangelis also pointed out that there may be more than one issue per test sample. In the Wiki, I think that this can be addressed by having more than one link in the last column of the Test Sample Status List [3]. This also reminds me that we should give each issue a unique identifier. If or when we move to a test case management system such as Mozilla Testopia, we will have to look into this again. We need to know not only what issues are related with a certain test sample, but also which test samples are related with an issue, so that we know which test samples can be reopened by the task force when an issue has been closed by the WCAG WG. Regarding the attributes "complexity" (on the testCase element) and "primary" (on the rule element): the proposal was about default values in TCDL 2.0, not fixed values. However, the script that will automate the structure review will check that the values are "atomic" and "yes", respectively, if the attributes are present. Best regards, Christophe [1] http://lists.w3.org/Archives/Public/public-wai-ert-tsdtf/2007Mar/0019.html [2] http://www.w3.org/2006/tsdtf/IssuesTemplatePage [3] http://www.w3.org/2006/tsdtf/TestSampleStatusList -- Christophe Strobbe K.U.Leuven - Departement of Electrical Engineering - Research Group on Document Architectures Kasteelpark Arenberg 10 - 3001 Leuven-Heverlee - BELGIUM tel: +32 16 32 85 51 http://www.docarch.be/ Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Received on Wednesday, 11 April 2007 14:59:11 UTC