Draft to Specification (was: [uf-discuss] More than three years)

[Ben Ward]

On 27 Aug 2008, at 17:38, Zachary Carter wrote:

> What does it take to bump a draft, say hResume, to spec status? Just
> resolving the remaining open issues, or is there more to it?

It's definitely something that people are unclear on. On my part I've  
been thinking a lot regarding ‘the role of editors’, spec status and  
so forth. My moving to San Francisco this month has pretty much  
neutralised my ability to contribute whilst I find an apartment and  
get settled in the US. The sunshine is awesome, though.

I will get it written up fully, but in short, my view is that spec  
editors need to be ‘actively’ working on their spec (for some value of  
active, with some *simple* conditions for passing editorial control of  
specs away from inactive/unsuitable editors when demand arises).

In my view, a specification goes from draft to ‘release’ when all  
issues are resolved in some way, and issue resolution should be a  
simple enumeration, probably one of ‘fixed’, ‘invalid’ or ‘deferred  
for future iteration’. Some clause needs to sit in place to ensure  
that specs are suitably vetted — we don't want someone creating a spec  
quickly, fixing a small number of raised issues and declaring  
something a spec just because they reach the ‘issues’ finishing line.  
It absolutely needs not to be a ‘finishing line’ at all.

Maybe each spec should have a required minimum draft iterations before  
it can go 1.0, allowing people to participate at different levels.  
Those passionate about subject matter will take interest at the 0.1  
stage, those who are simply active within microformats in general  
would review specs at the second or third draft to protect against  
process violations and fast-tracking. I wouldn't want anything too  
strict, but all specs iterate draft versions anyway, so it might be  
wise to map them to cue issue review.

It's also worth saying that I'd want to avoid ‘spec status’ being  
misinterpreted as something being ‘finished’. Specs should always be  
open to evolutionary iteration.

Ben