- From: Martin Duerst <duerst@it.aoyama.ac.jp>
- Date: Tue, 26 Sep 2006 10:31:48 +0900
- To: Felix Sasaki <fsasaki@w3.org>, "Lieske, Christian" <christian.lieske@sap.com>
- Cc: public-i18n-its@w3.org
At 18:29 06/09/25, Felix Sasaki wrote: > >Hi Christian, > >Lieske, Christian wrote: >> Hi Felix, >> >> So "feature at risk" is everything for which we do not get two implementations? > >Yes. > > Are there other criteria? > >No. I think things are a bit different (unless they have changed recently). In CR, you have to show that your spec actually got implemented. This usually means two independent implementations for each feature; it may also mean two implementations of all required stuff, or so; details may be negociated with the Director when entering CR. What happens when you end the CR period, and some things are not implemented? You can wait (a bit or a lot) longer, or you can go back and change the spec, and do another last call and CR. Both may not be desirable. Enter "features at risk": If you defined something as "feature at risk" when entering CR, and it didn't get implemented sufficiently, you can drop it from the spec and move on to PR, without going back. Going back to the current pre-CR period, how do you decide what to make a "feature at risk"? If you already know you won't get two implementations, you don't even have to make it a "feature at risk", you can as easily exclude it. If you see a chance that you won't get two implementations, then making it a "feature at risk" is a reasonable safety measure. But even if it's a "feature at risk", the WG should try to work hard to get the implementations. Also, for something to become a "feature at risk", it better be a) easy to remove from the spec (you don't want to get into discussion of what exactly it means to remove it from the spec if you have to remove it when going from CR to PR), and b) really something you think that the world can live without. If it is e.g. something related to universal access (accessibility, internationalization,...), making such a feature a "feature at risk" means in effect that you think you are okay even if your spec does not address accessibility concerns. Such a thing would be very bad. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
Received on Tuesday, 26 September 2006 06:35:34 UTC