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 _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss