Re: [syndication] RSS 0.94 - managing specifications

["Mark Nottingham" <mnot@mnot.net>]

I think I agree with others that if I were coordinating the development of
RSS 0.94, I would have a different style. However, Dave is managing this
development, as is his right.

It's fairly well-recognized that doing this kind of work needs some kind
of control to ensure quality, keep the bad ideas out, and make sure that a
coherent spec is delivered; specification by true democracy is madness.
Often, this is done with a group of people who meet some criteria
(technical ability, sponsorship, etc.) arriving at consensus; this is what
the RSS 1.0 group is doing, with voting procedures, etc.

However, it's just as legitimate for this control to be asserted by an
individual; this is the 'benevolent dictator' approach. Here, the manager
chooses what is included in the final product, and much of the
communication about it happens privately (as there's no need to prove
consensus was achieved).

This method can be very successful (often, more so than a consensus
process), if the manager is wise, has an excellent mastery of the subject
at hand, and has a vision. It also puts the onus on the manager to deliver
a specification that's relevant to the market, technically excellent, and
easy to understand (all of these are functions that are broken out into
formal roles like "Requirements and Use Cases", "Technical Review" and
"Editor" in a consensus process).

I think it's fascinating that both approaches are being applied to the
same problem domain concurrently*. Both have been successful and have
failed in the past. Ultimately, the market will decide which is better.

For full transparency, I would like to see both specifications clearly
labeled with the approach that was used in their creation, so that people
know how it was arrived at, and how future revisions are going to be
managed. While licenses are an appropriate place to put the legal
language, it would be good to see this written out in more human (humane?)
language somewhere near the top of the specifications. Dave, any thoughts?
RSS 1.0 guys, I see a hint of this in the spec, but it would be good to
spell it out, and/or offer a direct link to your management policy.

Regards,


* I find it especially interesting considering that the approaches to
managing the specification are mirrored in their extension mechanisms;
i.e., all-at-once version revision vs. namespace extension.

--
Mark Nottingham