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. `._.-(,_..'--(,_..'`-.;.'