process-brainstorming

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

I'm using this page to collect brainstorms on additions to the 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 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, hCalendar, hReview, hAtom)
        • resolve outstanding issues, incorporate issue resolutions into draft iterations
      • evaluate how well that "worked" and iterate process accordingly.

research

• 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
      • are not the editor(s) of the spec (demonstrates some breadth of interest)
      • benefit end users (i.e. not just artificial data published for data's sake)
    • 1+ solid real world consumer(s) that
      • are not the editor(s) of the spec (demonstrates some breadth of interest)
      • successfully consume the microformats published by the publisher(s).
      • provide real world end user benefits / solve 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 principle). 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 and hAtom 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 and hCalendar 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

• process
• process-faq
• process-issues
• process-principles