process-brainstorming
Revision as of 18:46, 11 February 2011 by Tantek (talk | contribs) (→draft spec standard: make more JSON-like per feedback from Chris Messina at ActivityStreams meetup, simplified/shortened descriptions)
<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.
- Tantek: both.
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)
- preconditions:
- 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:
- preconditions:
- 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")
- hCard and hCalendar can become "standards" with a bit of work:
- preconditions: