[uf-discuss] Re: [uf-new] Re: One issue per thread

[Ben Ward]

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