process-issues-resolved

Process issues that are resolved, but may have outstanding to-do items. As issues are resolved, they will be moved from the top of the issues list to the this page.

Once to-do items are complete, resolved issues will be moved to process-issues-closed.

2008

• 2008-07-24 raised by TobyInk
  1. 1. Has the process failed to produce any microformat specifications? A look at the list of "official" (non-draft) microformats on the main page shows that none of them were developed through the process — most have simply been POSH formats created outside the microformats community which were then "adopted". e.g. XMDP and XFN from GMPG; rel-tag from Technorati; hCard and hCalendar were simply proposed on Tantek's blog; ditto rel-license; and rel-nofollow is from Google. In contrast, drafts being run through the process languish there for years, their proponents often eventually giving up and abandoning them. Given that there are no examples of a microformat that has successfully made it through the process, it is not unreasonable to conclude that the process as is has failed.
     • RESOLVED ACCEPTED. to-do Yes, the process has failed to clarify how to get from a draft to a specification and this has likely been a major cause of the lack of any examples of a microformat that has successfully made it to "specification" via the process. To address this, there is now process-brainstorming proposal for better definitions and steps to advanced from "draft" to "specification" and to "standard" (new). Once this brainstorm proposal has seen some discussion/iteration we'll incorporate it into the process and close this issue accordingly.
  2. 2. I am not arguing that there should be no process at all — indeed in Manu's article linked to above, he cites instances where the process is helpful. But the process should be less onerous than it is currently.
     • RESOLVED REJECTED BY DESIGN. The process by design is meant to filter out and discourage the trivial creation of microformats by anyone/everyone, and rather help focus and create high quality microformats.
  3. 3. In particular, clearer guidelines should be established for when each stage of the process is "over". examples: how many is enough?
     • RESOLVED DUPLICATE. Duplicate of Manu's 2007 issue.
  4. 4. In particular, clearer guidelines should be established for when each stage of the process is "over". formats: how many is enough?
     • RESOLVED ACCEPTED FAQ. to-do add to FAQ: How many formats are enough? A: For formats the question is not one of quantity but rather of sufficient thoroughness in research. That is, at a minimum you should check search engines and Wikipedia for efforts at formats in the topic area that you're researching a microformat for. If you can't find any (or find very few), ask in IRC and on the email lists.
  5. 5. In particular, clearer guidelines should be established for when each stage of the process is "over". brainstorming: how long should editors wait for objections to a draft schema before "freezing" it and determining the class names?
     • RESOLVED ACCEPTED FAQ. to-do add to FAQ: Ask on IRC and the mailing lists. If you get no responses, that means there is too little interest in the topic area and it is unlikely deserving of a microformat. Stop.
  6. 6. In particular, clearer guidelines should be established for when each stage of the process is "over". draft: how long should a microformat remain in draft form before becoming "official"? would it be better to say that a draft will become official once there are N interoperable implementations (for some number N)? what scale of objections to the draft should result in a change to the draft, and which objections are big enough to send the draft back to the brainstorming stage?
     • RESOLVED ACCEPTED. to-do This is a core issue with the process and requires more work. See process-brainstorming for proposed definitions of draft vs specification vs standard that address this issue. Once those definitions/steps have been incorporated into the process this issue will be closed.
  7. 7. The process should be something that helps people establish new microformats; not something that they have to fight against.
     • RESOLVED REJECTED AMBIGUOUS. It's not clear what action is suggested here, as in some ways, both statements are true. That is, the process is absolutely something that helps people research, develope, and create a new microformat. On the other hand the process also by design is meant to be formal and at least somewhat rigorous. Science is not easy, you have to follow proper methods.

see also

• process-issues
• process-issues-closed