- From: Nathan <nathan@webr3.org>
- Date: Thu, 17 Feb 2011 03:09:25 +0000
- To: Jeff Jaffe <jeff@w3.org>
- CC: Ian Hickson <ian@hixie.ch>, www-archive <www-archive@w3.org>, Ian Jacobs <ij@w3.org>
Hi Jeff, Jeff Jaffe wrote: > I'd like to understand your view of the 80% a bit better. I would like > W3C to address this group, and in my view they are indeed well addressed > by having a more agile process with releases that are far more frequent > than today. But I don't think that the 80% will suffice with something > that is only semi stable - and I don't think that 80% needs something > every 3 months. So I would like to understand your thinking on this > point a bit more. To hopefully explain, the way I see it is that those who need catered for, are those who will use the features and read the specs, so given four release channels for HTML specifications: living the always being worked on draft dev the heavy lifting and testing has been done, time for early adopters and implementers to use and mature it (say, it's been implemented in one or two browsers and tests are written). beta adopting, other than bugs, a mature feature which is being adopted (say, it's in 60% of browsers, tutorials and demos written, general developers are aware of the feature and want to use) stable adopted, widely implemented and supported features (standardized you could say) I'd suggest that the majority (perhaps not quite 80%) are html authors, tooling vendors, general web developers/designers and the like, and that most of them are interested in, and need to have available, the dev and beta channels - for most people, the "stable" channel is just a marker which lets them know they can use something because it's commonly supported (they already know how to use it, because they already have via the beta spec). For example, back when i worked in a web agency making end user websites, I would hack and do demo's using "dev" channel features, I'd use beta features on my own sites, and for customers who wanted new features and didn't particularly care about legacy browsers, and I'd use stable only for larger corps, NGOs and gov sector clients. As another example, if I was making an HTML editing tool, then I'd be implementing the beta features, and thus need that spec. As for timelines, the "living" is just living, the "dev" is whenever something is ready to push there, the "beta" is arguably one of the most important and used, needing at least a 3 month update schedule, because that's the one most people will actually reference when adopting and implementing features. As for the stable branch I'm unsure, whenever a feature can be classed as stable and ready to be pushed there I guess. Hopefully that clarifies, best, Nathan
Received on Thursday, 17 February 2011 03:10:27 UTC