DiviserPourRégner

Traduction de http://www.emacswiki.org/cgi-bin/paper/Divide_and_Conquer - seul lien de référence

Diviser Pour Régner : Nouvelles Approches de Croissance dans les Communautés Wiki

Alex Schroeder - alex@gnu.org

Abstract

Les communautés wiki grandissent autour d’un sujet particulier. Tant que la communauté croît, une diminution de la révision par les pairs et une baisse de la politesse peuvent rompre la communauté. Nous décrivons des propositions pour des mécanismes de contrôles plus serrés : des approches pour permettre à la révision par les pairs de croître dans les communautés existantes et pour faciliter la bifurcation des communautés en ligne. L’idée-clé est que nous reconnaissons comment le jeu de pages locales forme un Langage Lien pour la communauté. Pour faciliter la bifurcation, nous rendons le lien et la recherche des pages distantes aussi facile que le lien et la recherche sur les pages locales via le Lien de Proximité et la Recherche de Proximité. Ceci nous permet la réutilisation de pages sur des sites distants pour notre propre Langage Lien.

Mots Clés

Wiki, Hypertexte, Communautés Fondées sur le Web, Bifurcation des Communautés en Ligne, Lien.

Introduction

Un wiki est un site Web où n’importe quel utilisateur peut créer ou éditer n’importe quelle page sur le site en utilisant un simple navigateur. 1 Il n’existe pas de définition exacte des wikis. La plupart des gens reconnaissent un wiki quand ils trouvent une page qui dit en quelque sorte : “Editez cette page.” Les wikis rendent l’édition des pages web extrêmement faciles. Cliquez sur le lien et allez-y tout simplement. Vous n’avez pas besoin d’installer un éditeur spécifique. Pas besoin de vous enregistrer. Pas besoin d’apprendre une nouvelle syntaxe pour débuter. Il est incroyablement facile de simplement corriger une erreur de typo ou de donner votre point de vue sur quelque chose. Wiki est aussi très rapide parce que dès que vous cliquez sur le bouton Sauvegardez, vos modifications sont en ligne. Un wiki n’est pas un système de gestion de contenu (CMS) qui imite un processus de publication traditionnel. Il est de loin plus simple et bien plus flexible qu’un CMS. 2

Si n’importe qui peut éditer un site Web et si le fait de faire ainsi est incroyablement facile et rapide, il y aura des problèmes : le fait d’ignorer les conventions et traditions, l’effacement de pages, le spam, les tags – tout cela arrive. Le wiki n’aide pas à empêcher ce type de comportement. La seule chose que le wiki fait, est de vous aider à réparer. Il existe des outils pour vérifier rapidement et revenir en arrière sur toutes les modifications. La vérification est ici la partie importante. Cette révision par les pairs est la seule chose qui assure la qualité du contenu. Sans cette DouceSécurité, le wiki tombe en décadence. 3

L’outil le plus important de révision par les pairs est la liste des modifications récentes, souvent appelée Modifications Récentes. C’est une page qui liste ce qui a été modifié, quoi et quand et offre des liens pour examiner la modification exacte, pour vérifier l’histoire de la page et en savoir plus à propos de l’auteur.

Tant que les visiteurs réguliers reviennent sur le wiki, ils vérifient habituellement la page Modifications Récentes. Certains d’entre eux les appellent même les AccrosDernièresModifs? 4

S’il n’y a pas de modifications récentes, un wiki semble mort. S’il y a beaucoup de modifications récentes, la révision par les pairs tombe parce que les personnes sont débordées par la longueur de la liste. Quand les wikis et leurs communautés croissent, il y aura plus de modifications. La liste des dernières modifications croît encore plus. Eventuellement, la révision par les pairs se dégradera. Ce dont nous avons besoin est un moyen d’organiser les Modifications Récentes, un moyen de diviser pour régner.

Subdiviser les Modifications Récentes

Afin de diviser les Modifications Récentes en morceaux digestes, vous pouvez soit grouper automatiquement les modifications par sujet, ou vous pouvez permettre aux utilisateurs de piocher les pages qui les intéressent par nom ou par sujet.

Le fait d’utiliser des thématiques pour diviser automatiquement les Modifications Récentes n’a pas encore à ce jour été essayé à une large échelle.5 Les grands wikis comme Wikipedia permettent aux utilisateurs de regarder seulement certaines pages.6 Parfois, on appelle cela Abonnement Modifications 7 Ceci divise les Modifications Récentes en de gros morceaux “personnalisés”. Malheureusement la révision par les pairs pour les pages présentant un intérêt marginal sera de mauvaise qualité. Certains ressentent que c’est le prix à payer afin de rester concentré sur le contenu intéressant. D’autres craignent que le site ne se dégrade au fur et à mesure que les personnes se montrent moins disposées à pratiquer la révision par les pairs et la remise en question, parce que personne ne s’est abonné aux futures pages intéressantes.8

Subdiviser les Communautés

S’il y a trop de sujets différents discutés sur un wiki, les personnes ne peuvent plus prendre soin des modifications effectuées sur les pages qui ne les intéressent pas. Elles ne révisent plus ces pages. Dans ce cas, le fait de diviser la communauté et de subdiviser le wiki dans son intégralité pourrait constituer la meilleure approche. Créez simplement de nouveaux wikis pour chaque sujet et migrez les pages appropriées.9

Parce que cela brise souvent une communauté d’amis, le coût émotionnel d’une telle rupture se doit ne pas être sous-estimé. Une solution proposée à cela est une organisation des wikis en Hub et Rayons.10

Beaucoup de mesures de sécurité douce se prêtent mal à la croissance. Au fur et à mesure de l’arrivée de nouveaux membres dans la communauté, on observe une baisse du nombre de connexions entre les personnes. Les nouveaux venus n’ont tout simplement pas autant d’amis dans la communauté que les membres existants. Ces nouveaux membres ne partagent pas les mêmes attentes de la communauté que les membres existants. Les membres existants noteront une augmentation du nombre d’éditions de pages qui font échouer les attentes de la communauté. Ils peuvent soit partir, s’adapter ou enseigner les attentes de la communauté aux nouveaux venus. Tout cela reste très coûteux. Cela exige de l’énergie. Et provoque de l’attrition. De ce fait la croissance peut tuer une communauté.11

De la même manière, au fur et à mesure que le temps passe, différentes questions peuvent scinder la communauté, par exemple des raisons personnelles, des points de vue différents sur les questions de licences ou des intérêts divergents. Dans tous ces cas, ce serait idéal si les membres mécontents pouvaient former une nouvelle communauté. Malheureusement, les coûts de scission sont grands. Nous pourrions aimer scinder les communautés avec des coûts de scission réduits autant que possible. Les coûts de scission d’un wiki comprennent :

Afin de minimiser ces coûts, différentes techniques sont communément utilisées. Toutes essayent de dissiper la frontière entre notre wiki et le leur en facilitant le lien entre les deux.

Nous avons implémenté les mécanismes suivant pour aller plus loin dans la levée de barrières entre deux sites, faisant ainsi baisser même encore plus loin les coûts de transition.

Liens De Proximité

Le but est de rendre le lien vers des pages aussi simple que la production de liens vers des pages locales. Afin de faire fonctionner cela, nous devons connaître comment sélectionner les sites avec lesquels coopérer. Nous avons utilisé une page appelé la Carte de Proximité éditable par les administrateurs. Ceci évite la nécessité d’accéder au code actuel fonctionnant sur le serveur. Cela permet aussi de ranger avec ordre les documents des sites avec lesquels nous coopérons.

Les Liens de Proximité seront autorisés vers les wikis présents sur la Carte de Proximité. Nous requêtons ces wikis à intervalles réguliers, leur demandant une liste de pages. Cette liste de noms de pages est ensuite mise en cache sur le serveur local.

Quand un utilisateur lie vers une page, nous vérifions d’abord si la page existe localement. Si tel est le cas, nous la pointons. Sinon, nous allons à travers tous les wikis sur la Carte de Proximité et vérifions si la page demandée existe. Si c’est le cas, nous la lions.

ImageMécanismeWikimitoyen

[Near Wiki Mechanism]

Image 1 : Les sites A et B sont sur la carte de proximité. Si notre wiki n’a pas de page locale X, il regardera la liste des noms de pages en cache sur le wiki A. S’il ne trouve pas de correspondance, il fera de même sur le wiki mitoyen B.

Ceci signifie que si une page requêtée existe sur plusieurs sites sur la Carte de Proximité, nous lions vers la première occurence. Il existe une hiérarchie construite à l’intérieur de la liste des sites. Nous listons actuellement vers le premier site qui a une page correspondante au lieu de lister toutes les correspondances. Un test d’ergonomie est requis pour déterminer comment offrir une expérience de lecture agréable en offrant toujours toute l’information dont nous avons besoin.

Parce que les Liens de Proximité nous éloignent du site, nous avons besoin d’un moyen de prévenir les utilisateurs de ce détournement. Sans cet avertissement, les utilisateurs hésiteront à suivre les liens, essayant de vérifier le lien cible dans la barre de statut de leur navigateur et de ce fait dégradant leur expérience de navigation. Nous avons utilisé à la place les liens en vert au lieu des liens en bleu afin de prévenir les utilisateurs. S’ils hésitent et que leur pointeur de souris survole le lien, nous utilisons un petit popup pour nommer le site distant. Ceci est la manière de leur faire apprendre que les liens verts les emmènent ailleurs du site sans que quiconque ne leur dise véritablement.

Une autre question sur l’ergonomie que nous avons besoin de résoudre est celle-ci : Que faire si l’utilisateur veut créer la page sur le wiki local ? Si l’on suit le lien , on finira sur un des autres wikis. Il n’y a pas de moyen pour cela de créer la page localement, à moins que nous ne concevions une interface utilisateur spécifique. Notre implémentation offre une liste de liens à éditer en bas de la page, un lien pour chacun des Liens de Proximité que nous avons utilisé au-dessus. Ceci prête à confusion pour les nouveaux venus. Même si vous différenciez les liens qui vous mènent vers des pages locales des liens qui vous mènent vers des pages distantes, les utilisateurs ne comprendront vraisemblablement pas ce qu’ils doivent faire afin de créer la page en question à moins qu’ils ne soient déjà très avancés. Une recherche plus avancée sur l’utilisabilité et l’ergonomie est requise pour ce sujet.

RechercheDeProximité

Le but est de rendre la recherche de pages sur des sites sélectionnés aussi simple que la recherche de pages locales.

Quand un utilisateur démarre une recherche plein-texte sur le wiki, nous fournissons un lien pour laisser l’utilisateur étendre la recherche à tous les wikis sur la Carte de Proximité. La Carte de Proximité nous dit comment envoyer la requête sur les sites distants. Pour les sites qui renvoient seulement des pages de résultats en HTML ordinaire, nous routons nos requêtes vers des scripts proxy CGI qui font le scraping HTML de telle manière à ne pas alourdir le code wiki avec du HTML scraping code. At the moment HTML scraping code exists for three other wiki engines, so the system has proven itself.

Quand un utilisateur étend la recherche à tous les wikis sur la Carte de Proximité, nous requêtons vraiment chacun d’eux à leur tour. A nouveau, il existe une hiérarchie construite à l’intérieur de la liste des sites. Cette fois-ci, cependant, nous ne nous arrêtons pas dès qu’un résultat est trouvé. Au contraire, au fur et à mesure que chaque site renvoie les résultats de recherche, ceux-ci sont imprimés sur la page résultat que l’utilisateur est en train de voir.

Afin de réduire la confusion, nous implémentons la même hiérarchie que nous avons utilisé pour les Liens de Proximité : quand une page fait déjà partie du jeu de résultats, nous ne l’affichons pas une seconde fois. De ce fait, même si une page peut être retournée à partir d’un site distant en tant que correspondante, nous l’écarterons si une page locale avec le même nom fait déjà partie du jeu de résultats.

Si le site distant fournit quelque contexte pour les équivalences, nous l’imprimons. Pas tous les wikis que nous supportons ne nous fournissent du contexte cependant. Dans ces cas de figure, nous imprimons simplement les liens vers les pages renvoyées. Notez que si les Liens de Proximité sont disponibles, alors nous avons déjà une liste de pages sur les sites distants disponible dans un cache local. Le fait de chercher les titres de pages ne requiert pas d’accès au réseau, et de ce fait reste très bon marché à opérer. Nous incluons la recherche de noms de pages dans la recherche par défaut.

image recherche de proximité

[Near Search Mechanism]

Image 2 : Les sites A et B sont sur la Carte de Proximité. Une recherche par défaut effectue une recherche plein-texte sur les pages locales et vérifie si les titres de pages des sites distants dans le cache. (étapes 1 et 2). Si la recherche est étendue aux sites distants, nous les requêtons dans l’ordre listée sur la Carte de Proximité (étapes 3 et 4) (Mécanisme de Recherche de Proximité)

Les pages qui font déjà partie du résultat ne sont jamais prises en considération, afin d’imiter les règles précédentes du Lien de Proximité. Ceci écarte évidemment l’information potentiellement utile. Acutellement la recherche ne calcule pas la pertinence du résultat de recherche. Ceci nous évite d’avoir à choisir la correspondance la plus pertinente. Nous piochons simplement la première correspondance. Du travail supplémentaire doit être envisagé dans ce domaine.

Notre implémentation actuelle ne sonde pas les sites de manière asynchrone. Telle est la raison pour laquelle la Recherche de Proximité ne peut bien croître. Si la liste des sites sur la Carte de Proximité devient très longue, cela prendra trop de temps pour présenter les résultats des sites situés en fin de liste. Plus de travail est requis dans ce domaine.

Noms Locaux (Local Names)

L’objectif est de faire que le lien vers d’autres URLs soit aussi simple que faire un lien vers des pages locales. Ceci est en rapport avec les Liens de Proximité. Le Lien de Proximité vous permet de lier vers toutes les pages du site distant qui n’existent pas sur le site local comme si elles étaient des pages locales. Les Noms Locaux font la même chose pour des ressources uniques sur le web : cela cartographie une situation uniforme de ressource (URL) vers un nom et vous permet de lier vers cette page comme si c’était une page locale.

Tout ce que vous devez faire est de définir la cartographie quelque part. Nous avons utilisé une page sépciale sur le wiki où nous faisons ces cartographies appelée Local Names. Ceci permet à une communauté wiki d’utiliser un jeu de documents distants comme partie intégrante de leur Langage Lien en plaçant les URLs pointant vers les documents sur la page Local Names et en leur donnant des noms. Une fois que les URLs ont des noms, les noms se transforment en sections de Langage Lien.

Discussion

Nous avons montré de nouveaux mécanismes pour resserrer l’interlien entre communautés. Nous croyons que c’est important afin de réutiliser le LangageLien des communautés en ligne existantes, faciliter la bifurcation des communautés en ligne et diviser les communautés qui grandissent en des sous-communautés plus gérables.

Notre expérience indique que plus de recherche sur l’utilisabilité est requise pour les Liens de Proximité et qu’une plus forte intégration avec les technologies existante de moteurs de recherche est requise pour améliorer substantiellement la Recherche de Proximité Nous avons aussi montré comment étendre cette approche pour les jeux de ressources sur le web via les Local Names.

Nous vous invitons à regarder Community Wiki16 et Meatball Wiki17, deux espaces où sont nées ces idées.

BIBLIOGRAPHIE


LangueFrançaise PageTranslation

Traduction de l’article Divide and Conquer d’AlexSchroeder seul lien de référence. – ChristopheDucamp

Footnotes:

1. Lars Aronsson. Operation of a Large Scale, General Purpose Wiki Website. João Álvaro Carvalho, Arved Hübler, Ana Alice Baptista (editors), Elpub 2002. Technology Interactions. Proceedings of the 6th International ICCC/IFIP Conference on Electronic Publishing held in Karlovy Vary, Czech Republic, 6-8 November, 2002, Verlag für Wissenschaft und Forschung Berlin, 2002, ISBN 3-89700-357-0, pages 27-37.
2. Clay Shirky. Wikis, Grafitti, and Process. MANY-TO-MANY: social software.
3. Sunir Shah et tous [http://www.usemod.com/cgi-bin/mb.pl?SécuritéDouce Sécurité Douce]. Meatball Wiki.
4. Anonymous. Recent Changes Junkie. Portland Pattern Repository.
5. Anonyme. Filtered Recent Changes. Meatball Wiki.
6. Anonyme. Watching Pages. MediaWiki User’s Guide.
7. Anonyme. Subscribed Changes. Meatball Wiki.
8. Alex Schroeder et tous. Personalized Peer Review. En préparation.
9. Lion Kimbro. Trancher Wiki. Community Wiki.
10. Lion Kimbro et Bayle Shanks. Wikis Hub Et Rayon. Community Wiki.
11. Clay Shirky. Un Groupe est Son Propre et Pire Ennemi. Publié le 1° juillet 2003 sur la liste de diffusion “Networks, Economics, and Culture”.
12. Christopher Alexander. A Timeless Way of Building. Oxford University Press (1979).
13. Lion Kimbro. Langage Lien. Community Wiki.
14. Lion Kimbro et al. InterLink. Wiki Features Wiki.
15. Anonymous. Twin Pages. Meatball Wiki.

Define external redirect: AccrosDernièresModifs

Languages: