events/2011-02-01-microformats-dinner

One of several microformats meetup events.

Details

When

2011-02-01 from 19:00 to 21:00

Where

21st Amendment, 563 2nd Street, San Francisco, CA 94107 USA

What

Microformats Weekly Meetup Dinner, San Francisco

Web

http://upcoming.org/event/7697850/

http://www.facebook.com/event.php?eid=179746412062960

http://plancast.com/p/3q2t

Add this event to your calendar

Meetup

The microformats community has grown and stabilized over the past few years, news of adoptions, new ideas and challenges come up frequently enough that there are no shortage of new topics to discuss on a regular basis.

Come along, meet up with the microformats community in San Francisco.

In another city? Check out Weekly Meetup: Other Cities and help organize one in your own city!

Tags

Use the following tags on related content (blog posts, photos, tweets):

tags: microformats-dinner microformats-meetup microformats san-francisco soma southpark 2ndstreet 21stAmendment microformats-dinner-2011-02-01 upcoming:event=7697850

If you use Twitter, mention @microformats dinner' in tweets about the event, and track them on Twitter Search.

Attendees

Add yourself alphabetically sorted by family name if you plan on attending or attended this event.

• Tantek Çelik
• Ben Ward
• Kevin Marks
• Jeremy Anderson
• Laura
• Ian Fung
• PJKix

Photographs

• Search for photographs from this event on Flickr: Photographs tagged microformats-dinner-2011-02-01 or for all photographs from microformats dinners.

Add a photograph from this event here.

Notes

Topics Discussed:

• admins - how to mentor and develop new admins, encourage positive community growth
• microformats-2
• process-brainstorming, specifically, iterating on ideas for more precisely defining the state of microformats specs. Thoughts by Tantek, with additional suggestions incorporated from Kevin Marks and Ben Ward:
  • 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.
      • 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:
    • 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
  • 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
    • consensus has been reached among the various *-brainstorming proposals, sufficient to write-up into a stand-alone draft.
    • ready for publishers to start experimenting with on their public pages, and providing feedback for draft iteration accordingly
    • ready for consumers to start experimenting with consuming such publishers, and providing feedback for draft iteration accordingly
    • major changes can still occur
  • specification - a draft that is mature/stable as determined by:
    • all outstanding *-issues resolved (bounced off zero issues, and perhaps stayed there for a few weeks)
    • 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)
    • 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)
    • minor changes can still occur, up to and including dropping of properties and values (especially in order to reach "standard" stage - see below)
    • 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:
    • test suite with at least one test per feature (property/value) (should be easy)
    • 2+ solid real world publishers as defined above for "specification"
    • 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.
    • each property is published by 2+ of those publishers
    • 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.
    • at this point bump the version # to 1.0 (if it isn't there already)
    • 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")

Articles and Blog Posts

Articles and blog posts following up on the meetup. Add a link to your post in the list below:

• ...

Also, find posts on this meetup on Google Blog Search or Technorati.

Related Pages

• upcoming and recent events
• events in 2012
• events in 2011
• events in 2010
• events in 2009
• events in 2008
• events in 2007
• events in 2006
• Template for an individual event page