- From: Shadi Abou-Zahra <shadi@w3.org>
- Date: Fri, 13 Apr 2007 09:47:12 +0200
- To: public-wai-ert-tsdtf@w3.org
Hi, Christophe Strobbe wrote: > 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. The proposal is that during a Content Review step, a reviewer will note the issue. It is ideally identified at this stage already. In the next step the opinion of the other TF participants on this review is gathered using the online strawpoll. In most cases, this is where the voting will take place. However, in other cases the other TF participants may have comments or even objections to the review. These different opinions are discussed on a teleconference in step 5, and one of the following will come out: #1. content review (in this case an issue) is accepted as-is #2. minor modifications needs to be made to the review (issue) #3. the review is rejected and the process must be repeated > 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). Good point. However, right now we are not actively developing test samples (only reviewing existing ones). I suggest we postpone this discussion until we start actively developing test samples. > 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]. Agreed. > This also reminds me that we should give each issue a unique identifier. It has a URI -is this sufficient for now? > 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. It seems to me that we may need to tap into the WCAG Bugzilla... > 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. Any volunteers to work on this script? > [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 Regards, Shadi -- Shadi Abou-Zahra Web Accessibility Specialist for Europe | Chair & Staff Contact for the Evaluation and Repair Tools WG | World Wide Web Consortium (W3C) http://www.w3.org/ | Web Accessibility Initiative (WAI), http://www.w3.org/WAI/ | WAI-TIES Project, http://www.w3.org/WAI/TIES/ | Evaluation and Repair Tools WG, http://www.w3.org/WAI/ER/ | 2004, Route des Lucioles - 06560, Sophia-Antipolis - France | Voice: +33(0)4 92 38 50 64 Fax: +33(0)4 92 38 78 22 |
Received on Friday, 13 April 2007 09:40:03 UTC