Observons Wikipedia : le blog de Pierrot le Chroniqueur

Impressions, révélations et gribouillages sur Wikipédia et autres projets Wikimédia

Wikipédia d'origine contrôlée

http://upload.wikimedia.org/wikipedia/commons/3/39/Chateau_Mouton_Rothschild%2C_1992%2C_Pauillac.jpg

 

 

On le sait depuis longtemps, Wikipédia a toujours été performante pour drainer des microconflits sans intérêt, aux conséquences pratiques nulles, mais engendrant des kilo-octets de discussions plus ou moins stériles, à n'en plus finir. On se souvient évidemment, ô grands classiques, de la guerre entre les chicons et  les endives, ou encore des tremblements1 entre Tōkyō et Tokyo. La dernière en date n'est pas mal non plus, du moins au premier abord. Cela se passe ici, sur la page de discussion des conventions sur les titres. L'enjeu est le suivant : faut-il, sur les articles vinicoles (principalement les crus, bien sûr) mentionner en titre les labels AOC et AOP ? Si oui, faut-il mettre ces acronymes entre parenthèses ? À première vue, le débat a tout pour être trollogène, et entrer dans la lignée susindiquée des grandes discussions inutiles dont raffolent les Wikipédiens. À première vue seulement, car le conflit est en réalité assez important et intéressant à plus d'un... titre : 

  1. La neutralité de point de vue (Npov) a été invoquée, ce qui rend déjà le débat plus important qu'il n'y paraît. Si la présence des labels en titre s'analyse comme un coup de pub — interprétation qui n'a finalement pas été retenue — alors le débat était indispensable car la NPOV est un principe fondateur de Wikipédia, comme vous le savez.
  2. La présence, antérieure à la discussion, des labels entre parenthèses, va à l'encontre des règles communautaires sur les parenthèses en titre, réservées en principe aux cas d'homonymie, comme Manuguf et Moyg l'ont très bien expliqué. Sauf qu'un consensus avait été obtenu sur le projet Vigne et vin pour qu'il en soit ainsi. On se retrouvait donc dans le cas, que j'avais sommairement abordé ici, du projet en butte au reste de la communauté. Ce fut particulièrement visible : les divergences dans cette longue discussion démarquent clairement la ligne entre ceux qui sont sur le projet et ceux qui n'y sont pas (cela me fait penser, toutes proportions gardées, à quelques commentaires de ce désormais fameux billet, qui pointaient le comportement clanique de quelques projets). C'est un aspect extrêmement intéressant de l'évolution de Wikipédia, et du distinguo nécessaire entre principes et réalités, entre règles et faits. Cela doit conduire à une véritable réflexion sur la portée des règles et recommandations communautaires, ainsi que sur l'influence que peut, ou doit, avoir un projet. Faut-il convenir que les règles wikipédiennes sont avant tout un corpus indicatif, nécessaire à une marche harmonieuse de l'encyclopédie, et qu'on peut ponctuellement y déroger, tacitement ou par consensus exprès ? Ou faut-il au contraire sérieusement borner les limites et appliquer à tout prix ces règles car elles sont d'essence communautaire ? Cela semble aller de soi pour les principes fondateurs. Mais pour le reste ? N'a-t-on pas justement un PF qui stipule que les règles doivent être appliquées avec souplesse ? Cela peut-il aller jusqu'à permettre l'application de l'exact contraire d'une règle dans certains cas ? Faut-il doter les projets de pouvoirs normatifs, en ce sens ? Après tout, les membres d'un projet sont ceux qui connaissent le mieux le sujet en question. Faut-il donc leur donner les coudées franches pour adapter certaines règles à leurs articles, dans l'intérêt supérieur de Wikipédia ? Je parlais de la distinction principes/réalités ; cela peut se traduire par cette nécessaire souplesse, cela se traduit déjà dans les faits : certains projets se sont clairement émancipés, et ont, par consensus en leur sein, développer de nouvelles règles qui leur sont propres, des coutumes qu'ils appliquent inconsciemment, qui peuvent être divergentes avec les règles communautaires. Faut-il, comme Manuguf, le déplorer et combattre ces entorses communautaires ? Ou faut-il au contraire estimer comme moi — car telle est mon opinion, du moins jusqu'à un certain point — que Wikipédia, si elle se doit, dans l'optique d'un fonctionnement communautaire efficace, d'avoir un minimum de règles de base, doit avant tout fonctionner par pragmatisme plutôt que de manière bureaucratique, ce qui implique évidemment une certaine autonomie des projets ? Beaucoup de questions, dont les réponses sont finalement loins d'être évidentes, et qui peuvent appeler des réactions radicalement différentes, mais tout aussi compréhensibles et recevables, selon les sensibilités de chacun. Mais la communauté gagnerait à sérieusement se pencher sur elles. Sauf que sa réponse, si elle est positive,  pourra alors être "localement" combattue2
  3. Souvent, de tels débats apparaissent insolubles. Enfin, ils finissent par être solutionnés, mais soit dans les larmes, avec quelques arbitrages par exemple, soit à marche forcée, avec une prise de décision. Mais ici, cette discussion pourtant bien mal partie a abouti à un compromis, à savoir la présence des labels, mais sans parenthèses sauf quelques petites exceptions clairement identifiées (enfin, si j'ai bien compris), consensuellement adopté par les parties en litige. C'est un très bel exemple de résolution collective d'un conflit trollogène et plein de tensions. Félicitations à tous les participants qui, malgré quelques anicroches, n'ont jamais fermé le dialogue. C'est, hélas, assez rare, et c'est tout à leur honneur.

 

Les protagonistes trinquent donc à leur accord et à leur réconciliation, mais une pensée me vient alors à l'esprit : cet accord ne respecte pas vraiment davantage (un petit peu plus quand même) les conventions sur les titres que ce qui avait été décidé par le projet Vigne et vin... Et, cette fois, ce n'est pas un projet qui est passé outre, ce sont tous les contributeurs qui se sont mêlés au débat. Dans l'allégresse générale. Le pragmatisme, je vous l'avais bien dit, permet à Wikipédia de mieux avancer que n'importe quelle règle. Santé !

 

 

Note : Photographie en provenance de Commons. Auteur : Michael Reuter.

 

 

1. Oui, je sais, je donne dans l'humour noir bien vaseux.

2. Je vous laisse réfléchir à cette boucle... 

Partager cet article
Repost0
Pour être informé des derniers articles, inscrivez vous :
Commenter cet article
A
<br /> <br /> /me note ce renseignement vague mais parlant dans la base de données secrète "qui est Pierrot le Wikirigolo?"  <br /> <br /> <br /> <br />
Répondre
P
<br /> <br /> Bon courage dans tes recherches ... <br /> <br /> <br /> <br />
A
<br /> <br /> Nous ne sommes naturellement pas totalement libres de ce que nos expériences font de nous, et peut-être que si tu te faisais étriller comme je l'ai été lorsque j'ai commis l'erreur de me rendre<br /> dans le projet pour discuter, nos avis serait encore plus proches <br /> <br /> <br /> <br />
Répondre
P
<br /> <br /> Possible, mais je connais d'expérience ce genre de problèmes, donc je crois que je saurais relativiser. <br /> <br /> <br /> <br />
A
<br /> <br /> Tu m'as mal lu ou je l'ai mal écrit, mais je ne pense pas que nos positions soient si éloignées l'une de l'autre. La mienne revient à laisser les projets travailler, mais "en liberté<br /> conditionnelle" en quelque sorte. Et si quelqu'un estime qu'une décision interne d'un projet devait être soumise à la communauté (sans même parler de prise de décision, je parle de simplement<br /> exporter la question sur une ou des pages communautaires généralistes), le projet ne peut s'y opposer ni limiter le champ de discussion aux sous-pages du projet. Ceci peut avoir l'air un peu<br /> formaliste et théorique, puisque si personne ne s'y intéresse vraiment, les membres du projet appuieront leur propre décision sur la page communautaire généraliste. Ce serait effectivement<br /> théorique si les membres des projets avaient de mauvaises intentions, mais ce n'est pas le cas. Rappeler que leur champ d'action s'inscrit dans le champ d'action plus général de l'encyclopédie,<br /> c'est rappeler qu'un projet n'est là que pour structurer des efforts communs, pas pour créer des sous WP déviant du tronc principal ni limiter le travail des autres wikipédiens, ce qui devrait<br /> suffire à limiter certaine tendance inquiétante sans limiter les projets dans ce qu'ils sont réellement censés faire.<br /> <br /> <br /> <br />
Répondre
P
<br /> <br /> Dit comme ça, je te suis davantage, en effet. Bien évidemment, les membres d'un projet ne pourront jamais s'opposer à une discussion sur une page communautaire généraliste de certaines de leurs<br /> règles et coutumes. Mais là, on est bien dans l'action a posteriori que je définissais ci-dessus. C'est la meilleure solution pour laisser des marges de manoeuvre tacitement<br /> consensuselles aux projets, tout en préservant la possibilité de saisine communautaire du dossier en cas d'abus trop problématiques. Nos positions ne sont pas si éloignées, en<br /> effet.  Peut-être que je veux simplement laisser un peu plus de liberté que toi aux projets, mais c'est minime.<br /> <br /> <br /> <br />
A
<br /> <br /> Ah non, pas d'accord sur ce point, ou en tout cas, la décision prise par le projet doit être soumise à la communauté sur une page communautaire générale, et si elle ne l'est pas, devrait être<br /> considérée comme sans effet dès contestation. Parce que en fait, dans le cas pratique considéré, le projet a réussi à refuser pendant deux ans de se soumettre à la communauté, et encore<br /> maintenant dans les projets,  plein de gens sont persuadés qu'il peuvent parfaitement prendre des décisions de ce type, et que si quelqu'un veut en parler il doit venir sur le<br /> projet (où il pourra se faire assassiner en douceur).Selon moi il devrait donc être parfaitement clair que oui, le projet peut faire sa petite cuisine, mais si quelqu'un dit que la<br /> communauté doit être consultée, le projet doit se soumettre et consulter la communauté.<br /> <br /> <br /> <br />
Répondre
P
<br /> <br /> Non, qu'une décision intra-projet, même dérogatoire à une règle communautaire soit soumise à la communauté engendrerait formalisme superflu et perte de temps. Généralement, de telles décisions<br /> sont tacitement consensuelles, malgré leur caractère d'exception à une règle. Si ce n'est pas le cas, alors il y aura fatalement des contestations.  Et il incombera aux contestaires de faire<br /> tout le nécessaire, si vraiment cette décision n'est pas justifiable. Pragmatisme, toujours. De toute façon, on ne peut forcer personne à quoi que ce soit sur Wikipédia, et certainement pas de<br /> lancer une consultation. Je n'approuve pas pour autant, bien au contraire, les projets qui refont tout Wikipédia à leur sauce, sont fermés et forment presqu'un Etat dans l'Etat, comme je l'ai<br /> très clairement souligné dans ma réponse plus haut. Simplement, je crois qu'il ne faut pas non plus tomber dans l'excès inverse de normativisme en empêchant toute dérogation communautaire par simple consensus sur un projet (car c'est sans doute fait pour une<br /> bonne raison) : encore une fois, une telle situation est gênante que si la décision est problématique. Et là des réactions sont possibles et se feront. Dans le cas contraire, largement<br /> majoritaire à mon sens, personne ne dit rien, et tout le monde est content. Donc pourquoi imposer des obligations a priori qui alourdiraient encore le système ? Le contrôle a<br /> posteriori suffit et a montré dans cette affaire son efficacité, justement.<br /> <br /> <br /> <br />
A
<br /> <br /> Oui, pragmatisme et souplesse, mais pas en cachette dans un projet. Si un projet pense devoir faire une entorse à une règle ou coutume, la communauté doit avoir son mot à dire. Régler les choses<br /> entre soi dans un projet, c'est montrer qu'on se défie de la communauté, et c'est là un péché majeur dans WP.<br /> <br /> <br /> <br />
Répondre
P
<br /> <br /> Dans l'absolu, il serait mieux que la communauté dans son ensemble soit consultée, mais ce n'est pas à mes yeux une nécessité. Des décisions peuvent très bien êtres prises intra-projet : c'est<br /> plus simple et plus rapide. Si vraiment cette décision interne est abusive, le reste de la communauté finira par s'en rendre compte (c'est ce qui s'est passé ici) ; si ce n'est pas le cas, tout<br /> le monde a gagné du temps. Pragmatisme, toujours.<br /> <br /> <br /> <br />
A
<br /> <br /> Le problème le plus fondamental n'est effectivement pas vraiment cette question de parenthèses, pourtant bien gênantes, mais bien la propension de certains projets à fonctionner en autarcie.<br /> J'avais fait une 1ere tentative début 2009 sur la question des parenthèses, et déjà la lecture est consternante (j'ai perdu le compte du nombre de fois où je répète sur tous les tons qu'un projet ne<br /> peut, dans son coin, aller à l'encontre de règles fixées par la communauté). C'est bien simple, mon "cas" a même été évoqué sur la BA à l'époque par LPLT, admin membre du projet, ce qui avait<br /> permis à l'époque de me faire taire devant un soupçon de faux-nez. Donc effectivement, puissants et inquiétants, ces projets, un danger pour l'encyclopédie (surtout mené par un JPS68). Ce coup-ci, suite au relancement de la question par Yelkrokoyade, j'ai tout de suite exporté la<br /> discussion hors du projet, ce qui a permis de résoudre le problème, notamment avec l'apport de Manuguf et Moyg (sans leur aide, je suis certain que le projet aurait de nouveau bypassé le<br /> processus). Pour compléter du côté "projets qui prennent le pouvoir",  j'avais aussi noté cette section du Bistro où on apprend à peu près qu'avant de faire quelque chose, il faut demander<br /> la permission au projet (j'exagère à peine): Bistro du 15 mars. Et ce n'est pas n'importe qui qui sort<br /> des énormités comme ça, hein!<br /> <br /> <br /> <br />
Répondre
P
<br /> <br /> Merci pour cette explication et tes exemples, tous instructifs et très intéressants. Oui, c'est en effet la véritable<br /> question de fond qui était sous-jacente dans ce débat. Je suis partiellement d'accord avec toi : oui, tu as raison, il est hors de question que des projets, mais hélas ça se voit et il est vrai<br /> que le projet Vigne et vin mené par un JPS68 que, en passant, je trouve de plus en plus autoritaire depuis qu'il est administrateur (cela arrive parfois, hélas...), en est l'illustration,<br /> puissent préempter des articles et y faire leur petite cuisine tous seuls dans leur coin, en refusant les autres contributeurs et en rejetant les règles communautaires. Il est évident qu'une<br /> telle attitude est une menace pour l'unité de Wikipédia, et qu'elle ne saurait donc être encouragée. Pour autant, comme je le disais dans ce billet, il me semble tout aussi problématique<br /> d'appliquer à la lettre ces règles sans aucune souplesse, et sans permettre à quelques projets de pouvoir y déroger pour x ou y raison valable.<br /> N'oublions pas que l'intérêt supérieur est celui de Wikipédia, et si quelques articles se trouvent améliorés par quelques entorses ponctuelles à des règles et recommandations, il faut savoir et<br /> pouvoir le faire. Le pragmatisme me semble essentiel au bon fonctionnement d'une encyclopédie. Le tout est donc de trouver un juste milieu.<br /> <br /> <br /> <br />
D
<br /> <br /> ou encore des tremblements1 entre Tōkyō et Tokyo<br /> <br /> <br />  <br /> <br /> <br /> > C'est avec stupeur que je constante que tu ne cite pas la bonne transcription, Tôkyô.<br /> <br /> <br /> <br />
Répondre
P
<br /> <br /> . Mais le débat, à l'époque, ne concernait que ces deux transcriptions (pour autant que je me souvienne). S'il y en a<br /> une troisième de proposée, maintenant, je vais crouler sous le travail de lecture pour en faire un billet, et j'en serai si fatigué que j'aurai un pied dans la Nothomb !<br /> <br /> <br /> <br />