Re: [uf-new] The Process (was: hAudio case study)

2007-09-13 Thread Tantek Çelik 
On 9/13/07 1:10 AM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:

> In message <[EMAIL PROTECTED]>, Tantek Çelik
> <[EMAIL PROTECTED]> writes
> 
>> "Document the implicit schemas that the content examples imply."
>> 
>> Every word in that sentence matters.
> 
> On the contrary: "implicit" is redundant.

Quite.

> The alternative:
> 
>   "Document the schemas implied by the content examples."
> 
> reads better.

Agreed. Updated process page. Thanks! Tantek


___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] The Process (was: hAudio case study)

2007-09-13 Thread Andy Mabbett 
In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

>"Document the implicit schemas that the content examples imply."
>
>Every word in that sentence matters.

On the contrary: "implicit" is redundant. The alternative:

"Document the schemas implied by the content examples."

reads better.

-- 
Andy Mabbett

___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] The Process (was: hAudio case study)

2007-09-12 Thread Tantek Çelik 
On 9/12/07 8:53 AM, "Scott Reynen" <[EMAIL PROTECTED]> wrote:

> On Sep 12, 2007, at 9:24 AM, Michael Smethurst wrote:
> 
>> Would it not be better for ufs to standardise markup based on the
>> domain
>> model than waste time wading through flakey html? [Perhaps]
> 
> I don't believe looking at current publishing practices is a waste of
> time at all.  Much the opposite, I think it's the most important part
> of the process.  Domain models that don't account for what is
> published on the real web tend to be less useful on the real web.

You're both right.

Michael, the "gather real world examples" for analysis step of the process
is specifically focusing on the *data* published, and NOT the patterns (or
lack thereof) of markup.

This is why the *-examples step says:

"Document the implicit schemas that the content examples imply."

Every word in that sentence matters.  *implicit* schemas, that is, you have
to look at the *content* of the examples and note what abstract
notions/fields/properties that people are publishing.  That's very
deliberate in that it is MUCH less important (if at all) what flakey html is
being used.

Scott is right in that analysis of current publishing practices helps us
prioritize what problems are worth solving (i.e. there is already
demonstrated incentive for people to publish such information) as opposed to
what problems are purely theoretical, or wishful thinking (e.g. if only
everyone would publish metadata ABC then we could build applications XYZ).

In fact, I have seen this question asked (or this step of the process
misinterpreted regarding example data vs example markup) sufficient times
that I think this merits documentation as an FAQ.  Might as well start with
this one.



Thanks,

Tantek

___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] The Process

2007-09-12 Thread Tantek Çelik 
On 9/12/07 9:55 AM, "Mary Hodder" <[EMAIL PROTECTED]> wrote:

> I have to second this one as well.
> 
> In fact I blogged about this some time ago:
> 
> http://napsterization.org/stories/archives/000583.html
> 

Mary and Manu,

Thank you both (again in your case Manu) for your frank comments, and more
importantly...

for being here and volunteering your valuable time participating in these
discussions.

In addition, for doing so in an objectively critical fashion.  You are both
setting good examples for the community, and your persistence and continued
civility are an inspiration.

> nicely of course, but the reality was that for 2 years, I got slammed
> and treated badly by the folks who started it, and then once I made
> them sit down and explain the process, I was able to follow the
> rules.  But it was harsh.  Many people commented privately to me
> after the two blog posts on process that it helped them a lot because
> they had the same experience.
> 
> I don't see why hazing helps the process.  You can have high
> standards without being mean.
> 
> mary

You're absolutely right Mary, any such hazing is wrong, and for any and all
part that I played in that, I apologize and take full responsibility.
Thanks for sticking with us through our growing pains (both personally and
as a community).

We can and should have high standards (in both senses) without being mean.

Thanks,

Tantek

___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] The Process

2007-09-12 Thread Mary Hodder 

I have to second this one as well.

In fact I blogged about this some time ago:

http://napsterization.org/stories/archives/000583.html

nicely of course, but the reality was that for 2 years, I got slammed  
and treated badly by the folks who started it, and then once I made  
them sit down and explain the process, I was able to follow the  
rules.  But it was harsh.  Many people commented privately to me  
after the two blog posts on process that it helped them a lot because  
they had the same experience.


I don't see why hazing helps the process.  You can have high  
standards without being mean.


mary

On Sep 12, 2007, at 8:50 AM, Frances Berriman wrote:


On 12/09/2007, Manu Sporny <[EMAIL PROTECTED]> wrote:

I think we should call it what it is:

"The Accepted Limitations of Microformats"


Yeah, that would work.


That harshness has also sent good people elsewhere... you don't  
have to

be harsh to prevent frivolous formats or unwanted behavior. In fact,
this goes against the Microformats "be nice" principle.



I agree - and I think that these new pieces of documentation will help
everyone be more supportive rather than exclusive in any way.


--
Frances Berriman
http://fberriman.com
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new


___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] The Process (was: hAudio case study)

2007-09-12 Thread Mary Hodder 

I'd second that.

Even if users are just plopping blobs of data that is recognizable to  
humans when presented in a blog, but unstructured, we can still make  
sense

of those blobs and structure them.

Seeing what people want to do makes more sense that imposing from on  
high.  That is typical of standard's bodies and in practice not often  
followed.


For an example of this, where some standards from on high, are  
compared to some standards that emerged, in video metadata, see this:


http://microformats.org/wiki/media-metadata-examples#Comparison_Table

mary

Mary Hodder
Founder:  Dabble
Blogs:  Dabble.com/blog
Napsterization.org/stories

On Sep 12, 2007, at 8:53 AM, Scott Reynen wrote:


On Sep 12, 2007, at 9:24 AM, Michael Smethurst wrote:

Would it not be better for ufs to standardise markup based on the  
domain

model than waste time wading through flakey html? [Perhaps]


I don't believe looking at current publishing practices is a waste  
of time at all.  Much the opposite, I think it's the most important  
part of the process.  Domain models that don't account for what is  
published on the real web tend to be less useful on the real web.


--
Scott Reynen
MakeDataMakeSense.com


___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new


___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] The Process

2007-09-12 Thread Manu Sporny 
Frances Berriman wrote:
> On 12/09/2007, Manu Sporny <[EMAIL PROTECTED]> wrote:
>> I think we should call it what it is:
>>
>> "The Accepted Limitations of Microformats"
> 
> Yeah, that would work.

I have created the wiki page, everyone please feel free to note issues
and add other sections on the page:

http://microformats.org/wiki/accepted-limitations-of-microformats

-- manu
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] The Process

2007-09-12 Thread Manu Sporny 
Brian Suda wrote:
> Edward Deming set-out 14 points.
> http://en.wikipedia.org/wiki/W._Edwards_Deming#Deming.27s_14_points
> 
> #11. Eliminate numerical goals, numerical quotas, and management by
> objectives. Substitute leadership.

With all due respect, Brian... we're back to hand-waving... which is
frustrating. "Substitute leadership" is vague... what kind of leadership
should we substitute? Authoritarian? Benevolent dictator? Constitutional
Republic? Mob Rule? Should the "leadership" be of the Microformats
author, or of somebody in The Cabal? I agree with you in philosophy...
but we need some more specific guidelines.

When we don't have clearly defined goals, it's difficult to know if
we're getting anywhere. We don't have to use hard numbers, but we need
something more specific than what you have just outlined.

Why can't we agree to a simple set of guiding principles of when a
Microformat should be considered? For example:

A Microformat should be considered if:

1. There are more than 100 websites that mark up the type of data in
   the problem statement of the proposed Microformat.

A Microformat should be created if:

1. There are more than 1000 websites that mark up the type of data in
   the problem statement of the proposed Microformat.

> Quantity does not equate quality!

I agree with you in principle, but I think the Microformats community is
botching the execution on this.

> The other thing that might help the example gathering is if more
> people were involved. If one person goes out and finds 200 examples,
> but no one else is helping, then is there really a reason to keep
> pushing the process?

Yes! They have found 200 examples of the data in the wild... that shows
that the data exists out there! If they can find 200 examples, that
probably means that there are many more websites that contain that data.

You say that we shouldn't use numbers... but now you're saying that the
number of people working on a Microformat is relevant?

> Microformats work best when there is an "itch to
> scratch", not a personal issue to solve. 

What constitutes an "itch to scratch"? I'd say that the number of
websites that are publishing the data in a Microformat Problem Statement
 is very relevant. I don't think anybody would argue that if we could
find 10,000 websites publishing a certain type of data, that we
shouldn't consider a Microformat for those websites.

> Many formats have collected
> many, many examples, but there is just no interest at the current time
> to move it forward. Just because things can be checked on the process
> list doesn´t mean it should. This is the current state of the
> media-info, people did some homework, and saw there wasn´t community
> interest.

Again, with all due respect Brian, I disagree completely. As you can
already tell, I'm not a very big fan of goals that can't be measured.
So, here is how I'm proposing that we measure "interest in a Microformat".

Interest in a Microformat should not be measured at the beginning, but
over the lifetime of the Microformat. From beginning to the point of the
final draft. This can be measured quite easily by looking at the number
of contributors on all of the pages for each Microformat, and the number
of people that took part in the discussion on the mailing list and
normalizing that number by the number of months the format has been
active. Here's an analysis that I've been doing in my spare time of how
this applies to some of the current Microformats:

hCard  contributors: 263 normalized (26 months): 10.11
   authors :   2

hCalendar  contributors:  85 normalized (26 months):  3.27
   authors :   2

hAtom  contributors:  62 normalized (22 months):  2.81
   authors :   3

hResumecontributors:  54 normalized (20 months):  2.70
   authors :   5

hAudio contributors:  35 normalized ( 6 months):  5.83
   authors :   2

hReviewcontributors:  53 normalized (26 months):  2.03
   authors :   6

VoteLinks  contributors:  23 normalized (26 months):  0.88
   authors :

xFolk  contributors:  12 normalized (26 months):  0.46
   authors :   1

With these examples above, we can see several patterns. hAudio has a
fairly high "normalized interest level"... but it has been proposed that
we not move that forward until there is "more interest". It's interest
level is higher than all the other Microformats listed, except for hCard.

This is part of what is frustrating - even when we present data like
this, it is sometimes ignored by the Microformats administration.

> --- this is also why POSh has been pushed more. We have also been
> adding things to the process, like "first make sure you site is POSH,
> it validates and uses existing microformats". Then and ONLY then
> should more people be allowed to propose new formats. This would also
> FORCE an understanding of some of the more basic things befor

Re: [uf-new] The Process

2007-09-12 Thread Frances Berriman 
On 12/09/2007, Manu Sporny <[EMAIL PROTECTED]> wrote:
> I think we should call it what it is:
>
> "The Accepted Limitations of Microformats"

Yeah, that would work.


> That harshness has also sent good people elsewhere... you don't have to
> be harsh to prevent frivolous formats or unwanted behavior. In fact,
> this goes against the Microformats "be nice" principle.
>

I agree - and I think that these new pieces of documentation will help
everyone be more supportive rather than exclusive in any way.


-- 
Frances Berriman
http://fberriman.com
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] The Process (was: hAudio case study)

2007-09-12 Thread Scott Reynen 

On Sep 12, 2007, at 9:24 AM, Michael Smethurst wrote:

Would it not be better for ufs to standardise markup based on the  
domain

model than waste time wading through flakey html? [Perhaps]


I don't believe looking at current publishing practices is a waste of  
time at all.  Much the opposite, I think it's the most important part  
of the process.  Domain models that don't account for what is  
published on the real web tend to be less useful on the real web.


--
Scott Reynen
MakeDataMakeSense.com


___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] The Process (was: hAudio case study)

2007-09-12 Thread Michael Smethurst 



On 12/9/07 10:58, "Frances Berriman" <[EMAIL PROTECTED]> wrote:

> On 11/09/2007, Manu Sporny <[EMAIL PROTECTED]> wrote:
>> To us it seemed like this was an unfair argument that was thrown out
>> there whenever we disagreed with somebody that was "more senior" in the
>> community. The argument came across as "Well, you're just not analyzing
>> the correct sites - otherwise, you'd see my point... so why don't you go
>> and analyze more examples until you can prove us right". The person
>> making the previous statement doesn't have to do anything to defend
>> their viewpoint and the person creating the Microformat now has to spend
>> tens of hours collecting more examples.
>> 
>> In the end, it made hAudio better - but at the expense of frustrating
>> the Microformat authors.
> 
> Yeah - that frustration is understandable, but I don't think it's easy
> to say at the start of a project how much (# wise) is enough.  Perhaps
> that should be iterative itself... go off and find 30, do you have
> conclusive evidence... if not, find another 20..?  I wonder if review
> got by with less, because there's just less data out there already?
> The general idea is just to get "as many as you can" but that's almost
> like saying "how long is a piece of string", I agree.
> 
> We'll have to give this one some more thought.  Does anyone else have
> good ideas about how to iron this out?


Just to chip in here - I've never been entirely convinced that auditing
sites for markup standards is all that beneficial

If you were proposing a tracklist uf you could look at:

Bbc.co.uk/radio1

And find text with line breaks

If you were proposing a recipe uf you could look at:

Bbc.co.uk/food

And find text with line breaks

Same goes elsewhere for news, travel etc. And not just at the bbc. More or
less everywhere I've worked has had legacy markup produced by legacy
systems. 

Look outside of html and the same holds. I was recently looking through:

http://gonze.com/playlists/playlist-format-survey.html

For tips on music markup and every one was a mess of proprietary, legacy
markup

Would it not be better for ufs to standardise markup based on the domain
model than waste time wading through flakey html? [Perhaps]


http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal 
views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on 
it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] The Process

2007-09-12 Thread Manu Sporny 
Frances Berriman wrote:
>> We felt that the community wasn't very upfront about these shortcomings
>> of Microformats. We didn't even know that the community understood that
>> Microformats had these shortcomings until we were 7 months into the
>> process. I think we as a community should be very honest about what one
>> can't do with Microformats.
> 
> That's fair.  I think it would be very beneficial to be upfront about
> this.  After all, it'll save everyone time in the long run.  I think
> devoting a page to "are microformats for you or your project?" would
> be worthwhile.

I think we should call it what it is:

"The Accepted Limitations of Microformats"

> It's rigorous, but yeah, I agree... any effort to make it less
> meat-grinder like and more "super fun adventure" is a good thing.  But
> at the same time, it's been that harsh to prevent frivolous formats
> being created.

That harshness has also sent good people elsewhere... you don't have to
be harsh to prevent frivolous formats or unwanted behavior. In fact,
this goes against the Microformats "be nice" principle.

-- manu

___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] The Process (was: hAudio case study)

2007-09-12 Thread Scott Reynen 

On Sep 12, 2007, at 4:33 AM, Brian Suda wrote:


Quantity does not equate quality!


Right.  I think we tend to get caught up in whether or not the  
numbers are convincing to our fellow community members, and lose  
track of the important question: whether or not the end result is  
convincingly useful for publishers.  Most publishers don't care if  
the examples we collect are statistically significant; they only care  
if it looks useful for them.  More examples helps with that goal, but  
there's not really quantifiable finish line.  I suspect much of this  
problem could be resolved with better scope definitions.  When  
someone says "these examples don't cover my needs," rather than  
collecting more examples to prove those needs are edge cases, we  
could be referring back to the scope definition and saying "sorry,  
your needs are outside the defined scope of this microformat."  But  
that only works when the scope is very clearly defined in advance.


--
Scott Reynen
MakeDataMakeSense.com


___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] The Process (was: hAudio case study)

2007-09-12 Thread Brian Suda 
On 9/12/07, Frances Berriman <[EMAIL PROTECTED]> wrote:
> Yeah - that frustration is understandable, but I don't think it's easy
> to say at the start of a project how much (# wise) is enough.
> The general idea is just to get "as many as you can" but that's almost
> like saying "how long is a piece of string", I agree.
>
> We'll have to give this one some more thought.  Does anyone else have
> good ideas about how to iron this out?

--- it is NEVER a good idea to use number quotas. All they do is mask
potential shortcomings. If you say that you need 10 examples, they
only the first 10 will ever be looked at. If you say you need 50, but
only find 45, then 5 additional will be created "in your favour"
purely to meet the quota. If you set it at 500 then it is an
unachievable goal.

Edward Deming set-out 14 points.
http://en.wikipedia.org/wiki/W._Edwards_Deming#Deming.27s_14_points

#11. Eliminate numerical goals, numerical quotas, and management by
objectives. Substitute leadership.

At the end of the day, we should avoid "voting" on issues and examples
purely by the numbers and base it more on experience, leadership and
good reasoning, NOT because 25 of my 27 examples show this... because
someone else can go out and (create or document) 50 more to counter
the previously gathered examples.

IMHO numeric quotas (much like those voting polls where you can vote
as many times as you want) do not reflect the truth, but instead a
meter to which people do as little work as possible to achieve the
goal and then say "but i did what you told me", even though it might
be crap.

Quantity does not equate quality!

The other thing that might help the example gathering is if more
people were involved. If one person goes out and finds 200 examples,
but no one else is helping, then is there really a reason to keep
pushing the process? Microformats work best when there is an "itch to
scratch", not a personal issue to solve. Many formats have collected
many, many examples, but there is just no interest at the current time
to move it forward. Just because things can be checked on the process
list doesn´t mean it should. This is the current state of the
media-info, people did some homework, and saw there wasn´t community
interest. This is the perfect opportunity to take a step back an use
POSH for awhile, test it and report back with results. No need to
hammer on the process.

> It's rigorous, but yeah, I agree... any effort to make it less
> meat-grinder like and more "super fun adventure" is a good thing.  But
> at the same time, it's been that harsh to prevent frivolous formats
> being created.

--- this is also why POSh has been pushed more. We have also been
adding things to the process, like "first make sure you site is POSH,
it validates and uses existing microformats". Then and ONLY then
should more people be allowed to propose new formats. This would also
FORCE an understanding of some of the more basic things before a
proposal and frustration of "not understanding".

-brian

-- 
brian suda
http://suda.co.uk

___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] The Process (was: hAudio case study)

2007-09-12 Thread Frances Berriman 
On 11/09/2007, Manu Sporny <[EMAIL PROTECTED]> wrote:
> To us it seemed like this was an unfair argument that was thrown out
> there whenever we disagreed with somebody that was "more senior" in the
> community. The argument came across as "Well, you're just not analyzing
> the correct sites - otherwise, you'd see my point... so why don't you go
> and analyze more examples until you can prove us right". The person
> making the previous statement doesn't have to do anything to defend
> their viewpoint and the person creating the Microformat now has to spend
> tens of hours collecting more examples.
>
> In the end, it made hAudio better - but at the expense of frustrating
> the Microformat authors.

Yeah - that frustration is understandable, but I don't think it's easy
to say at the start of a project how much (# wise) is enough.  Perhaps
that should be iterative itself... go off and find 30, do you have
conclusive evidence... if not, find another 20..?  I wonder if review
got by with less, because there's just less data out there already?
The general idea is just to get "as many as you can" but that's almost
like saying "how long is a piece of string", I agree.

We'll have to give this one some more thought.  Does anyone else have
good ideas about how to iron this out?


> We felt that the community wasn't very upfront about these shortcomings
> of Microformats. We didn't even know that the community understood that
> Microformats had these shortcomings until we were 7 months into the
> process. I think we as a community should be very honest about what one
> can't do with Microformats.

That's fair.  I think it would be very beneficial to be upfront about
this.  After all, it'll save everyone time in the long run.  I think
devoting a page to "are microformats for you or your project?" would
be worthwhile.


> I think the best thing that the community could do at this point
> regarding the creation of new Microformats is to smooth and refine The
> Process. It is not very easy to grok until you've been through it... and
> after you go through the New Microformat meat grinder, you really don't
> want to do it again. :)

It's rigorous, but yeah, I agree... any effort to make it less
meat-grinder like and more "super fun adventure" is a good thing.  But
at the same time, it's been that harsh to prevent frivolous formats
being created.

That document is a great start.  I still have issues with using "POSH"
over simply saying "create good, semantic HTML", but I think I already
got ignored over that one. :)  Simple language and clearly defined
steps is a reasonable and achievable goal.


-- 
Frances Berriman
http://fberriman.com
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] The Process (was: hAudio case study)

2007-09-11 Thread Manu Sporny 
Frances Berriman wrote:
> I imagine it will be valuable as a primer for those interested in
> creating some type of microformat (or wondering if microformats are
> indeed for them) and maybe how the process works.

Good, as that is one of the goals of the document :)

> Talking of... I note that one of your encountered problems was with
> the process itself.  Was it just the shifting/vague targets that were
> the main problem, or do you have others? 

Shifting/vague targets was the most frustrating part of the process. The
idea that Microformat authors now are being held to a different standard
than the ones that created hCard, hCalendar and hReview.

For example, once we had collected around 30 examples for hAudio, we
thought we had enough. After all, review-examples (hReview) only has 17
examples collected. However, some on the list kept going on about
collecting more examples before a decision could be made. After we had
50 examples, the same issue was brought up that we needed more examples.
Thus we went overboard and collected over 100 examples.

To us it seemed like this was an unfair argument that was thrown out
there whenever we disagreed with somebody that was "more senior" in the
community. The argument came across as "Well, you're just not analyzing
the correct sites - otherwise, you'd see my point... so why don't you go
and analyze more examples until you can prove us right". The person
making the previous statement doesn't have to do anything to defend
their viewpoint and the person creating the Microformat now has to spend
tens of hours collecting more examples.

In the end, it made hAudio better - but at the expense of frustrating
the Microformat authors.

The other issue seemed to deal with being surprised by things that you
couldn't do with Microformats, as the wiki doesn't necessarily focus on
what you can't do with a Microformat. For example: overlapping
Microformats is a problem, so is the lack of namespaces, global
identification on pages, and the scoping issue outlined in the hAudio
case study.

We felt that the community wasn't very upfront about these shortcomings
of Microformats. We didn't even know that the community understood that
Microformats had these shortcomings until we were 7 months into the
process. I think we as a community should be very honest about what one
can't do with Microformats.

In an attempt to address these issues, I've authored the following
document (with help from Martin McEvoy and Brian Suda):

http://microformats.org/wiki/how-to-start-a-new-microformat

The document attempts to outline The Process more clearly and in a
step-by-step manner. We found ourselves missing steps or not
understanding what needed to be accomplished at certain points in the
process.

Our general view of The Process when going through it the first time was
that it seemed to be being made up as we went along. There are several
community members that have their own take on each step of the process
and their advice sometimes conflicted with what other members of the
community advised us to do. In short - there didn't seem to be a
consensus on the process, which led to frustration when attempting to
get to the next step.

I think the best thing that the community could do at this point
regarding the creation of new Microformats is to smooth and refine The
Process. It is not very easy to grok until you've been through it... and
after you go through the New Microformat meat grinder, you really don't
want to do it again. :)

-- manu
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] The Process (was: hAudio case study)

2007-09-08 Thread Manu Sporny 
Tantek Çelik wrote:
>> http://wiki.digitalbazaar.com/en/haudio-case-study
> 
> Manu, that's an exceptionally thorough write-up.

Thanks :). One of the goals was to lay some more ground work for others
that may want to create new Microformats or contribute to semantic web
projects, but didn't know where to start.

> I've captured the issues you noted (or at least a pointer to them) here:
> http://microformats.org/wiki/process-issues

Great! That is very helpful as it makes us feel like issues with The
Process are being heard outside of the mailing list.

I've added an issue that is subtly different from #3:

# 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.

In an attempt to address this issue, Brian Suda and I have been working
on a New Microformat HOW-TO document. It gives a straightforward set of
steps for anybody that wants to create a new Microformat to follow:

http://microformats.org/wiki/how-to-start-a-new-microformat

The last three steps aren't completed yet, it's a work in progress that
I hope will be completed later this month. The goal of the document is
to not only outline the steps, but the logic behind each step.

I hope the document will do the following:

 1. Give newcomers to Microformats a straight-foward, step-by-step
guide on how to create a new Microformat.
 2. Explain the logic behind each step, in an attempt to counter-act the
notions that a "Cabal" is in charge of Microformats. If we can all
agree on the logic behind each step of The Process, then I hope that
we can improve cohesion in this community.

Thoughts/feedback?

-- manu
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new