W3C home > Mailing lists > Public > www-qa-wg@w3.org > July 2004

Re: [SpecGL Draft] E. Good Practice: Write sample code or

From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
Date: Thu, 15 Jul 2004 14:37:35 -0400
Message-Id: <>
To: Karl Dubost <karl@w3.org>, www-qa-wg@w3.org

Seems we make a good team.  (apologies to Mark for using this phrase - 
inside joke/comment)

>mmm My bad. I wonder what I was thinking when I have written this.
>My point:
>         When a WG is working group is developing a technology, all 
> members of the WG are very tempted to add as many features as possible 
> (because it will be cool, because it's needed here or there, because it's 
> just an idea which popped up).
>         But adding these features doesn't mean:
>                 - that it would be easy to implement them: Benefit/Cost 
> for each individual features.
>                 - that it would be implementable: When you come to the 
> implementation phase, you see that in fact, it doesn't make sense at all 
> or it's impossible to implement.
>                 - that it doesn't fit in the bigger scheme of things: For 
> example, two features in the spec that would have opposite or 
> contradictory behaviour without mutual exclusion mechanism (The two 
> features must not be present at the same time).

Much clearer.  I'm wondering if this also belongs under the Scope 
section.  There is a relationship between the 2 sections, in that writing 
sample code/tests can help focus the scope and help prevent feature-creep.

>>>         1. Try to associate developers to the Working Group progress 
>>> (Open source or commercial)
>>Awkward.  I don't know how to rewrite this.
>         1. Encourage developers (Open Source or Commercial) to work with 
> the Working Group to get pre-implementation at the same time the 
> technology is developed.

This makes sense.

Received on Thursday, 15 July 2004 14:40:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:33 UTC