process-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (Replace <entry-title> with {{DISPLAYTITLE:}})
 
(6 intermediate revisions by one other user not shown)
Line 1: Line 1:
<h1>process brainstorming</h1>
{{DISPLAYTITLE:process brainstorming}}


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


What's wrong with focusing on preventing the negatives?
=== related issues questions regarding document stages ===


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


What is the alternative to preventing the negatives?
== see also ==
 
* [[process]]
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.
* [[process-faq]]
 
* [[process-issues]]
The key alternative to prevent the negatives is the inversion of the entire statement.
* [[process-principles]]
 
== Enable the positives ==
 
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.
 
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.
 
(Should this have been a blog post instead?)

Latest revision as of 16:31, 18 July 2020


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

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