[uf-discuss] moving drafts forward - process-brainstorming: draft, specification, standard

[Tantek Çelik]

It's been noted[1][2] that no drafts are making it to specification,
and in short there are two reasons for this:

1. Lack of steps in the process[3] for how a draft should proceed to
specification and what each of those mean (other than the summary on
the Main Page[4]), including lack of documentation of implicit
assumptions such as that all outstanding issues must be resolved on a
draft (and any patterns it depends on) before we can in good
conscience make it a specification. As the editor/maintainer of the
process, I accept full personal responsibility for this.

2. Blocking issues. During the development of various drafts we
encountered a few blocker cross-microformat issues (e.g.
accessibility, internationalization) which were potentially doing
harm. Since then, those cross-microformat issues have been
resolved[5], and we've been incorporating those resolutions into the
specifications (e.g. hCard, hCalendar) as well as into resolutions of
spec-specific issues.


I've been working the past few weeks on addressing #1 above.

Having had the experience of confronting and overcoming these
cross-microformat issues, as well as close experience with the
document stages in W3C and IETF (and what works / is pragmatically
useful vs what is mostly just bureaucratic), I've developed the
following minimal process brainstorm:

http://microformats.org/wiki/process-brainstorming

Summary: three defined document stages:

* draft: consensus among brainstorm proposals, experimental, it's
ready for trial on the public web.

* specification: all outstanding issues resolved, stable, 1+ real
world publisher(s)+consumer(s), it's ready to depend on.

* standard: (new) test suite and 2+ interoperable real world
publisher(s)+consumer(s) for each feature, errata only, what the
market has accepted.


These are strictly summaries - please see
http://microformats.org/wiki/process-brainstorming for more precise
preconditions, actions, definitions, stability, and example steps to
take.


Please raise any *major* problems you note directly in an "Issues"
section on the process brainstorming page.


Assuming no major problems are found (minor are ok to fix in
iterations) in the next few days, I plan on incorporating this
brainstorm into the process itself[3] and starting to take various
current/mature specifications and drafts forward to exercise these new
steps / definitions to see how well they work in practice.


In short: I believe we can quickly get many specifications to the new
level of "standard" (e.g. hCard, hCalendar) after perhaps some
trimming of unused properties, as well as several drafts to
"specification" (e.g. hReview, hAtom) with an iteration that
incorporates issue resolutions having especially to do with the
cross-microformat issues noted above.

Thanks,

Tantek


[1] http://en.wikipedia.org/wiki/Microformat#Evaluation_of_microformats
[2] http://lists.w3.org/Archives/Public/public-html/2010Dec/0089.html
[3] http://microformats.org/wiki/process
[4] http://microformats.org/wiki/Main_Page#Specifications
[5] http://microformats.org/wiki/value-class-pattern

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5