From Microformats Wiki
process-brainstorming /
Revision as of 18:46, 11 February 2011 by Tantek (talk | contribs) (→‎draft spec standard: make more JSON-like per feedback from Chris Messina at ActivityStreams meetup, simplified/shortened descriptions)
Jump to navigation Jump to search

<entry-title>process brainstorming</entry-title>

I'm using this page to collect brainstorms on additions to the The microformats process for discussion and feedback before incorporation. -- Tantek

draft spec standard proposal

problem statement

  • What's the real world problem we're solving? (should ask for all microformats efforts)
    • no microformats "drafts" have made it to "specification" since site launch in 2005
  • Why is this a real world problem?
    • perception/actual lack of microformats progress, or frustration with (in)ability to make progress, hurts adoption/evangelism efforts, raises barrier to additional adoption of microformats.
  • Is this just blocked due to lack of explicit process or is there something more?
    • Tantek: both.
      • Yes there is currently no defined The microformats process for transitioning from draft to specification. Hence this proposal.
      • Also - outstanding issues. From my perspective, for most of the past, none of the drafts have deserved progressing due to unresolved issues regarding accessibility and internationalization. Fortunately most of those cross-microformat issues were actually finally resolved in 2009 and most specific microformat (e.g. hCard issues) have been resolved since.
      • What remains:
        • draft a simple process that provides the minimal needed guidance for evolving drafts.
        • take/iterate one or more drafts through the new stages to prove out the process (perhaps oldest/most popular first: hCard 1.0, hCalendar 1.0, hReview 0.4 (in progress), hAtom 0.1)
          • resolve outstanding issues, incorporate issue resolutions into draft iterations
        • evaluate how well that "worked" and iterate process accordingly.


  • How do we create "real world" process for advancing drafts?
    • follow microformats philosophy, gather examples of what others do, what works, minimally pick 80/20 that seem necessary, base it on microformats principles (real world, mimimal).

Research: previous efforts at defining specification progress stages:

  • W3C process: Working Draft (WD), Last Call (WDLC), Candidate Recommendation (CR), Proposed Recommendation (PR), Recommendation (REC).
  • IETF process: Internet Draft (draft), RFC, Proposed Standard, Draft Standard, Standard.
  • WhatWG process: continuously updated editor's specification, "living standard", no document stages/phases. unknown stability.

draft spec standard

Thus, draft stages brainstorm: draft, specification (as used currently), and standard (new) based on being market proven (only market proven standards are "real world" standards).

Specific brainstorm definitions:

  • draft - experimental new microformat
    • preconditions:
      • consensus has been reached among the various *-brainstorming proposals
    • actions:
      • determine a name for the new microformat (**)
      • write-up consensus brainstorm into a stand-alone draft
      • create **-issues page for collecting feedback
    • means:
      • ready for publishers to start experimenting with on their public pages
      • ready for consumers to start experimenting with consuming such publishers
      • and both providing feedback for draft iteration accordingly
    • stability:
      • major changes can still occur
      • e.g. add/drop/rename arbitrary features (per research/feedback from publishers/consumers)
  • specification - a stable and mature draft
    • preconditions:
      • all outstanding **-issues resolved (hit zero issues for a few weeks)
      • 1+ solid real world publisher(s) that
        • beyond the editor(s) of the spec (demonstrates some breadth of interest)
        • benefits end users (i.e. not just artificial data published for data's sake)
      • 1+ solid real world consumer(s) that
        • beyond the editor(s) of the spec (demonstrates some breadth of interest)
        • successfully consumes the microformats published by the publisher(s).
        • provides real world end user benefits / solves use-cases
        • (libraries/opensource are nice as enablers but insufficient for this)
    • actions:
      • update draft to use specification template
      • create **-examples-in-wild, **-implementations pages to collect them
    • means:
      • ready for publishers to start depending on
      • ready for consumers to start depending on
    • stability:
      • minor changes can still occur
      • e.g. dropping of properties and values (e.g. to reach "standard" - see below)
      • iteration based on real-world publisher/consumer experience
    • actions:
      • encourage widespread adoption by all publishers and consumers
      • evaluate properties published by <2 publishers
      • evaluate properties consumed by <2 consumers
        • such properties block advancement from specification to standard.
        • drop such under-supported property(ies) - insufficient market support to keep them. properties which fail in the real world should be and get dropped (per the simplify principles). features may be reconsidered for future versions.
        • or wait for more additional publisher(s)/consumer(s) to support them. up to editor's preference.
    • example microformats to advance:
      • hReview 0.4 (in progress) and hAtom 0.1 can become "specifications" with a bit of work:
        • resolve issues, incorporate into spec updates (0.4, 0.2 respectively)
        • *-examples-in-wild *-implementations pages show publisher(s)/consumer(s) support
  • standard - market proven microformat
    • preconditions:
      • test suite with 1+ test per feature (e.g. property) (should be easy)
      • 2+ solid real world publishers as defined above for "specification"
      • 2+ solid real world consumers as defined above for "specification" that:
        • pass the test suite tests
        • interoperably consume microformats published by the publishers.
      • each property is published by 2+ of those publishers
      • each property is consumed by 2+ of those consumers
    • actions:
      • bump the version # to 1.0 (if it isn't there already)
    • means:
      • the market is interoperably publishing and consuming this microformat
    • stability:
      • the microformat is considered stable
      • minor errata expected per real world publishing/consuming experience
    • example microformats to advance:
      • hCard 1.0 and hCalendar 1.0 can become "standards" with a bit of work:
        • incorporate resolved issues into 1.0.1 releases (use 1.0.1 due to how long we left them a 1.0)
        • write up remaining missing test cases for a full property (not necessarily value) coverage test suite
        • drop insufficiently supported properties (e.g. "class", "key")

see also