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

Karl
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.



>>>Techniques:
>>>         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.

--lynne

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