Wiki is better than email

Le wiki fonctionne mieux que l'e-mail pour le contenu (exemples, problématiques, brainstorm, etc.) pour bon nombre de raisons.

wikis en langage clair (anglais)

Voici une vidéo courte résumant comment les wikis fonctionnent mieux que l'e-mail pour la collaboration, même pour quelque chose d'aussi simple que d'organiser un voyage en camping.

YouTube: Wikis in Plain English

raisons

Voici quelques raisons pour lesquelles les wikis fonctionnent mieux que l'e-mail pour les microformats en particulier, et en fait, pour tout type de développement de standards ouverts.

• rapport signal bruit. Tout le monde n'est pas intéressé par chaque problématique sur chaque format.
• efficacité : lire l'état actuel vs deltas. Vous pouvez lire une page wiki pour avoir le statut/fil de discussion sur une problématique tandis qu'avec les emails, vous devez souvent lire de nombreux emails (et fils de discussions) et les appliquer comme des deltas/diffs dans votre tête pour comprendre où s'est terminée la problématique, etc.
• recherche. la recherche sur le web/wikis fonctionne bien mieux en pratique que la recherche dans les listes de discussions (la recherche web sur les archives d'emails n'a par exemple pas de recherche sur les fils).
• domaine public. les contributions wiki sont requises pour être dans le domaine public, alors que dans l'email il n'existe pas d'interface-utilisateur pour renforcer ça, de ce fait l'email devrait être utilisé uniquement "informaivement" pour les notifications et jamais pour le contenus à comprendre de quelque substance.
• tradition. les microformats ont été documentés sur un wiki depuis leur inception, en tant que résultat le wiki est la ressource définitive pour tout ce qui concerne les microforamts ; pas du tout sur les listes de discussion. La communauté a une tradition de longue date préférant l'utilisation du wiki pour le contenu. Nous réalisons que c'est tout à fait nouveau pour une communauté de standards, du fait que la plupart des communautés de standards sont centrées sur l'email (par ex. W3C, IETF). Néanmoins pour toutes les raisons présentées au-dessus, nous croyons qu'utiliser les wikis pour le contenu est bien supérieur à l'email et de ce fait, espérons que les autres communautés de standards basculeront plus leurs activités pour être basées sur web/wiki plutôt que sur des listes de discussion.

• note historique : les microformats ont toujours été développés via IRC public + wiki depuis 2004 quand Kevin Marks et Tantek Çelik ont commencé initialement à chercher/brainstormer/ébaucher les microformats tels que rel-license, vote-links, XOXO, hCard, hCalendar sur le Wiki des Développeurs de Technorati. et le réseau IRC Freenode. Brian Suda a découvert en quelque sorte la page hCard sur le wiki des développeurs de Technorati, a commencé à la modifier, et c'est comme ça qu'ils se sont rencontrés avec Tantek Çelik. Les listes de discussion n'étaient pas créées jusqu'à ce que le site microformats.org se lance mi 2005 et elles ont toujours été considérées comme secondaires au wiki et au canal IRC.
  • exception : hAudio fût développé essentiellement à travers des éditions via e-mail et wiki. -- ManuSporny 03:37, 28 février 2009 (UTC)
    • Avec du recul, autoriser cela était probablement une erreur, parce qu'il y a eu bien trop d'emails sur le sujet de hAudio de ma part et de bien d'autres pour le hisser, et beaucoup de questions ont été résolues avec peu de profondeur de discussion (seulement 1-2 participants, typiquement Manu et Martin). A l'avenir en tant que communauté, nous devrions insister que toutes les problématiques soient enregistrées sur le wiki, et que toutes les opinions sur les problématiques spécifiques soient saisies sur le wiki, de manière à ce que cette information ne soit pas perdue dans l'e-mail.Tantek 21:23, 15 June 2009 (UTC)

documentation supplémentaire

• Voir le livre http://www.wikinomics.com/ pour plus de détails et explications sur les raisons pour lesquelles les wikis sont plus efficaces que l'e-mail pour une variété de workflows.
• Cette image aide à illustrer un des nombreux scénarios - et même si nous n'envoyons pas de documents word, le point est que le contenu itéré à travers l'email est bien moins efficace qu'itérer du contenu sur un wiki :
  

FAQ

quel est le meilleur moyen de comprendre et résoudre les problématiques

What is the best way to capture and resolve issues through broad consensus?

1. First check the relevant *-issues page, and if available, the corresponding *-issues-resolved page.
2. IRC can be useful for quickly discovering whether something is an issue or not.
3. If you cannot find the answer to an issue by searching, and asking in IRC, then ask a short message on the microformats-discuss list, and mention specifically the relevant *-issues wiki page where you didn't find the issue.
4. If it appears you have a new issue, capture it on the appropriate *-issues page.
5. If you have an opinion about an existing issue, add a nested list item to the existing issue and a "+1" or "0" or "-1" signifying your approval/ambivalence/disapproval, sign your name with ~~~~, and optionally provide reasons for your opinion.

The wiki, being on the Web and much more easily discoverable, reaches far more people than any email list or the IRC channel. Wiki pages are also much more readable as a summary of opinions, than having to wade through email threads trying to determine who is for/neutral/against any particular issue.

• Thus the wiki is the best choice for documenting a range of opinions, and archiving discussions that lead to consensus.
  • -1 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)
    • This reasoning is flawed for multiple reasons: Tantek 21:23, 15 June 2009 (UTC)
      • Different opinions should be captured on the wiki, not just consensus. If you only capture consensus, then others with different opinions that come along later will simply restate those different opinions and then the community will waste time arguing the same arguments again. IRC/Email is insufficient for discussion.
      • Consensus should arise from expression of opinions on the wiki via +1/0/-1 subpoints. If you only capture +1/0/-1 opinions in email, those discussions are inevitably lost in email archives, difficult to find, and difficult to show that consensus actually occured.
      • People can communicate informally using whatever method works for them. Formal issue capturing/discussion/resolution takes place on the wiki.
      • In order to actually keep a community a community, we have to converge on certain methods and practices. Issue capturing, discussion, and resolution is one such practice.

et si je ne peux pas trouver les problématiques sur le wiki

What should I do if I cannot find issues on the wiki?

I find it difficult to understand the arguments behind a large number of the items on the Microformats 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 ask in the IRC channel or on an email list as noted in the previous FAQ.
• 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.

pourquoi l'IRC est mieux que l'email

Why is IRC okay, but e-mail not okay? ManuSporny 03:22, 28 February 2009 (UTC)

1. 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 much more cumbersome to subscribe/unsubscribe when you have time to handle discussions or don't.
2. In IRC, if a participant has a misconception, others in the channel can quickly correct that participant, rather than the participant waste a lot of time with writing something up that is based on that misconception. In email OTOH, a mistaken assumption in the start of an email can lead to the author wasting time writing paragraphs upon paragraphs dependent on that bad assumption.

et si je n'ai pas le temps d'être sur l'IRC

What if I don't have time to be on IRC?

I do not have the time to sit around in an IRC channel. -- ManuSporny 03:22, 28 February 2009 (UTC)

I need an asynchronous method of communication and IRC doesn't work for me. -- ManuSporny 03:22, 28 February 2009 (UTC)

• If you do not have time to be on IRC or want an asynchronous method of communication, you may check the IRC archives at your convenience.

et si je préfère faire ma communication dans des batches

What if I prefer to do my communication in batches?

I do my communication in batches because that is most efficient for me. -- ManuSporny 03:22, 28 February 2009 (UTC)

• If you prefer to do your communication in batches, simply check the IRC archives, write up simple short follow-ups with references to specific IRC archive permalinks, and paste them into IRC at your convenience.

comment m'assurer que je ne rate rien sur l'IRC

How do I make sure that I don't miss something in IRC?

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)

• You can check the IRC archives, since the last time you checked the IRC archives, and thus make sure that you don't miss anything without having to be on IRC at all times.

et si quelqu'un démarre une guerre de modifications sur une question

What if someone starts an edit war on an issue?

Edit wars lead to subsequent banning of individuals, as this community has experienced. -- ManuSporny 03:22, 28 February 2009 (UTC)

If someone:

• does a revert without any explanation or follow-up explanatory edit, or
• undoes a revert without any follow-up to an explanation, or
• simply repeats an edit, ignoring previous edit explanations

Please contact one or more of the admins either on IRC (preferably) or via email, alerting them and providing URL(s) to the problematic edits on the wiki.

The admins will follow-up by correcting the wiki.

Such behavior that is disruptive to the community will not be tolerated.

If the individual persists in an edit war, especially after one of the admins have stepped in, the admins will warn and then ban the individual for progressively longer ban times as necessary.

de quelle façon le wiki est mieux pour les questions à controverse

How is the wiki better for controversial issues?

• 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.

• In comparison, 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.

qu'est-ce qui différencie la communauté microformats des communautés précédentes des standards

How is the microformats community different from previous standards communities?

• 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 mailing lists) thus significantly reducing both the utility of such lists, and the desire for people of any level of expertise to actually attempt to participate.

As Paul Graham wrote:

There's a sort of Gresham's Law of trolls: trolls are willing to use a forum with a lot of thoughtful people in it, but thoughtful people aren't willing to use a forum with a lot of trolls in it. Which means that once trolling takes hold, it tends to become the dominant culture.

comment le wiki peut améliorer l'objectivité et le sentiment de camaraderie

How can the wiki improve objectivity and friendliness?'

• 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. --BenWard 23:32, 28 February 2009 (UTC)
  • +1 Tantek 21:23, 15 June 2009 (UTC)
• 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 distill 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)
  • We should encourage neutral/objective documentation of issues, and editing of issues to remove emotional content that could be interpreted as hostile or unfriendly. Tantek 21:23, 15 June 2009 (UTC)
  • In addition, as admins we should act quickly to warn and ban individuals who are abusive on the wiki (see above about edit wars). Tantek 21:23, 15 June 2009 (UTC)
  • On the side of friendliness, we should reach out to and contact new editors over IRC and email as necessary to help familiarize them with how-to-play and the mailing-list guidelines. Tantek 21:23, 15 June 2009 (UTC)

en rapport

• listes de discussion
• comment jouer
• posez-le-sur-wiki