wiki-better-than-email: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (added signature)
Line 16: Line 16:
** 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.
** 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.
** 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. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)
** 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. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)
** Another historical note: hAudio was developed almost entirely through e-mail and wiki edits.
** Another historical note: hAudio was developed almost entirely through e-mail and wiki edits. -- [[User:ManuSporny|ManuSporny]] 03:37, 28 February 2009 (UTC)


== reasons against ==
== reasons against ==

Revision as of 03:37, 28 February 2009

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

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

  • No, not always, not for all workflows, this is a false assertion. Wikis are excellent at capturing the state of the art and providing a mechanism for collaborative document editing. 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. Low-latency communication is best for that... for synchronous communication, IRC... for asynchronous communication, e-mail. -- ManuSporny 03:22, 28 February 2009 (UTC)

Here are a few:

reasons

  • s/n scaling. Not everyone is interested in every issue on every format.
    • No, but 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)
  • 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.
    • 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)
    • Another historical note: hAudio was developed almost entirely through e-mail and wiki edits. -- ManuSporny 03:37, 28 February 2009 (UTC)

reasons against

  • 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)
  • The Microformats wiki 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)
  • 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)

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:
    wiki_collaboration2.jpg
    • 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)

related