process-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(entry-title, see also)
(moving metaprocess thinking to process-principles where it belongs, add draft spec standard proposal from events/2011-02-01-microformats-dinner)
Line 1: Line 1:
<entry-title>process brainstorming</entry-title>
<entry-title>process brainstorming</entry-title>


A lot of thought and experience went into designing the microformats [[process]], and somewhere I want to capture that background.  However, this page is not for that purpose, but rather to collect brainstorms and ideas on improving the process, along with some methodologies (or patterns) for considering changes to the process.
I'm using this page to collect brainstorms on additions to the [[process]] for discussion and feedback before incorporation. -- [[User:Tantek|Tantek]]


by [http://tantek.com/ Tantek], 20060801T1745-0700.
== draft spec standard proposal ==


== Questioning Assumptions ==
=== problem statement ===
<div class="discussion">
* '''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.
</div>


Much of what [[microformats]] has achieved can be directly attributed to various assumptions made by other organizations, groups, experts that have been questioned about technology, markup, adoption, XML, XHTML etc.
=== research ===
<div class="discussion">
* '''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).
</div>


There are other kinds of assumptions being questioned as well however, even assumptions that most don't even realize they are making due to habits and ways of thinking learned years ago. Not to mention established cultural behaviors in various communities.
Research: previous efforts at defining specification progress stages:
* [http://w3.org W3C] process: Working Draft (WD), Last Call (WDLC), Candidate Recommendation (CR), Proposed Recommendation (PR), Recommendation (REC).
* [https://secure.wikimedia.org/wikipedia/en/wiki/Internet_standard 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.


=== Prevent the negatives ===
=== 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).


One assumption that pervades A LOT of process-think (bureaucracy if you will) is that it is of utmost importance (unquestioned even) to prevent negatives from occuring. I'm using "negative" here as a shorthand for "negative actions", "negative outcomes", "negative effects" etc.  If you read any contracts for example, you'll see an incredible focus and obsession about preventing the negatives.  Most processes build up rules to follow to prevent a negative that occured that recently occured. Problem happens. Not covered by the process.  Rules added to the process to prevent the problem. One might even assert that most governments and bodies of law are grown this way.
Specific brainstorm definitions:
 
* '''draft'''
What's wrong with focusing on preventing the negatives?
** 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
Because rarely is that the *actual* goal of any organization or effort.  Most efforts have a specific *constructive* goal in mind and *that* goal is more important than the prevention of any negative. While that may be easy to understand, the habit of preventing the negative is so deeply ingrained that people often act to prevent the negative to such a great extent that they prevent the *actual* goal(s) of the effort(s) as well, and thus end up thinking and acting against their own interests.
** 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)
What is the alternative to preventing the negatives?
* '''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)
One alternative might be the actual goal of the organization or effort, as explained above.  But that doesn't work.  Or rather, it doesn't work in a universal enough way in order to actually combat the deeply seated prevent the negative assumption. When that goal or effort is completed, it is far too easy to simply fall back on old habits.
** precondition: 1+ solid real world publisher(s) that
 
*** benefit end users (i.e. not just fictional/artificial data published for data's sake)
The key alternative to prevent the negatives is the inversion of the entire statement.
*** not the/an editor of the spec (demonstrates some breadth of interest)
 
** precondition: 1+ solid real world consumer(s) that
== Enable the positives ==
*** 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)
One of the key realizations that I (and lots of other people have) had when first seeing and subsequently interacted with Wikipedia was how the nature of the medium and the culture and the community built around it enabled a constant stream of small positive steps to construct something incredible. I'm not sure that aspect was overtly designed into the system (and the culture around it), or if it was a happy accident or if it evolved. Regardless, we can use that aspect as a design center, especially in something like microformats which also depends on the incremental positive contributions of lots of people.
*** not the/an editor of the spec (demonstrates some breadth of interest)
 
** means: ready for publishers to start depending on
Thus when someone does something which appears to cause a negative, rather than first think, how do we prevent that, we should consider, how can we redirect/shape the *initiative*, *energy*, and *interest* of that person and *enable* such contributions to be positive, rather than focusing on preventing such actions.  In the long term, I think this kind of philosophical shift will be absolutely essential for scaling both the growth and productivity of the community.
** 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)
(Should this have been a blog post instead?)
** 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 &lt;2 publishers or consumed by &lt;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 ==
== see also ==
Line 37: Line 80:
* [[process-faq]]
* [[process-faq]]
* [[process-issues]]
* [[process-issues]]
* [[process-principles]]

Revision as of 02:11, 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
    • 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

Retrieved from "http://microformats.org/wiki/index.php?title=process-brainstorming&oldid=43566"