- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 9 Jun 2008 21:51:51 +0000 (UTC)
- To: Laura Carlson <laura.lee.carlson@gmail.com>
- Cc: public-html@w3.org
I noticed a query on the www-archive list regarding what the process was for adding features to the spec. I tried to find somewhere where this was documented, but all I could find was how to raise issues, which is a different process altogether. So, here's a look at how to propose new features. I hope it is helpful. On Sat, 7 Jun 2008, Laura Carlson wrote: > > So... > > Step number one is...? > Step number two is...? > Step number three is...? > etc. > Last step is proposal is incorporated into spec. Actually that's far from the last step. The process for adding features to the spec is: 1. Research the use cases and requirements by discussing the issue with authors and implementors. Read the responses. Listen to the feedback. Consider whether your ideas are good solutions to the use cases and requirements put forward. Discussions here should be done in public, e.g. on an archived public mailing list or documented in blogs. 2. Get implementors to commit to implementing the feature. If you can't get several implementors to implement the feature, then get at least one user agent to implement it experimentally. Experimental implementations should be publicly available. 3. Bring the experimental implementations to the attention of the spec's editors. Document the experience found from any implementations, the use cases and requirements that were found in the first step, the data that the design was based on. 4. Participate in the design discussions, considering all the proposals carefully. Typically at this step the original design gets thrown out and a significantly better design is developed, informed by the previous research, new research, and implementation and author experience with experimental implementations. Sometimes, the idea is abandoned at this stage. 5. The spec is updated to reflect the new design. 6. Implementations are updated to reflect the new design. More authors and implementors are exposed to the design. 7. The spec is updated to fix the many problems discovered by authors and implementors, over a period of several years. 8. At the same time, write a comprehensive test suite. This will also find problems in the spec, which have to be fixed. 9. Eventually, a number of provably interoperable implementations are deployed. At this point development of the feature is somewhat frozen. This is the process that has been followed for almost all the new features in HTML5. Some features failed to go through this process, most of those are likely to be removed (e.g. the data templates stuff). I should add that in almost all cases, features fail to make it past the first few steps. Even after reaching step 5 (adding the feature to the spec), if the feature doesn't get implemented widely it can (and will!) _still_ be dropped. The default state for a feature request is for it to be rejected; the default state for a section of the spec is for it to be eventually dropped. I can't could the number of ideas I've had that I've thrown out, sometimes before even talking to anyone about them (step 1). Also, at the moment I'm being especially negative in terms of new features, since HTML5 has so many new things already and implementations are lagging behind. We don't want to add so many things to the spec that user agents all implement different new features and nobody is compatible! Because of this, the bar for adding features right now is basically a threat from an implementor that if we don't add the feature they'll just make it up themselves and implement it anyway. This limits it only to things that are so important that browser vendors (an especially stingy and overworked group) are actually ready to commit money and risk interop issues over it. (This doesn't apply to features that were proposed last year or earlier, since those would already been processed last year, before the feature freeze was announced, if it wasn't for me being slow.) > Where does bugzilla fit in? > Where does issue tracker fit in? Those are more useful for tracking problems and errors in the spec, than for tracking new features. > Where and how is this agreement made? That doesn't really matter so long as it is publicly archived and that the core community (for lack of a better definition, those on the public-html and whatwg lists) knows about it soon enough. > Which implementors and authors are you referring to? As many as possible. Certainly we'd want representatives of the top four browser vendors involved (or at least invited). HTH, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 9 June 2008 21:52:32 UTC