Difference between revisions of "process-brainstorming"

From Microformats Wiki
process-brainstorming
Jump to navigation Jump to search
(moving metaprocess thinking to Process principles where it belongs, add draft spec standard proposal from Microformats Dinner & Drinks)
m (Replace <entry-title> with {{DISPLAYTITLE:}})
 
(4 intermediate revisions by one other user not shown)
Line 1: Line 1:
<entry-title>process brainstorming</entry-title>
+
{{DISPLAYTITLE:process brainstorming}}
  
 
I'm using this page to collect brainstorms on additions to the [[process]] for discussion and feedback before incorporation. -- [[User:Tantek|Tantek]]
 
I'm using this page to collect brainstorms on additions to the [[process]] for discussion and feedback before incorporation. -- [[User:Tantek|Tantek]]
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)
+
**** are not 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
+
**** benefit 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)
+
**** are not the editor(s) of the spec (demonstrates some breadth of interest)
** precondition: 2+ solid real world publishers as defined above for "specification"
+
**** successfully consume the microformats published by the publisher(s).  
** precondition: 2+ solid real world consumers as defined above for "specification" and with additional requirements that:
+
**** provide real world end user benefits / solve 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 &lt;2 publishers or consumed by &lt;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 &lt;2 publishers
 +
*** evaluate properties consumed by &lt;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 ===
 +
 
 +
<div class="discussion">
 +
* '''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.
 +
</div>
  
 
== see also ==
 
== see also ==

Latest revision as of 16:31, 18 July 2020


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.

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

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