Projet:KISS

N’hésitez pas à le relancer !

KISS : Keep It Simple, Stupid en anglais, mot à mot : « Garde ça simple, idiot ».

Le but du projet est de coordonner les efforts de simplification de l'édition de Wikipédia. Pas forcément au niveau logiciel, ce dont bien peu d'entre nous sommes capables, mais au niveau de l'application du principe KISS à l'édition de Wikipédia :

limiter le nombre de modèles à utiliser dans les articles ;
choisir des noms de paramètres explicites ;
limiter l'usage de modèles qui ne sont pas simplement compréhensibles pour les nouveaux (générant du texte ou des catégories, par exemple) ;
préférer des choix de présentation simple, aussi WYSIWYG que possible (acronyme anglais pour : « ce que vous voyez est ce que vous obtenez »).

Ce projet fait suite à plusieurs discussions, notamment sur le bistro Wikipédia:Le_Bistro/17_mai_2012#Kanji,_le_retour_de_la_vengeance, Wikipédia:Le_Bistro/18_mai_2012#Mazinger,_le_fils_du_Kanji et Wikipédia:Le_Bistro/11_juin_2012#Cochonneries_d'infobox_!, et à un sondage, Wikipédia:Sondage/modèles insérant du texte.

Dans ce but, vous pouvez lister dans la page de discussion les pages et/ou modèles posant problème, et proposer des solutions.

Quelques idées

Quand créer un nouveau modèle ?

ne pas créer ni importer un modèle sans s'être assuré qu'un modèle existant ne remplit pas une fonctionnalité similaire, qu'il y ait des différences de mise en forme ou non.
ne pas multiplier les modèles qui sont des variantes de la même fonctionnalité pour pouvoir varier la mise en forme du contenu.
évaluer la nécessité de chaque nouveau modèle, mettre en balance le surcroît de complexité qu'il entraîne et l'importance de ce qu'il apporte (simple mise en forme, autre)
favoriser les modèles qui facilitent l'édition, c'est-à-dire qui sortent des articles des syntaxes complexes rendant plus difficile les contributions (exemple : le modèle relevé météo)

Quand ajouter un nouveau paramètre ?

évaluer la nécessité de chaque nouveau paramètre d'un modèle existant, mettre en balance le surcroît de complexité qu'il entraîne et l'importance de ce qu'il apporte (simple variante de mise en forme, etc.)
ne pas multiplier les paramètres et variantes de mise en forme d'un même modèle (couleur, alignement, etc.)

Jusqu'où automatiser les modèles ?

ne pas créer de modèle produisant un texte rédigé générique (une phrase identique d'un article à l'autre, un paragraphe entier, etc.) : chaque contenu rédigé doit être librement modifiable en éditant l'article.
ne pas déporter dans des sous-modèles les contenus de tableau modifiables par les contributeurs : le contenu éditable doit se trouver soit directement dans l'article (les valeurs passées aux paramètres du modèle), soit dans le modèle lui-même (exemple : une palette de navigation) et non dans un sous-modèle appelé par celui-ci : chaque contenu de type données de tableau, de diagramme etc. doit être librement modifiable en éditant soit l'article, soit un modèle immédiatement modifiable depuis l'article (lien modifier adapté).
les capacités de la syntaxe wiki, des fonctions parseurs et des mots magiques sont limitées. Éviter de bricoler en les détournant pour obtenir à tout prix un modèle plus puissant. Si vous avez vraiment besoin de fonctionnalités puissantes, il faut apprendre et utiliser Lua.
les modèles ne servent pas à stocker des données. Éviter de simuler une base de données à l'aide d'un faux modèle : il existe Wikidata.

Comment coder les modèles ?

éviter les modèles dont le code devient trop complexe à force de mutualiser des cas trop nombreux : préférer des modèles spécifiques plus légers et plus aisés à maintenir
limiter la profondeur de sous-modèles (plus d'un niveau de sous-modèle est déjà à éviter si possible)
ne pas créer ou modifier de modèle sans le documenter ou mettre sa documentation à jour

Comment nommer les modèles ?

nommer explicitement le modèle et ses paramètres : il s'agit d'éviter d'imposer dans les articles un « {{nZFTr3 | pxw = | s1 = | s2 = }} »
s'il existe d'autres modèles avec des paramètres similaires, utiliser les mêmes noms de paramètres plutôt que des variantes inattendues
renommer raisonnablement : ce n'est qu'un nom de modèle à usage interne, ce n'est pas un drame s'il n'est pas conforme aux règles typographiques de l'Imprimerie nationale.

Voir aussi