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
  • precondition: consensus has been reached among the various *-brainstorming proposals, sufficient to write-up into a stand-alone draft.
  • means: ready for publishers to start experimenting with on their public pages, and providing feedback for draft iteration accordingly
  • means: ready for consumers to start experimenting with consuming such publishers, and providing feedback for draft iteration accordingly
  • stability: major changes can still occur, including adding/dropping/renaming arbitrary features (based on research and publisher/consumer implementation feedback)
• specification - a draft that is mature/stable as determined by:
  • precondition: all outstanding *-issues resolved (bounced off zero issues, and perhaps stayed there for a few weeks)
  • precondition: 1+ solid real world publisher(s) that
    • benefit end users (i.e. not just fictional/artificial data published for data's sake)
    • not the/an editor of the spec (demonstrates some breadth of interest)
  • precondition: 1+ solid real world consumer(s) that
    • successfully consumes the microformats published by the aforementioned publisher(s).
    • provides real world end user benefits / use-cases (libraries/opensource are nice as enablers but insufficient for this)
    • not the/an editor of the spec (demonstrates some breadth of interest)
  • means: ready for publishers to start depending on
  • means: ready for consumers to start depending on
  • stability: minor changes can still occur based on real-world publisher/consumer implementation experience, up to and including dropping of properties and values (especially in order to reach "standard" stage - see below)
  • test cases: hReview and hAtom are ready to become "specifications" with a bit of work:
    • resolve outstanding issues and incorporate into spec updates (0.4, 0.2 respectively)
    • use existing *-examples-in-wild and *-implementations pages as supporting evidence for publisher(s)/consumer(s) requirement
• standard - only market proven specifications are standards for practical purposes, thus this is determined by:
  • precondition: test suite with at least one test per feature (property/value) (should be easy)
  • precondition: 2+ solid real world publishers as defined above for "specification"
  • precondition: 2+ solid real world consumers as defined above for "specification" and with additional requirements that:
    • pass the test suite tests
    • interoperably consume the microformats published by the aforementioned publishers.
  • precondition: each property is published by 2+ of those publishers
  • precondition: each property is consumed by 2+ of those consumers
  • thus properties that are published by <2 publishers or consumed by <2 consumers block advancement from specification to standard. The options to progress to standard are:
    • drop such under-supported property(ies) - insufficient market support to keep them. Thus properties which fail in the real world should be and get dropped. This also supports the simplify principle. Such features may be reconsidered for future versions if more sufficient publishers/consumers adopt them.
    • or wait for more additional publisher(s)/consumer(s) to support them. a bit up to the editor's preference.
  • means: the market is interoperably publishing and consuming this microformat
  • means: at this point bump the version # to 1.0 (if it isn't there already)
  • stability: the microformat is considered stable, and only minor errata are expected in response to real world publishing/consuming implementation experience
  • test cases: hCard and hCalendar are ready to 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