Interactions de communautés.

Petite mise en contexte

De nombreux remous ont agité la communauté Alionet à la fin de l'année 2009. À l'époque, la communauté Kaméléon-Facile (KF) s'est dissoute. KF hébergeait une documentation très importante, qui servait officiellement de documentation à Alionet. Du jour au lendemain, la communauté Alionet s'est donc retrouvée sans site pour sa documentation.  Nous avons donc envisagé plusieurs solutions, et sommes tombés d'accord avec l'équipe qui assure l'organisation du projet Linuxpedia . Et nous avons alors commencé la migration, dont la description des étapes n'est pas le but de ce billet.

Cet état de fait a provoqué l'apparition d'un problème original. Nous partons de deux communautés a priori distinctes : on a des utilisateurs d'openSUSE réunis au sein d'un forum, et des utilisateurs de systèmes libres qui alimentent un wiki très vaste (plus de 2500 pages... ). Bien sur, on compte quelques personnes qui jouent sur les deux tableaux, qui contribuent à la fois au forum et au wiki... mais elles sont assez peu nombreuses, en fait. La problématique suivante est donc apparue. Les membres des deux communautés cherchent à répondre à leur besoin d'informations auprès de l'outil de leur choix, ici un forum d'une part, et un wiki d'autre part. Les attentes sotn donc propres, même si elles peuvent avoir des points commun.

De plus, Linuxpedia a un statut un peu particulier : il s'agit d'une documentation traitant de problèmes très différents. Il faut donc réussir à inclure une documentation pour une distribution spécifique, ici openSUSE, dans un cadre très général. Point positif, l'expérience n'est pas la première du genre pour Linuxpedia, qui abrite par exemple la documentation de la distribution Nutyx. Point négatif : il est nécessaire de repenser la structure de la documentation qui était proposée par Kaméléon-Facile...

Une situation à démêler...

Que ce soit pour Linuxpedia ou pour Alionet, les projets à mener sont toujours le fruit de l'attente, puis de la mise en oeuvre, de la communauté. Malheureusement, dans notre cas, la situation est extrêmement complexe. En effet, les pages à étudier sur l'ancienne documentation sont nombreuses, et doivent être mises en ligne au sein de Linuxpedia. Malheureusement, aucune architecture n'est prévue pour ce genre d'entreprise, il est donc nécessaire de tout reconstruire. De plus, Linuxpedia possède ses propres règles, qu'il serait impensable pour la communauté Alionet de ne pas suivre. L'association entre les deux  communautés doit être pérennes, sans quoi le projet mourra. Et si le projet est intéressant pour Alionet, puisqu'il permet une remise en ligne et un renouveau de la documentation, il l'est également pour Linuxpedia. En effet, cette intégration permet l'apport de nouvelles connaissances, et un partage de ressources entre les commaunutés. Il est tout à fait naturel d'envisager un transfert de compétences d'une communauté à l'autre, de façon tout à fait transparente.

Dans le cadre ainsi présenté, comment réaliser la migration? Bien entendu, les communautés sont maîtresses de la chose. Cependant, il est plus qu'indispensable de réussir à transmettre les informations clairement, surtout lors des premières phases de reconstruction : la construction de l'architecture, et le transfert des documentations les plus importantes vers la nouvelle ossature. À ce niveau d'interactions, je pense qu'il est plus habile de faire communiquer des représentants de la communauté en cercle restreint, plutôt que la communauté dans son ensemble. Cela permet de limiter les problèmes de communication, et de simplifier les processus de décision.

Attention cependant, il faut toujours garder à l'esprit la règle suivante : une décision ne peut jamais être prise par une seul personne, sans consentement des autres, et de préférence avec un large soutient. Dans notre cas, la communication a connu deux niveaux distincts, peut être trois. D'une part, l'équipe d'administration d'Alionet a construit peu à peu une architecture d'accueil, qui a longtemps été débattue avant d'arriver à un résultat satisfaisant tout le monde. D'autre part, nous avons été, et sommes toujours, engagé dans un dialogue étroit avec le staff de Linuxpedia. Ceux-ci ont ainsi pu émettre des critiques vis-à-vis du résultat que nous proposions, et améliorions peu à peu.

En choisissant cette approche, nous avons effectué l'hypothèse suivante : nous pensons être capable d'effectuer un travail qui sera satisfaisant pour la communauté. Cette hypothèse est dangereuse, car elle nous impose une très grande prudence. En effet, on peut très rapidement s'éloigner de ses objectifs, oublier quel est l'intérêt du travail que nous accomplissons, et imposer finalement un résultat décevant, sans être plus capable de comprendre pourquoi les membres sont déçus.

Et les membres de la communauté dans tout ça...

Le pari était risqué. Nous serons bientôt fixé sur la qualité de notre travail, il est très proche de la mise en ligne, la plupart des phases de migration subissent des finitions  ces jours-ci. Nous avons fait le choix discutable de parler au nom de la communauté, tout en sachant que nous ne pouvons pas la représenter pleinement.

Car après tout, ces différents projets appartiennent tous aux diverses commautés. De même que Linuxpedia ne pourrait continuer son aventure sans la contribution de ses rédacteurs, Alionet mourrait sans les interventions prolifiques de certains de ses membres, toujours prompts à défendre la carte graphique veuve et le chipset wifi orphelin.

Le travail des équipe d'administration n'est qu'une simplification pour les utilisateurs. Il permet de résoudre de façon à peu près transparente les interférences qui secouent naturellement les mouvements de ce genre de projets. Transparente pour les utilisateurs. Suite à une discussion avec un membre de l'équipe technique de Linuxpedia, ce soir (enfin, hier soir, mais bon... ), il est ressorti qu'après tout, nous ne sommes que des membres de ces communautés. Même en étant administrateurs, nous sommes aussi de simples contributeurs. Avec une contrainte supplémentaire : ce que nous faisons peut rendre la vie de la communauté plus simple. Mais ça peut aussi la détruire.