Wikipédia:Consultation sur la communication 2019/Phase 1/Question 6

Avez-vous d'autres remarques à faire et qui devraient être remontées à la Fondation ?

Les avis ci-dessous sont divisés en sections. Gardez à l'esprit qu'il s'agit uniquement d'avis destinés à la fondation et non pas d'un vote ou d'une prise de décision. • Retour aux questions

Avis de Jules78120

À mon sens, il faut absolument, à terme, n'avoir qu'un seul outil de discussion. Le mix Flow/discussions classiques n'est pas satisfaisant, et complexifie davantage la vie des nouveaux : Flow est plus simple à prendre en main pour les petits nouveaux, mais actuellement ils sont ensuite obligés de se frotter au système de discussion classique.

Dans tous les cas, c'est une banalité, mais il faut un système qui soit adapté tant aux nouveaux qu'aux contributeurs expérimentés. — Jules ^Discuter 23 février 2019 à 19:21 (CET)

C'est presque une injonction contradictoire, mais j'acquiesce. Nous avons depuis 15 ans relevé d'autres défis, grâce à toi notamment. Merci --Lamiot (discuter) 17 mars 2019 à 17:48 (CET)

Avis de Lomita

Tour revoir sur Flow qui ne satisfait qu'un nombre limité de contributeurs, certainement que les nouveaux - -- Lomita (discuter) 24 février 2019 à 16:49 (CET)

Avis de CreativeC

Faire une enquête d’opinion pour enfin comprendre pourquoi il y a des réfractaires à Flow (bien que je pense que ce soit idéologiquement l’attachement à l’anarchie la liberté offerte par le wikicode en PDD) --CreativeC^d|c|g 25 février 2019 à 23:32 (CET)

Coucou @CreativeC . Tu trouveras peut-être quelques premiers éléments de réponse ici : Wikipédia:Consultation sur la communication 2019/Phase 1/Question 3. Ce serait bien que la présente consultation permette justement d'améliorer/transformer Flow. L'éditeur visuel est un vrai plus pour les nouveaux. — Jules ^Discuter 25 février 2019 à 23:41 (CET)

Je pense que tu as raison, un élément très important que j'apprécie dans les discussions actuelles est la grande liberté offerte aux utilisateurs par le wikicode. O.Taris (discuter) 3 mars 2019 à 20:34 (CET)

Avis de Madelgarius

Ce commentaire déborde du cadre de cette consultation puisqu'il en questionne les présupposés. Il est question ici d'outils de communication de la communauté. Les inférences sont donc qu'il y a des problèmes d'outils, qu'il existe une communauté et surtout qu'en redéfinissant les contours du/des outils cela va améliorer la communication entre wikipédiens.

Il me semble que le premier écueil, bien avant le wikicode (que je pratique volontiers), ou les problèmes de suivi, d'archivage de flow, est le fait qu'il n'existe pas de "communauté wikipédienne" parce que rien ne permet de développer un "sentiment d'appartenance". La communauté n'est donc selon moi que la juxtaposition d'individus. Pas d'ingroup = pas d'outgroup = pas d'impétrants. En revanche, cette communauté en manque de cohésion et d'esprit de groupe dispose de castes (elles sont bien nécessaires, je ne suis pas en train de cracher dans la soupe), les admins, les bureaucrates, les stewards puis l'immense magma des contributeurs.

Améliorer la communication sur WP doit d'abord passer par un renforcement du sentiment d'appartenance. Une piste serait de créer un véritable statut pour les wikipédiens qui, à l'heure actuelle, ne sont que des nouveaux arrivés qui ont un peu vieilli et ont l'insigne honneur d'être "autopatrolled", donc non nuisible? Il y a trop de sable dans ce mortier pour qu'il puisse faire sa prise. Renforcer le sentiment d'appartenance permet également de se structurer davantage autour de valeurs partagées et fédératrices et d'identifier plus clairement les outgroups et les cheminements/accompagnements pour intégrer ses membres: l'accueil des nouveaux (et je ne dis bien sur pas qu'à ce stade rien n'est fait en ce sens).

Voilà, un avis d'un nouveau wikipédien qui fête aujourd'hui (tout seul) son huitième anniversaire de contributions sur wikipédia qui est un projet d'un idéal fou et qui mérite à lui seul toute l'énergie que j'y mets. La communauté? ... peut-être un jour.— Madel (... le 22 à Asnières ?) 26 février 2019 à 07:45 (CET)

Avis de Tortliena

Juste une note sur la consultation elle-même : Annoncer de fait des défauts et des qualités aux outils dans les objectifs (même à titre de démonstration de ce qui est attendu) risquent d'enfermer les gens et réduire les chances de trouver des choses peut-être inattendues mais viables. Après, c'est vrai, ça réduit aussi les chances que les gens parlent de problème hors-sujets comme le fait qu'il y a des gens qui disent pains au chocolat ou chocolatine x).

--- }i{ - Tortliena (discuter) - }i{ - 26 février 2019 à 13:41 (CET)

Avis de Nemo 33

Je propose de garder le wikicode (avec le bandeau de l'éditeur visuel) pour ceux qui souhaitent garder une liberté totale + trouver une alternative à Flow qui doit être adapté pour tout le monde et compatible avec le wikicode (pas comme maintenant où certaines conversation sont en WikiFlow et d'autres non ce qui bordélise WP. Cela permettrait que tout le monde soit content et arrangerait les nombreux défauts qu'a Flow. Nemo 33 (discuter) 27 février 2019 à 21:40 (CET)

Avis de O.Taris

Quand je vois les développements d'outils réalisés par la Fondation, je me désole beaucoup trop souvent de l'énergie déployée pour les résultats obtenus, généralement très insatisfaisants (au point que je m'empresse de ne pas utiliser les outils nouveaux) :

• outils gourmands en ressources et lents ;
• complexité des outils et manque de sobriété, trop de fonctionnalités dont l'utilité réelle reste à démontrer.

Il faut faire simple et robuste. Un outil peut être compliqué à programmer, pourquoi pas, mais il faut qu'il paraisse simple et efficace à l'utilisateur. O.Taris (discuter) 3 mars 2019 à 20:51 (CET)

Avis de Tomybrz

Améliorer l'espace de nom Topic/Sujet :

• Pouvoir personnaliser le nom du sujet en lien avec {{BASEPAGENAME}}
• Améliorer l'ajout des modèles

Tomybrz Bip Bip 11 mars 2019 à 19:41 (CET)

Avis de Silvicola

Les montagnes de parenthèses nécessaires pour faire le moindre modèle sont une vexation. De plus, la syntaxe des modèles est cassée dès le début:

• La faille des arguments de position
• La coupe du white space avant et aprés les argiments empêche certain formatages à la main qui sont parfois dßesirables justement à caise de restrictions des modèles
• Les noms de includeonly et onlyinclude prêten à confusion (sauf peut-être piur les anglophones)
• Le principe de l'opération par substitution de texte est difficile à saisir. Le tissu e texte propre et de parties opérationelles empèche une formatisation bien lisible du texte.

Il faudrait de la programmation véritable avec des variables que l'on peut soi-meme définir et utiliser etc. Il faudrait pouvoir construire un arbre d'objets et une méthode constructeure pour ne produire le résultat de l'opération totale d'un modèle que dans une méthode de fin-de-vie disont print, qui pourrait à loisir parcourir l'arbre des objets construits. Ainsi l'on pourrait séparer l'operation sémantique et la composition syntactique du texte.

La langue Wiki a évidemment été faite petit à petit et sans une idée claire à l'avance. Peut-on espérer une substitution? Sinon, les wikis seront un jour du « legacy » bourré et confus auquel personne ne voudra plus toucher. --Silvicola (discuter) 22 mars 2019 à 18:18 (CET)

 Silvicola : Il y a déjà beaucoup de choses possibles avec les bots, Scribunto ou encore des extensions MediaWiki telles que celle-ci. La syntaxe des modèles est assez affreuse, notamment à cause du fait qu’on ne peut pas faire des retours à la ligne et indenter sans que ça affecte le résultat (à moins de mettre cette aération en commentaire, ce qu’on fait du coup, mais c’est très lourd). Peux-tu préciser ce que tu voudrais comme « programmation véritable », en donnant un exemple de code ?

Beuh… J’avoue, on ne peut même pas faire des modèles récursifs ! Ça fait sortir un affreux message : « Modèle en boucle détecté ». Tu as raison, il y a un problème. Frigory (discuter) 28 mars 2019 à 01:49 (CET)

@Lua:

Je voulais m'y essayer et j'ai pour cela téléchargé pour pouvoir jouer sur mon ordinateur-même, la seule méthode à mon expérience de s'introduire vraiment dans ine langue. Il n'y avait pas de gestionnaire de paquets, la chose étant prétendument sans dépendances. Mais hélas, si! Entre-temps, j'ai trouvé et installé les bibliothÊques manquantes, mais l'augure est là.

@programmation véritable:

Le problème vient de ce substitutionnisme pauvre. Chaque modèle prend des paramètres texte et en fait un nouveau texte à insérer à sa propre place. Il n'y a pas de flux de dates à volonté, sinon par ces mots magiques mis à la disposition par les bricoleurs de la syntaxe wiki et qui sont de fait des variables globales; on se gardera donc bien à en augmenter encore le nombre ou à les rendre changeables!

Il n'y a donc pas d'objets, pas de structure profonde et subtile, tout l'opération est une séquence de substitutions impératives de texte. C'est comme une architecture modèle-vue-contrôleur à laquelle on aurait enlevé au moins tout modèle.

Un exemple de problème que j'ai rencontrés (en de-wp).

Il y a là un modèle de:Vorlage:Infobox Fluss (qui correspond à fr:Modèle:Infobox Cours d'eau). Il y a des paramêtres pour la longueur, pour l'altitude de la source et l'altitude de l'embouchure. On constate assez vite que beaucoup de fleuves ont plusieurs sources (commencement du parcours fluviale sous son propre nom; plus haute source; source de la branche avec la plus grande longueur jusq'au commencement du parcours fluviale sour son propre nom etc.) et quelques-uns ont aussi plusieurs embouchures (Rhin, Mississippi, Ganges etc., il y a aussi bien des deltas intérieurs ou des branchements avant l'embouchure en un canal d'une part et le parcours naturel du fleuve d'autre part et qui se jettent à endroits différents). Il serait donc à propos d'encapsuler toutes le dates se référant à la même source en les rendant non pas paramêtres du modèle de:Vorlage:Infobox Fluss propre, mais d'un sous-modéle employé dans l'intérieur de celui-ci. Mais pour calculer la hauteur parcourue ou l'inclinaison moyenne du fleuve, il faudrait avoir accès au paramêtres du sous-modèle, qui n'est, hélas, pour le modèle envoûtant qu'une partie quelconque et inaccessible du produit substitutionel dans l'intérieur d'un de ses propres paramêtres. La solution trouvée par necessité technique: tout devient un des paramêtres innumérables du « grand » modèle. On n'offre donc, tel qu'exposé par les paramêtres (QUELLE l'emplacement en mots, QUELLHÖHE l'altitude, QUELLE_REGION code ISO-3166-*, QUELLE_LAT_GRAD, QUELLE_LON_GRAD coordinées etc.) du modèle de:Vorlage:Infobox Fluss, qu'une seule source, mais on met à disposition du rédacteur des paramêtres QUELLE-PREFIX, QUELLE-SUFFIX pour bricoler les dates des autres sources (inspection du code du modèle aidant …) pour qu'elles soient formatées de la même façon et mis avant ou après la cellule de table pour la « bonne » source. Résultat prévisible: peu de rédacteurs s'octroient la peine et souvent la longueur annoncée se réfère à une autre source que celle exposé comme source principale, donc incopmpatilité sinon fausseté.

Le débit d'un fleuve souvent est mesuré à divers lieux de son cours, on a donc des paramètres PEGEL1, PEGEL2, PEGEL3, PEGEL4 et paramètres accompagnants. Pourquoi exactement 4? Parce qu'il faut copier le code de traitement et adapter les noms de paramètres inpliqués pour chaque nouveau PEGEL nom allemand pour l'instrument de mesure de la hauteur du fleuve et donc indirectement de son débit à ce point-là et l'on ne veut pas faire cela indéfiniment …

Tout jusqu'ici a éte très concret, maintenant la vue au-dessus de la mêlée.

Le mal vient de l'opération substitutionelle de texte. Les modèles ne devraient pas produire du texte, mais un objet, qui peut aussi être un arbre d'objets. Leur paramètres de même ne devraient être du texte (potentiellement comprenant des produits textuelles d'autres modèles), mais aussi des objets (souvent ce ne seraient bien sûr que des chaînes de caractères). Chaque modèle est vu des cet aspect une sorte de constructeur. Le texte désirée ne serait construit à la dernière occasion/au plus haut biveau, à savoir par le parseur d'une page wiki qui rencontre un modèle, qui lui fait faire sa construction et sachant que le ŕesultat en est un objet, appelle ensuite la méthode print de celui. Dans cette méthode print, definie pour chaque modèle (pour beaucoup de modèles simples peut-être non explicite parce que triviale) chaque objet pourra organiser les flux de dates necessaires entre lui-même et ses sous-objets à sa guise, soit que les sous-objets offrent des méthodes d'accès à ses propriétés, soit que celles-ci sont par principe tout à fait transparentes et accessibles.

Cette architecture avec double entrée constructeur/print permettrait d'extriquer le code et les segments du produit, dont l'entremêlement fait les modèles qui font vraiment quelques choses si compliqués.

Je ne vois pas vraiment une entrave grave à enseigner aux rédacteurs sans expérience avec la programmation de mettre dans les seuls modèles simples à qui ils toucheront et touchent aussi maintenant quelque chose comme par exemple

MON-MODÈLE-PERSONNE (PRÉNOM, NOM-DE-FAMILLE, LIEU-DE-NAISSANCE) {

print {

résultat = $NOM-DE-FAMILLE + "," + $PRÉNOM + ", naissance à " + $LIEU-DE-NAISSANCE

}

}

au lieu de la marée de parenthèses pour les seuls paramètres qu'il est aujourd'hui necessaires de déverser. (Le constructeur banal qui ne fait rien d'autre que de copier ses paramêtres dans ses propriétés de même nom pourrant être omis.)

Dans l'exemple donné, s'on procurait un seul paramètres QUELLENLISTE qui est une liste de sous-modèles QUELLE comprenant tout les parametres se référant à une même source. On a accès à la hauteur de la source primaire par quelque chose comme QUELLENLISTE[1].HÖHE, de même pour l'embouchure primaire, et aisi le calcul de Linclinaison se pourra faire sans lever tous les sous-paramêtres à la hauteur du modèle principal.

De même, en donnant à celui un paramêtre-liste PEGELLISTE comprenant des sous-modèles, on pourra en avoir autant que l'on veut sans bourrer le code du modèle principal par des répétitions inutiles, tout étant encapsulé dans le sous-modèle.

Je regrette, c'était un peu long et c'était aussi utopiste à cause de la persévérence inextricable de l'état des choses, fût-il perverti. --Silvicola (discuter) 28 mars 2019 à 05:01 (CET)

 Silvicola : Merci pour ces détails… Je ne demandais que par curiosité ; je ne pense pas pouvoir faire grand-chose, n’étant pas un développeur de MediaWiki.

Mais je ne comprends pas grand-chose à ce que tu racontes… Qu’est-ce que tu appelles des « dates » ; quel rapport entre des fleuves et des dates ?

J’ai moi aussi eu l’occasion de me plaindre du fait qu’il fallait parfois faire beaucoup de copier-coller pour obtenir les résultats qu’on veut… C’est pas terrible, m’enfin on s’y fait.

Scribunto retourne bien des objets, mais ça m’a l’air plus limité que ce que tu proposes. Frigory (discuter) 2 avril 2019 à 18:21 (CEST)

Excusez-moi. « dates » = « données ». Je suis, hélas, atteint et du franglais (fr + en) et du denglisch (de + en). --Silvicola (discuter) 3 avril 2019 à 00:39 (CEST)

Avis de Frigory

Faut-il que je me répète alors que j’ai déjà évoqué la chose en réponse aux questions 1 et 2 ? Je suis content de voir que Nemo 33 a la même idée que moi. En effet, cette idée permettrait de faire ce qu’on veut, c’est-à-dire se débarrasser de l’interface de discussion utilisant la modification de page classique, et offrir aux nouveaux utilisateurs une interface ergonomique, optimisée pour la discussion, sur absolument toutes les pages de discussion. La discussion par modification classique des pages resterait un temps disponible pour les nostalgiques réfractaires au changement, mais la compatibilité avec le wikicode étant conservée, on trouverait bien un moyen de les convertir à l’utilisation de l’interface moderne. Et ça permettrait de n’avoir qu’un unique système de discussion sur les wikis, ce qui simplifierait les choses, effectivement.

J’ai aussi eu le plaisir de lire dans les réponses à cette consultation quelques autres opinions progressistes très tranchées — . Ouf, je ne suis pas le seul extrémiste un peu taré du coin ; même si je suis probablement le plus taré de tous.

Frigory (discuter) 28 mars 2019 à 01:59 (CET)

Voilà comment j’imagine la surcouche dont je parle. Le système pourrait commencer par altérer toutes les pages de discussion afin de les rendre plus faciles à lire (on ferait soit le traitement d’un coup soit lors du premier affichage de la page de discussion). Il faudrait réussir à détecter la plupart des signatures et les mettre dans un format plus clair. Au lieu d’avoir des signatures personnalisées insérées dans chaque page, on pourrait avoir un code {{Signature:Frigory|1554752142}} qui insèrerait la page Utilisateur:Frigory/Signature qui aurait un contenu par défaut, ainsi que la date correspondant au nombre indiqué qui est le numéro de la seconde à laquelle la signature a été publiée à partir du 1^er janvier 1970 dans la langue qu’il faut. Ainsi le système aurait beaucoup moins de mal à identifier les signatures.

Pour identifier les signatures, on a de nombreux repères :

• les deux traits d’union « -- » assez fréquemment utilisés ;
• le lien vers une page utilisateur et vers sa page de discussion ;
• une date, avec dans le cas français :
  • un numéro de jour ;
  • un nom de mois parmi douze existants ;
  • une année supérieure à 2000 ;
  • « à » et une heure au format américain ;
  • la zone horaire utilisée indiquée entre parenthèses, ici « (CET) » ;
• il y a aussi parfois l’utilisation du modèle {{Non signé}}.

Il faut identifier ce gros bloc, déterminer l’utilisateur et la date et remplacer tout ça par un code {{Signature:1|2}} beaucoup plus propre, qui écrirait la même chose. Éventuellement, si on détecte un préfixe avec des traits d’union, on peut le spécifier comme troisième paramètre : ce serait affiché dans le mode classique, mais pas avec la surcouche. On pourrait de la même façon avoir un quatrième paramètre qui indiquerait s’il faut ou non utiliser le modèle {{Non signé}}.

Il faudrait ensuite identifier les messages, et mettre un {{Non signé}} (potentiellement : {{Signature:Frigory|1554752142||Non signé}}) lorsqu’il n’y a pas de signature, en essayant d’identifier qui a écrit le message, à partir de l’historique. On voit que l’on passe d’un message à un autre soit parce qu’il y a un changement d’indentation, soit parce qu’il y a une signature. Il peut y avoir de l’indentation au sein d’un message sans que ce soit un nouveau message : c’est ce qu’on interprète si une indentation n’est pas précédée d’une signature, et si on détecte dans l’historique que l’utilisateur a écrit les deux parties (celle de base et celle qui a une indentation de plus) lors d’une même modification.

Ensuite, lors de son fonctionnement normal, le système n’aurait qu’à trouver les différents messages en voyant les séparations grâce aux {{Signature:}}, et il rajouterait de l’indentation à chaque nouveau message. Ce sera vite moche dans le cas où il y aura beaucoup de messages ; mais c’est nécessaire… Ou alors on pourrait supprimer toute l’indentation et afficher un séparateur après chaque signature, pour que ça ressemble plus au style de Flow, et ça permettrait d’avoir des messages indentés, qui ne répondent pas au flux principal mais à une réponse spécifique.

Oui, tout cela est un peu moche, mais il est à mon avis beaucoup plus approprié que les développeurs professionnels de MediaWiki se satisfassent (au moins pendant quelques années) de bidouilles dans ce genre, plutôt que l’on demande brutalement à des millions d’utilisateurs d’adopter un système cassant la compatibilité. Je suppose que pour qu’un tel système voie le jour, il faudrait que je développe MediaWiki moi-même… Ça pourrait être une idée…

Frigory (discuter) 8 avril 2019 à 22:04 (CEST)

Avis de Histoire16022005

certains administrateurs se prennent pour dieu, il faudrait une police de la police...

Avis de Nattes à chat

J'aimerais pouvoir faire des mass message en tant qu'organisatrice d'évènement et je ne peux pas à moins d'être admin. Donc il faudrait dévopper cet outil pour des usages spécifiques, comme communiquer un horaire, un évènement. --— Nattes à chat ^[chat] 4 avril 2019 à 20:48 (CEST)

Avis de J. N. Squire

Il est irresponsable de la part de la WMF de ne pas prendre soin des testeur des Discussions Structurées, dont je fais partie. Ces personnes initialement enthousiastes qui s'attendaient à des améliorations rapides de l'outil sont restées sur leur faim pendant plus d'un an, sans communication dédiée, avant de découvrir que la WMF lançait une consultation pouvant mener à la suppression de l'outil avec les pires outils de communication possible (le Bistro est peu lu). L'image et la perception de sérieux de la WMF ont été sévèrement entamés, et je crains les réactions de rejets irrationnels à l'application des projets retenus, surtout si Discussions Structurées est mis à la poubelle.

Par pitié la WMF, embauchez des spécialistes en sociologie et en psychologie sociale dans vos équipes de communication/stratégie pour prendre soin de ceux qui vous font confiance pour tester des outils forcément buggués et imparfaits. -- J. N. Squire^{[Discussion constructive]} 5 avril 2019 à 19:34 (CEST)

Avis de Laurent piller

Je n'ai pas la prétention de changer quoi que se soit.

Mon niveau d'intelligence étant moyen,je tiens juste a vous féliciter pour ce fabuleux outil de connaissances.