I am a very pro-wiki person; not just in microformats.org, but
everywhere else, too.
Also, moving this discussion to microformats-discuss, since this is
not discussing the creation of new microformats.
On 28 Feb 2009, at 07:49, Manu Sporny wrote:
The only problem with this approach is that it would take a very long
time to develop/implement.
I think I would class that problem as ‘fatal’ to an otherwise
beautiful vision of interoperating technologies. Nice try though ;-)
On 28 Feb 2009, at 09:47, Scott Reynen wrote:
For what it's worth, I've always considered email a tool for
discussion and the wiki a tool for documentation. But I don't think
that's worth much.
I somewhat agree, in that regardless of how the content is
compromised, the content of the wiki *must* function as a piece of
documentation. It's all the documentation we have, of specs,
brainstorms, and so forth. Certainly within this community it is
regarded as ‘truth’ — “wiki or it didn't happen”.
As such, no matter where discussion takes place, the knowledge from it
*must* go on the wiki, or it will be lost. If anything has dragged
this community down in the past, it's not being able to accurately
refer to past events. Using the wiki thoroughly is what prevents that.
The importance of using it as part of spec and related developments
here cannot be played down. I think it's well suited to editorially
driven content, which is the primary output of microformats.org.
* The problem with the lists is that if an issue discussed is not
documented on the wiki, you raise an ever increasing barrier to entry
for someone else to join that discussion, particularly as time passes
and the thread is buried under subsequent unrelated discussions.
* Conversely, the problem with the wiki is that a piece of
documentation can be spoiled by interjections of disagreement in every
other paragraph.
I find value in lists for humanising discussion too. Writing this
email I'm able to be a little more verbose with mannerisms and
language that, hopefully, means everyone appreciates me as a human
being rather than a Robot Overlord Admin Robot (additional robot for
benefit of awesome ‘ROAR’ abbreviation). I think that's important to
everyone here being able to work together, and the depersonalised
nature of documentation on the wiki is the opposite; highly-optimised
issues are vital for documentation, but bad for interacting in a
friendly manner with the people that contributed. (Issue documented: http://is.gd/laIn)
The result is a certain amount of duplicity to having lists. As I say,
I have no issue just ignoring list content that should go on the wiki.
But, somewhere it shifts a burden: Either to individuals who must
ensure their point of view is documented twice, or onto specification
editors to pull every discussion together. The latter editorial burdon
is not going to be acceptable in most cases; expecting a spec editor
to create permanent wiki documentation of every discussion is an
unreasonable waste of their time.
I'm not anti-email. But I support the idea that everyone contributing
must ensure their knowledge is documented. I don't have a clear idea
on precisely where the line between different sorts of discussion sits
to reduce duplication.
B
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
