process-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(moving metaprocess thinking to process-principles where it belongs, add draft spec standard proposal from events/2011-02-01-microformats-dinner)
(→‎draft spec standard: make more JSON-like per feedback from Chris Messina at ActivityStreams meetup, simplified/shortened descriptions)
Line 37: Line 37:


Specific brainstorm definitions:
Specific brainstorm definitions:
* '''draft'''
* '''draft''' - experimental new microformat
** precondition: consensus has been reached among the various *-brainstorming proposals, sufficient to write-up into a stand-alone draft.
** '''preconditions:'''
** means: ready for publishers to start experimenting with on their public pages, and providing feedback for draft iteration accordingly
*** consensus has been reached among the various *-brainstorming proposals
** means: ready for consumers to start experimenting with consuming such publishers, and providing feedback for draft iteration accordingly
** '''actions:'''
** stability: major changes can still occur, including adding/dropping/renaming arbitrary features (based on research and publisher/consumer implementation feedback)
*** determine a name for the new microformat (**)
* '''specification''' - a draft that is mature/stable as determined by:
*** write-up consensus brainstorm into a stand-alone draft
** precondition: all outstanding *-issues resolved (bounced off zero issues, and perhaps stayed there for a few weeks)
*** create **-issues page for collecting feedback
** precondition: 1+ solid real world publisher(s) that
** '''means:'''
*** benefit end users (i.e. not just fictional/artificial data published for data's sake)
*** ready for publishers to start experimenting with on their public pages
*** not the/an editor of the spec (demonstrates some breadth of interest)
*** ready for consumers to start experimenting with consuming such publishers
** precondition: 1+ solid real world consumer(s) that
*** and both providing feedback for draft iteration accordingly
*** successfully consumes the microformats published by the aforementioned publisher(s).  
** '''stability:'''
*** provides real world end user benefits / use-cases (libraries/opensource are nice as enablers but insufficient for this)
*** major changes can still occur
*** not the/an editor of the spec (demonstrates some breadth of interest)
*** e.g. add/drop/rename arbitrary features (per research/feedback from publishers/consumers)
** means: ready for publishers to start depending on
* '''specification''' - a stable and mature draft
** means: ready for consumers to start depending on
** '''preconditions:'''
** 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)
*** all outstanding **-issues resolved (hit zero issues for a few weeks)
** test cases: [[hReview]] and [[hAtom]] are ready to become "specifications" with a bit of work:
*** 1+ solid real world publisher(s) that
*** resolve outstanding issues and incorporate into spec updates (0.4, 0.2 respectively)
**** beyond the editor(s) of the spec (demonstrates some breadth of interest)
*** use existing *-examples-in-wild and *-implementations pages as supporting evidence for publisher(s)/consumer(s) requirement
**** benefits end users (i.e. not just artificial data published for data's sake)
* '''standard''' - only market proven specifications are standards for practical purposes, thus this is determined by:
*** 1+ solid real world consumer(s) that
** precondition: test suite with at least one test per feature (property/value) (should be easy)
**** beyond the editor(s) of the spec (demonstrates some breadth of interest)
** precondition: 2+ solid real world publishers as defined above for "specification"
**** successfully consumes the microformats published by the publisher(s).  
** precondition: 2+ solid real world consumers as defined above for "specification" and with additional requirements that:
**** provides real world end user benefits / solves use-cases
*** pass the test suite tests
**** (libraries/opensource are nice as enablers but insufficient for this)
*** interoperably consume the microformats published by the aforementioned publishers.
** '''actions:'''
** precondition: each property is published by 2+ of those publishers  
*** update draft to use specification template
** precondition: each property is consumed by 2+ of those consumers
*** create **-examples-in-wild, **-implementations pages to collect them
** 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:
** '''means:'''
*** 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.
*** ready for publishers to start depending on
*** or wait for more additional publisher(s)/consumer(s) to support them. a bit up to the editor's preference.
*** ready for consumers to start depending on
** means: the market is interoperably publishing and consuming this microformat
** '''stability:'''
** means: at this point bump the version # to 1.0 (if it isn't there already)
*** minor changes can still occur  
** stability: the microformat is considered stable, and only minor errata are expected in response to real world publishing/consuming implementation experience
*** e.g. dropping of properties and values (e.g. to reach "standard" - see below)
** test cases: [[hCard]] and [[hCalendar]] are ready to become "standards" with a bit of work:
*** iteration based on real-world publisher/consumer experience
*** incorporate resolved issues into 1.0.1 releases (use 1.0.1 due to how long we left them a 1.0)
** '''actions:'''
*** write up remaining missing test cases for a full property (not necessarily value) coverage test suite
*** encourage widespread adoption by all publishers and consumers
*** drop insufficiently supported properties (e.g. "class", "key")
*** 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 ==
== see also ==

Revision as of 18:46, 11 February 2011

<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
        • 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 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