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")

related issues questions regarding document stages

• if/when does it make sense to demote a microformat spec to a lower level?
  • can a standard be undone? we haven't seen any examples of this, but it is certainly possible that a sufficient implementations/publishers of a standard could disappear until it no longer meets requirements, should (and when should) it be demoted to just a specification or perhaps even a draft?
  • from spec back to draft it's possible that implementations or publishers may disappear, and thus what used to qualify as a specification no longer meets the requirements, when should it be demoted explicitly back to a draft?
  • undrafts e.g. there are plenty of drafts that never got any traction, should we have another category for "uninteresting-draft" that means no one other than the editor(s)/author(s) really cared for it, and thus it isn't a priority for the community. maybe we could call these "undrafts" - where drafts go when they don't make it to spec after some amount of time. From there it's probably best to simply use them for more brainstorming, and not encumber any future microformat effort with their legacy. This is likely important to keep the list of drafts as accurate/recent, and will also likely be challenging case-by-case judgment calls.

see also

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