process-issues

process issues

These are issues that have been raised about the microformats process with broadly varying degrees of merit. Thus some issues are rejected for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be accepted and perhaps cause changes or improved explanations in the spec.

Important: Please read the process FAQ before giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well.

Closed Issues

Resolved issues that have no further actions to take. These will likely be moved to a separate page like process-issues-closed.

• none yet.

Resolved Issues

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 bottom of this section.

• none yet.

Issues

Please add new issues to the bottom of the list by copying and pasting the template. Please follow-up resolved or rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

2005

• open issue! 2005-07-03 raised by User:Bud
  1. I would point out that the paving the cowpaths method suggests that all you are doing is enshrining current practice. One question I asked myself is how something like reltag fits into that. hCard certainly does. Not sure about hReview. What I would say more is that you are "enabling emerging practices". Maybe you should say "widening the ferrett holes".

2007

• open issue! 2007-09-07 raised by Manu Sporny
  1. Issue 1: What constitutes "Enough Examples"
  2. Issue 2: Proper interpretation of W3C standards
  3. Issue 3: Keeping up with changes to the process becomes frustrating
  4. Issue 4: There is no clear order of operations for "The Process". This makes uF creation a trial-and-error process that can frustrate new members, that may waste time on things that don't matter. It also annoys old members of the community, that have to answer the same questions over and over again.
  5. Issue 5: Analayzing the receipts-examples is difficult because we don't have a central location to dump the example, scrubbed HTML. We need a central SVN repository.
  6. Issue 6: We don't have a central Microformats code repository for tools and utilities that are useful to the community.
     1. hg.microformats.org is the code repository we have been using for several years now. There is also a wiki that can be used to link to various implementations. A central code repository, or lack of, should not be an issue in the process when developing a new format?

2008

• open issue! 2008-07-24 raised by TobyInk
  • Is the process more of a hindrance than a help?
    • 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.
    • 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.
    • In particular, clearer guidelines should be established for when each stage of the process is "over".
      • examples: how many is enough?
      • formats: how many is enough?
      • brainstorming: how long should editors wait for objections to a draft schema before "freezing" it and determining the class names?
      • 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?
    • The process should be something that helps people establish new microformats; not something that they have to fight against.

Template

Please use this format (copy and paste this to the end of the list to add your issues):

• open issue! YYYY-MM-DD raised by YOURNAME.
  1. Issue 1: Here is the first issue I have.
  2. Issue 2: Here is the second issue I have.

Related Pages

• process
• process-faq
• process-brainstorming