[admin] [EoT request] was Re: [uf-new] Use of img in rel-*(withanalyzed data)

[Joe Andrieu]

Tantek Ç elik wrote (Sunday, July 15, 2007 5:49 PM):
> On 7/15/07 3:58 PM, "Joe Andrieu" <joe at andrieu.net> wrote:
> 
> > I would also like to see some of the back-and-forth move to 
> concrete 
> > proposals on the wiki.
> 
> Thanks Joe.
> 
> 
> > Including your own points, Tantek.
> 
> I'm wiking everything I can, in priority order per my to-do 
> list on the
> wiki:
> 
> http://microformats.org/wiki/to-do#Tantek
> 
> I encourage you to add a section for yourself on the to-do 
> page as well for the things you want to get done in the 
> microformats community.

Tantek,

I have been specifically requested by Rohit /not/ to put my issues on the wiki. And since he has removed them, spoken with me
personally, and promised some sort of progress behind the scenes, I will continue to respect that.

However, until that progress is visible and my concerns about governance, ownership, and IP are resolved satisfactorily, I will
continue to refrain from substantial contributions to the wiki, just as I will be careful about using uF in my own work.  Where I
can, I will contribue in email discussions and participate in the community with hopes that it will eventually evolve from a private
cabal of individual uF owners to a true open source community.

> > You yourself have acknowledged the lack of documentation 
> before. As a 
> > result, I'd say the burden of proof exists, as usual, for everyone 
> > making a case.
> 
> It is not the same for everyone no.  There is what is 
> established and thus works today, and there are proposals for 
> change.  The proposals for change have burden of proof.  The 
> documentation at this point for those that actually worked on 
> it is a matter of historical documentation, not process.
> 
> > And in my opinion, it is even greater for
> > those defending the status quo, if simply because the 
> incumbant have 
> > the benefit of possession of the standard.
> 
> We will simply have to choose to disagree on this point then.
> 
> The burden of proof is always on those who wish to change or 
> modify what already "works" to a great extent today.  This 
> principle is actually in use all over microformats, such as 
> re-using existing implied schemas and looking at existing 
> widely interoperable standards as a basis for vocabulary for 
> microformats.
> 
> Thus it could be said that a key principle of microformats in 
> general "doing what already works" (i.e. re-use) is greatly 
> valued over "changing everything and starting from scratch" 
> (i.e. re-invention).


Respectfully, please avoid hyperbole if you would like to have a constructive conversation. Nobody has suggested "changing
everything and starting from scratch".  It would be easier to do that outside of microformats.org if it were appropriate.

Based on my own experience and informal research of significant cultural, historical, and philosophical essays on the issue of
authority, I reject the argument that things should stay the same just "because that's the way we've always done it".  Time and
again, questioning the status quo has repeatedly generated improvements, even when catalytic of disruptive change.

If there are documented and well-found reasons for a standing decision, the simple response is to point to those reasons and suggest
to those who would suggest something new, that they address those reasons explicitly in any new proposals.  Clearly articulated and
well argued foundations for decisions can stand the test of time... but that fact should not be taken as license to reject
suggestions out of hand simply because they are new or "not invented here".  The foundation of technical authority must lie in the
merit of the technology, not in the legacy of authorship.

Just because a handful of smart guys documented semantic HTML representations of vCard and iCalendar does not make those
specifications "holy" or unchangeable.  This community has severe limitations on growth, especially in the area of versioning. As
respectfully as possible, I suggest it is largely because the original authors often react defensively when changes are proposed.
Supporting that emotional dynamic, there is no change control process.  Either the original author deems it appropriate and updates
the spec--such as when you added "places" to the semantics of vCard--or the original authors fight tooth and nail until
well-intentioned suggestions are bludgeoned to death.  In contrast, new proposals go through a brutal review process where every
last detail is examined and debated. For those proposals that survive the gauntlet, the outcome promises to be a solid, robust
microformat.

Perhaps it would be more constructive if proposed changes to existing standards had some sort of agreed upon process for
documentation, evaluation, and acceptance/rejection.

-j

--
Joe Andrieu
SwitchBook Software
http://www.switchbook.com
joe at switchbook.com
+1 (805) 705-8651