Re: [TSD TF] Minutes for Teleconference on 10 April, 2007

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