wiki-better-than-email

<entry-title>Wiki is better than email</entry-title>

The wiki works better than email for content (examples, issues, brainstorms etc.) for numerous reasons.

wikis in plain english

Here is a short video explaining how wikis work much better than email for collaboration, even for something as simple as planning a camping trip.

YouTube: Wikis in Plain English

reasons

Here are some reasons why wikis work better than email for microformats in particular, and in fact, for any kind of open standards development.

• s/n scaling. Not everyone is interested in every issue on every format.
• efficiency: reading current state vs deltas. You can read one wiki page to get the status/thread of an issue whereas with emails you often have to read thru numerous emails (and threads) and apply them like deltas/diffs in your head to understand where an issue etc. ended up.
• search/discoverability. search for the web/wikis works much better in practice than searching mailing lists (web search of email archives has no thread-smarts for example).
• public domain. Wiki contributions are required public domain, while in email there is no UI to enforce this, thus email should be use only "informatively" for notifications and never for capturing material of any substance.
• tradition. microformats have been documented on a wiki since their inception, as a result the wiki is the definitive resource for all matters microformats; not any of the mailing lists. The community has had a longstanding tradition preferring use of the wiki for content over email. We realize this is fairly novel for a standards community, as most standards communities are email-centric (e.g. W3C, IETF). However, for all the above reasons we believe using wikis for content is far superior to email and thus hope that other standards communities shift more of their activities to being web/wiki-based rather than email lists.
  • historical note: microformats have always been developed via public IRC + wiki since 2004 when Kevin Marks and Tantek Çelik first started researching/brainstorming/drafting microformats such as rel-license, vote-links, XOXO, hCard, hCalendar on the public Technorati Developer's Wiki and the Freenode IRC network. Brian Suda somehow discovered the Technorati Developer's wiki page for hCard, started editing it, and that's how he and Tantek Çelik met. The mailing-lists were not created until the microformats.org site was launched in mid 2005 and have always been considered secondary to the wiki and IRC channel.
    • exception: hAudio was developed almost entirely through e-mail and wiki edits. -- ManuSporny 03:37, 28 February 2009 (UTC)

additional documentation

• See the book http://www.wikinomics.com/ for more details and explanations on how wikis are more efficient than email for a variety of workflows.
• This picture helps illustrate one of many scenarios - and though we are not sending word documents, the point is, that iterating content through email is far less efficient than iterating content on a wiki:
  
  • I'm not arguing for an all-or-nothing approach. I think we should discuss on IRC/e-mail, form a consensus of some kind, and then record that consensus on the wiki. The community should allow people to use whatever method works for them, rather than forcing a method of communication and issue resolution onto the community. -- ManuSporny 03:22, 28 February 2009 (UTC)

FAQ

why is IRC okay but not email

Why is IRC okay, but e-mail not okay? In other words, why is a synchronous method of communication with a small number of contributing individuals accepted, but an asynchronous method of communication with a large number of contributing individuals not accepted as a method of resolving issues? If we are to achieve broad consensus, I would expect that we'd chose the latter over the former. -- ManuSporny 03:22, 28 February 2009 (UTC)

• People can easily choose to be on IRC or not when it is convenient for them to participate in discussions or not and that aspect of easy in/out control is very important. Email on the other hand, is quite hard to subscribe/unsubscribe when you have time to handle discussions or don't.
• IRC is also discouraged for actual content, again, deferring to the wiki for capturing content and follow-ups.
• Broad consensus is better achieved via the wiki, which is much more readable (see efficiency reason above), and discoverable (see search reason above) by more people.

what if you cannot find issues or arguments on the wiki

The Microformats wiki {sometimes} makes it difficult to understand the arguments behind a large number of the items on a wiki. Sometimes it is best to ask the mailing list where to start, or the reasoning behind an issue rather than state something that you have no idea is true or not on a wiki. -- ManuSporny 03:22, 28 February 2009 (UTC)

• If a simple search of the wiki fails to quickly reveal an answer to an issue, then yes, asking on an email list is reasonable. Responses to such queries should include URLs to answers on the wiki, hopefully with improved discoverability to increase findability of similar issues in the future.

what if you do not have time to be on IRC

Some of us do not have the time to sit around in an IRC channel. Some of us do our communication in batches because that is most efficient for us. Constant interruption or temptation to get involved in a discussion is more prevalent in IRC than it is in e-mail. I can shut off my e-mail client and not worry that I've missed something, I can't necessarily do the same with IRC. -- ManuSporny 03:22, 28 February 2009 (UTC)

• The mailing-lists are appropriate for notification/queries regarding one or more issues or other major changes, as long as such messages include URLs to the relevant content on the wiki, rather than the content itself. IRC should not necessarily be needed for this.
• In addition, there are IRC archives which can be checked once in a while, rather than having to be on IRC at all times.

responses to issues

controversial discussion does not lead to edit wars

Issue: Discussing issues that are highly controversial are bad to do via a wiki because they lead to edit wars and subsequent banning of individuals, as this community has experienced. -- ManuSporny 03:22, 28 February 2009 (UTC)

• This is false. Controversial issues can result in noise in whatever medium they are discussed, email, wiki etc.
• Edit wars are the result of bad wiki behavior, not controversial issues, where relevant content is deleted or reverted without giving good reason, or the same edits are made repeatedly.
• Bad wiki behavior (see how-to-play for good behavior) resulted in the banning of individuals, which has happened independent of controversial issues.

email is not better for controversial issues

Low-latency communication is best for that {for controversial issues}... for synchronous communication, IRC... for asynchronous communication, e-mail. -- ManuSporny 03:22, 28 February 2009 (UTC)

• All issues, whether controversial or not, are better captured on a wiki for future documentation, with permalinks to reduce the probability that the same issue is re-raised (since the previous issue and resolution can be easily referenced by permalink, and often better discovered by search.)
• If it seems like differences of opinion on an issue are unresolvable, then a wiki can serve to summarize opinions one way or the other (via +1 / -1 / 0 {username} surveys) so that at least the controversy can be recorded rather than incessant "email-ping-pong" where emails simply just go back and forth and no progress is made.

email may provide only the illusion of consensus

There needs to be a forum other than IRC (synchronous method of communication) for discussion of these topics. E-mail is nice because it is asynchronous and allows broad consensus to be reached before moving forward. Not all of us have the luxury of being connected to IRC at all times. -- ManuSporny 03:22, 28 February 2009 (UTC)

• In practice e-mail does not allow for broad consensus, only the illusion thereof. The problem is that the overwhelming amount of email noise (on issues or formats they may not be interested in) typically results in people simply paying less attention and eventually leaving the mailing lists. Absence of response is not an indicator of agreement or certainly not consensus.
• Much better to capture the actual issues/responses/opinions on the wiki and not flood the mailing lists.

changing the ways a community works requires justification

Tradition, in and of itself, is not a valid reason for doing something. We need an asynchronous method of communication and IRC doesn't work for some of us. Decisions shouldn't be made by a select few that hang out in an IRC channel all day, this is not how you reach consensus. -- ManuSporny 03:22, 28 February 2009 (UTC)

• The burden of proof is on *changing* how a community works, by default, it makes sense for a community to keep doing what works for that community.
• The microformats community started with the wiki as central practice, and other methods (including IRC) as merely notification or for very brief discussions that if meaningful were captured on the wiki. In comparison the email-centric discussions in other standards communities (e.g. W3C, IETF) has long been overwhelmed by trolls and other bad actors (e.g. www-style and www-html) thus significantly reducing both its utility, and the desire for people of any level of expertise to actually attempt to participate.

issues needing answers

documentation-style of wiki removes human-touch, increases animosity in disagreements

• The wiki is a vital documentation tool, and we should strive that it be written as a quality piece of documentation of issues and specs. But, in forcing discussion into this format, discussion is blunted, becomes harsh and naturally gravitates toward polarized discussion. This is important for documenting the issue; to distil issues to their core, but this is bad for building friendly, amicable relationships between people trying to work together on microformats. --BenWard 23:32, 28 February 2009 (UTC)

related

• mailing-lists
• how-to-play
• put-it-on-the-wiki