[uf-new] Leading by example (was: Standards bodies)

[Manu Sporny]

Brian, you have made some very valid points, I'm not disputing most of
what you have said. I feel that this discussion is getting a bit off-track.

>From your various e-mails, you seem to be making the following points
(I'm paraphrasing, there are nuances, but I'm attempting to summarize):

1. We should minimize duplication of work between what we do here and
   other standards bodies.
2. Big standards bodies (like W3C, IETF, etc.) have corporate sponsors
   that may not have the publisher's best interests in mind.
3. The Microformats community is all-inclusive - "The Process", logic,
   reasoning and open debate should prevail. Most standards bodies
   have a great deal of red tape and preferential treatment for
   paying members.
4. Microformats are not a "throw everything at the wall and see what
   sticks" methodology. It is a very careful process that provides a
   minimum set of markup that solves 80% of publisher issues out there.

Personally, I agree with all of these statements. It is a very good
thing that the Microformats community follows them and holds them at its
core. We are not talking about changing any of that.

A very high level view of the Microformats creation process could be
proposed as thus:

1. See if you have a problem.
2. Gather examples of the problem you are attempting to solve.
3. Analyze examples.
4. If analysis deems necessary, create a draft Microformat.
5. Brainstorm and argue about names, usage - document via wiki.
6. Implement the Microformat, get feedback.
7. Create Microformat specification.
8. Evangelize the Microformat (especially, in other standards bodies).

hAudio is at step 5 right now. Keep in mind that it only solves 80% of
the publishing problems out there... which means that there are the 20%
that are still left without a solution and will seek that solution.

Why should we not weigh in with the people that are taking the time to
solve the other 20% of the problem? We have a great deal of knowledge in
this community and can help solve the problem completely by giving other
communities a very strong base to start from. If they don't listen to
us, we are no worse off than we are by doing nothing. If they do listen
to us, we can stop a plethora of useless semantic formats that are not
needed.

Another way to look at it is that we can talk other communities out of
creating a ton of different standards by proposing that they use the
Microformats semantic vocabulary as a starting point. If it solves their
problem, there is no need to create yet-another-semantic-format.

My arguments have nothing to do with changing the Microformats process -
they have to do with interacting with other communities. We can prevent
duplication of work in other locations by taking part in the discussion.
Or, we can do nothing and let the duplication of work knowingly occur.

I'm not claiming to have all of the answers. There certainly could be
down-sides to what is being proposed. However, those are not as bad as
not working with other communities.

I assert that, in general, collaborating with other communities will
strengthen the acceptance of Microformats. We plan to work with the RDFa
group to see if they can use hAudio. It is also an attempt to stop a
dearth of semantic formats that do the same exact thing. We're trying to
prevent what we fear is going to happen with RDFa.

-- manu