process brainstorming

Jump to: navigation, search

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.


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

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:

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

process brainstorming was last modified: Thursday, March 3rd, 2011