Améliorer l'usage des tags

Salut tout le monde,

Pour ceux qui ne le savent pas, je suis un contributeur technique régulier de Zeste de Savoir et parmi mes nombreuses contributions, il y en a une qui m'intéresse tout particulièrement en ce moment : le centre de notifications. La spécification du centre de notifications (la ZEP-24) indique qu'il doit être possible de suivre un tag et c'est sur ce point précis que j'aimerais discuter un peu.

Aujourd'hui, les tags sont utilisés pour les contenus (articles, tutoriels, tribunes prochainement) et les sujets des forums. Techniquement, c'est la même chose (utilisation du même modèle). Fonctionnellement, on en est vraiment pas loin (hormis le fait qu'un tag créé pour un sujet n'existe pas forcément pour les contenus et inversement).

Sachant ça, j'aimerais énoncer 3 problèmes avec le système actuel qui m'amène à vous solliciter aujourd'hui :

• Les tags des forums sont difficilement accessibles : L'URL d'un tag est sous la forme suivante /forums/sujets/tag/2/java/. Comme il n'existe aucune page qui liste tous les tags (comme le propose les contenus) et que nous ne pouvons pas connaitre l'identifiant d'un tag, on ne peut pas deviner l'URL d'un tag. Et quand bien même cela serait possible, cela ne serait pas ergonomique.
• Les tags des contenus ne s'utilisent pas comme ceux des forums : Cela peut sembler normal. Après tout, même si techniquement ce sont les mêmes modèles, cela n'implique pas forcément que fonctionnellement cela soit pareil. Oui … mais non. Aujourd'hui, nous avons 3 URLs pour les tags des contenus /tutoriels/?tag=zds, /articles/?tag=zds et /contenus/?tag=zds. On remarque que l'identifiant ne doit pas être renseigné (ça implique de faire la requête sur le titre du tag et non pas sur son identifiant) et même si on comprend aisément à la lecture des URLs le scope de la recherche, en pratique la navigation porte à confusion. Il m'arrive régulièrement de me retrouver dans un contexte générique (contenus) alors que je venais d'un contexte plus spécifique (tutoriels ou articles). C'est perturbant.
• La création des tags est hors de contrôle : Que cela soit sur les forums ou les contenus, nous devons spécifier nos tags entre des crochets au début de nos titres (non ergonomique), il n'existe aucune auto-completion ce qui engendre très souvent des duplications (par exemple, android, android - wip, java android, java, etc.). Il y a d'autres inconvénients mais cela me prendrait trop de temps de tous les lister.

Pourquoi est-ce ennuyant pour moi ?

C'est vrai, je pourrais me contenter de prendre la page d'un tag et de lui ajouter un bouton "Suivre ce tag" mais c'est pas dans ma façon d'être de mettre des fleurs sur du caca. J'aimerais donc avoir un avis ou des propositions quant aux améliorations que nous pourrions apporter pour uniformiser les tags à travers les types de contenu et améliorer l'ergonomie de cette fonctionnalité pourtant très intéressante.

Me concernant, voici mon avis:

Pour le premier et le second point:

• Même si une recherche par chaîne de caractère est plus éprouvante qu'une recherche par pk (ZEP-12 powaa), je trouve que les URL des "contenus" sont plus "facile" pour un être humain lambda. Je partirai là dessus. Par contre, je serait pour un truc du genre /tag/zds/?type=article, par exemple (ce qui rejoint ma proposition juste après).
• Pour moi, il devrait exister une page reprenant les contenus ET les messages de forum associés à un tag. Ça permettrait de faire le pont entre les deux, et ce serait probablement ça qu'il faudrait faire suivre ("oh, 3 nouveaux messages pour le C++ et un nouveau tuto !"). Et comme pour la page de recherche, on pourrait ensuite faire le tri tuto/article/fofo.
• Du coup, ça serait aussi sympa à intégrer à la recherche.

Pour le 3ième point:

• Malgré que c'est un peu le bordel, le fait de préciser ces tags directement dans le titre est pour moi un avantage: je pense que les tags seraient beaucoup mois employés si, comme pour les contenus, il fallait les sélectionner. On pourrait s'arranger avec de l'auto-complétion, mais il faudra bien faire attention à ce qu'on fait.
• Une autre idée, c'est de tagger à posteriori: hier, quelqu'un à fait remonter une issue qui demandait de tagger automatiquement selon le language employé. Avec un peu de code un peu tordu, on pourrait proposer à l'utilisateur "nous pensons que les tags suivants sont d'application, est-ce que c'est correct ?" (c'est très difficile à mettre en place, je propose juste ce qui me passe par la tête).
• On peut donner le pouvoir aux modos de corriger les tags. C'est très réverbatif comme activité, et beaucoup trop tard vu la masse de sujets déjà créé et qui sont créés par jour.
• Un mix des deux précédentes: on donne aux modo le pouvoir de tagger en fonction du contenu, donc une liste pré-faite via analyse du contenu du topic, que le modo pourrait valider au passage.
• On peut aussi faire des "association de tags", c'est à dire mettre ensemble le tag "android" et "java android", par exemple (encore qu'on me dira que quelqu'un qui poste un problème avec son GSM dans "bug et suggestions" en à probablement rien à f*** de java). Le problème, c'est que c'est un être humain qui doit faire ce genre d'associations, et qui devrait le faire souvent. En pratique, ça me semble ingérable (je sais pas combien de centaine de tags on a actuellement, mais probablement déjà trop).
• Il y a bien entendu la solution "radicale", à savoir une liste de tag prédéfinie et fixée. Quasiment impossible à mettre en place sans se taper une liste de "il manque ce tag là".

Donc j'avoue que là, je sèche un peu.

Il serait aussi possible de proposer, lors de la rédaction d'un sujet sur le forum, la liste des tags les plus utilisés dans cette catégorie (et par exemple permettre de cliquer dessus pour les associer au sujet).

Je suis d'accord sur l'idée, mais dans les faits, on a des forums qui couvrent de très grosses catégories ("site web", par exemple), ce qui à mon avis va limiter l'effet. Mais oui

Quand on a spécifié la ZEP-25 qui introduit les tags sur les contenus, on a décidé deux choses.

1) Ne pas fusionner les tags des contenus et ceux des forums. En effet, ils ne coïncident pas nécessairement. Par exemple, « maths » ou « mathématiques » est un tag sur les forums, mais une catégorie sur les contenus : le tag « mathématiques » des contenus n’existe que pour des raisons historiques liées au changement de système, et devrait en bonne logique disparaître à terme.

A contrario, « Multimédia et Jeux vidéo » est une catégorie sur les forums, alors qu’il s’agit de tags sur les contenus, globalement à cheval entre les catégories « Programmation » et « Arts, graphisme et multimédia ».

Enfin, un certain nombre de tags des forums n’auraient vraiment aucune raison d’être sur les contenus, comme « bug », « suggestion » ou encore « zep ».

2) Autoriser les validateurs à exercer un contrôle a posteriori sur les tags utilisés. Et ceci, afin d’éviter que trop de tags ne fleurissent, et surtout des doublons. La question avait été rapidement abordée d’étendre ce contrôle aux tags des forums, mais a été abandonnée à cause de l’aspect rébarbatif (et par « *réverbatif » ) du travail.

On pourrait envisager de la remettre au goût du jour, au minimum pour essayer de limiter les doublons. Mais sans une page « Tous les tags », cela va s’avérer compliqué. Il faut également garder à l’esprit que de nombreux sujets ne sont tout simplement pas tagués (je dirais 1/3, au pifomètre) : il y aurait vraiment un gros boulot à faire, même sans chercher à rattraper le passif.

Se pose également le problème d’une hiérarchie des tags : une recherche sur le tag « chimie » devrait-il renvoyer les contenus et sujets de forum tagués comme « chimie organique » ? À mon avis, oui. Mais comment définir cette hiérarchie sémantique entre tags ?

Bref, tout ça pour dire que ce débat va au-delà de la simple question des tags, et que ce serait peut-être l’occasion de réactiver la ZEP-15.

PS : félicitations, les enfants ! Vous venez de redécouvrir un des plus grands et éternels problèmes de la bibliothéconomie.

• Même si une recherche par chaîne de caractère est plus éprouvante qu'une recherche par pk (ZEP-12 powaa), je trouve que les URL des "contenus" sont plus "facile" pour un être humain lambda. Je partirai là dessus. Par contre, je serait pour un truc du genre /tag/zds/?type=article, par exemple (ce qui rejoint ma proposition juste après).

On pourrait donc imaginer un module "tag" avec ses vues et ses personnalisations en fonction du contenu. J'aime bien extraire des modules du module utilitaire actuel.

• Pour moi, il devrait exister une page reprenant les contenus ET les messages de forum associés à un tag. Ça permettrait de faire le pont entre les deux, et ce serait probablement ça qu'il faudrait faire suivre ("oh, 3 nouveaux messages pour le C++ et un nouveau tuto !"). Et comme pour la page de recherche, on pourrait ensuite faire le tri tuto/article/fofo.

Comme le dit Dominus, ça poserait des problèmes. Finalement, fonctionnellement, ils sont moins comparable que je le pensais.

• Du coup, ça serait aussi sympa à intégrer à la recherche.

Rien que d'y penser, ça me démoralise d'intégrer ça à solr …

• Malgré que c'est un peu le bordel, le fait de préciser ces tags directement dans le titre est pour moi un avantage: je pense que les tags seraient beaucoup mois employés si, comme pour les contenus, il fallait les sélectionner. On pourrait s'arranger avec de l'auto-complétion, mais il faudra bien faire attention à ce qu'on fait.

Je ne suis pas d'accord. C'est vrai que nous renseignons l'usage dans le champs du titre mais je ne pense pas qu'un utilisateur va éviter un champs, sans même le regarder. Puis, rajouter ce champs nous permettrait d'appliquer un style et de faire une recherche sur les tags pendant que l'utilisateur le remplit.

• Une autre idée, c'est de tagger à posteriori: hier, quelqu'un à fait remonter une issue qui demandait de tagger automatiquement selon le language employé. Avec un peu de code un peu tordu, on pourrait proposer à l'utilisateur "nous pensons que les tags suivants sont d'application, est-ce que c'est correct ?" (c'est très difficile à mettre en place, je propose juste ce qui me passe par la tête).

Il faudrait lister tous les critères d'analyse pour pouvoir rechercher des tags appropriés mais cela reste une solution pas évidente à développer.

• On peut donner le pouvoir aux modos de corriger les tags. C'est très réverbatif comme activité, et beaucoup trop tard vu la masse de sujets déjà créé et qui sont créés par jour.
• Un mix des deux précédentes: on donne aux modo le pouvoir de tagger en fonction du contenu, donc une liste pré-faite via analyse du contenu du topic, que le modo pourrait valider au passage.
• On peut aussi faire des "association de tags", c'est à dire mettre ensemble le tag "android" et "java android", par exemple (encore qu'on me dira que quelqu'un qui poste un problème avec son GSM dans "bug et suggestions" en à probablement rien à f*** de java). Le problème, c'est que c'est un être humain qui doit faire ce genre d'associations, et qui devrait le faire souvent. En pratique, ça me semble ingérable (je sais pas combien de centaine de tags on a actuellement, mais probablement déjà trop).

Malheureusement, ces 3 points ne sont pas faisables.

• Il y a bien entendu la solution "radicale", à savoir une liste de tag prédéfinie et fixée. Quasiment impossible à mettre en place sans se taper une liste de "il manque ce tag là".

C'est une solution trop radicale. Par contre, je serais pour m'inspirer de StackOverflow et permettre seulement à des utilisateurs confirmés de créer de nouveaux tags.

Se pose également le problème d’une hiérarchie des tags : une recherche sur le tag « chimie » devrait-il renvoyer les contenus et sujets de forum tagués comme « chimie organique » ? À mon avis, oui. Mais comment définir cette hiérarchie sémantique entre tags ?

Cela me semble être un tout autre problème mais on pourrait imaginer la création de tags dépendant d'un autre tag, qui deviendrait alors son tag parent et qui instaurerait cette hiérarchie.

Bref, tout ça pour dire que ce débat va au-delà de la simple question des tags, et que ce serait peut-être l’occasion de réactiver la ZEP-15.

Je me note cette ZEP. Merci du lien.

Rien que d'y penser, ça me démoralise d'intégrer ça à solr …

Pour moi, la première étape de toute évolution avec Solr est de remplacer Solr par une version récente d'ElasticSearch, qui est infiniment plus simple à gérer.

Salut, J'ai pas tout lu mais pour moi la suggestion de tag permetrai de regler plusieurs problème :

Les fautes d'orthographes

Les tags de flemard (algo pour algorithmes)

Et eviterai les tags du genre [android java] car les crochets du premier tag seraient fermés automatiquement.

Cependand je suis pour un système de suggestion qui n'impose rien. (Et encore moins une liste de tag fixé)

Récemment, j'ai posté une suggestion; je voulais mettre le tag 'suggestion'… et je n'ai pas su le faire. Là, en re-testant, je vois que l'écran de saisie affiche une aide *[tag1][tag2] Titre du sujet * mais au moment où j'ai voulu mettre un tag, cette aide avait bien entendu disparu. Laisser cette aide visible serait utile pour les utilisateurs non-réguliers. Ou même mieux, mettre 2 ou 3 champs de saisie facultatifs dédiés pour les tags.

Et ces champs de saisie dédiés aux tags pourraient même proposer de la saisie assistée, pour éviter les tags de flemmards évoqués par cbourree.

Sur les 20 derniers sujets postés dans le forum suggestion, 7 n'ont pas de tag …

Dans le but d’appuyer un peu la réflexion sur l’encadrement des tags du forum, j’ai bidouillé un peu de Perl dégueulasse, et je suis parvenu à faire une liste globalement alphabétique de tous les tags utilisés sur les forums (à part les forums cachés, bien sûr).

La première constatation, c’est qu’il y a beaucoup de tags. 1900 tout rond au moment où j’ai fait l’extraction (le 3/08/2016 entre 16h17 et 16h20 pour être précis). Le but serait évidemment de rationaliser tout cela, ce qui devrait permettre de réduire le nombre de tags.

Je vois un certain nombre de situations types, à vous de me dire si vous pensez à d’autres choses.

1. Quelqu’un n’a pas bien compris le fonctionnement des tags et en a fusionné plusieurs en un seul. Exemple type : android - wip, qui devrait être séparé entre un tag android et un tag wip.
2. Problème inverse, deux tags séparés qui n’ont pas de sens séparément et devraient être fusionnés. Exemple type : ian et murdock qui devraient être un seul tag Ian Murdock.
3. Deux tags identiques, au détail près que l’un est au singulier, l’autre au pluriel. Exemple type : livre et livres, qui devraient être fusionnés en livre. La plupart du temps, préférer la forme singulière.
4. Deux tags identiques, aux espaces près. Exemple type : archlinux et arch linux. Préférer la forme officielle, ici, Arch Linux.
5. Des erreurs manifestes d’orthographe. Exemple type : algorythme ou encore javascrip. Seule solution envisageable, la correction.
6. Deux tags correspondant à des concepts très proches, qu’il vaudrait sans doute mieux fusionner. Exemple type : impression 3d et imprimante 3d.
7. Plusieurs tags correspondant à une abréviation et sa forme développée. Exemple type : app, applis et application. Je pense que dans la plupart des cas, il vaut mieux favoriser la forme pleine.
8. Deux tags correspondant au même concept, mais dans des langues différentes. Exemple type : défi et challenge, ou encore logiciel et software. Sauf raison valable, je recommande de fusionner vers le terme français.
9. Un tag beaucoup trop spécifique, qui devrait disparaître purement et simplement. Exemple type : probleme d'alert.
10. Un tag qui peut sembler utile, mais qui dans le contexte du sujet où il est utilisé, devrait être remplacé par un autre plus clair/adapté. Exemple type : les tags amélioration, améliorations et améliotation qui devraient être replacés par suggestion.
11. Un tag qui devrait être renommé pour être plus clair, et dont la version renommée n’existe pas encore. Exemple type : arpg, qui devrait s’appeler action RPG. L’idéal serait de pouvoir le renommer directement dans la base de données, pour ne pas créer un nouveau tag en le renommant directement dans le sujet.
12. Dans le cas des tags de logiciel, on se retrouve confronté au problème des versions. Certains en ont fait un tag séparé, comme 2.x, d’autres intègrent la version dans le tag, comme python2.7. Mais ça peut devenir carrément difficile, comme dans le cas de apache 2.4.17, ou dans celui des tags debian, debian 7, debian8, debian jessie et debian sid. La solution idéale, ce serait d’avoir des tags hiérarchisés et de classer les différentes versions et sous-versions sous le tag de base. Mais pour l’instant la techno n’existe pas, et je ne sais pas quoi proposer comme solution.

Ça réfléchit

Bon, vu que ça a l’air de plaire, suite de la réflexion. J’ai ajouté deux nouveaux éléments à la liste, les numéros 2 et 4.

Par ailleurs, j’ai réfléchi au problème des versions (point 12) et j’en suis arrivé à la conclusion suivante : le plus simple, en attendant d’avoir éventuellement un jour des tags hiérarchisés, c’est de conserver des tags séparés quand on a besoin de préciser une version. Je suggère les règles suivantes.

1. Ne préciser la version que si c’est pertinent au regard du sujet abordé. Par exemple, pour une question générique sur les liens en HTML, le tag html suffit, pas besoin de préciser html 4 ou html5.
2. Utiliser la version la plus large possible qui reste pertinente. Par exemple, python 3 pour préciser qu’on ne veut pas réponses valables pour Python 2, et python 3.4 seulement pour les questions qui seront valables sous Python 3.4 mais pas sous Python 3.3.
3. Préférer symfony 3 à symfony 3.x.
4. Préférer les versions numérotées aux version nommées, par exemple Debian 8 plutôt que Debian Jessie, sauf bien sûr quand le numéro n’existe pas ou serait incompréhensible, par exemple, Windows Vista.
5. Mettre une espace entre le nom du logiciel et le numéro de version, sauf quand l’absence d’espace est ultra-majoritaire dans l’usage, par exemple, html 4 mais html5.

Autres réflexions, qui s’adressent plus spécifiquement à Andr0, puisque cela concerne la gestion des tags en interne.

• Je suppose qu’il y a des raisons techniques derrière, mais c’est à mon avis une mauvaise idée que le nom des tags (leur nom, pas leur slug) soit systématiquement mis en minuscules. Quel est l’intérêt de conserver les diacritiques si on ne peut pas avoir les majuscules à un nom propre ? Si on a un nom compréhensible par l’ordi (le slug) et un nom présentable pour les humains, il faut que celui-ci soit entièrement correct, pas seulement à moitié.
• Arrête-moi si je me trompe, mais la première orthographe utilisée pour un tag fixe la forme lisible par un humain, et tous les tags considérés comme équivalents y seront rattachés, sans possibilité de le modifier. On se retrouve ainsi avec le tag electronique sans accent, alors que électricité a tous les siens, et electrocinétique n’en a qu’un sur deux. Une interface permettant au staff de modifier à posteriori un tag, et de répercuter sur tous les sujets concernés, serait certainement appréciable.
• Si on met en place des tags hiérarchisés, on va assez vite se trouver confrontés au problème des homonymes : par exemple, « go » désigne à la fois le langage de programmation et le jeu. On peut envisager plusieurs manières de les distinguer, soit à l’aide des majuscules (Go pour le langage), soit en réservant go au jeu et golang pour le langage, soit en précisant explicitement go (jeu) et go (langage). Mais en tout état de cause, il faudra réfléchir sérieusement au problème, et la solution nécessitera peut-être un changement du fonctionnement des tags individuels.

Ça agit

Sur ce, je voudrais vous inviter à participer à la rationalisation des tags de ZdS. Pour ce faire, j’ai créé un brouillon d’article qui recense tous les tags accessibles publiquement sur les forums, et qui pourra servir à décider quel sort leur faire subir, parmi les 12 choix proposés dans le message précédent.

Je vais de ce pas ajouter tous ceux qui ont participé à la discussion ou aux votes comme auteurs, à la condition près que j’aie à peu près idée de qui vous êtes : on est entre gens de bonne compagnie, et l’historique permet de rattraper les bêtises, mais une suppression est si vite arrivée… De même, si vous voulez participer au travail de classement des tags, vous n’avez qu’à demander, et je vous ajoute sous les mêmes conditions.

Ceux qui ont des pouvoirs magiques n’ont pas besoin de moi pour accéder au brouillon et le modifier. Nous, en revanche, nous aurons besoin de vous pour appliquer les changements proposés. Sauf bien sûr si quelqu’un a la possibilité de faire faire cela par un script.

Enfin, pour terminer, un petit avertissement.

Juste pour dire que je n'ai pas le temps et que je ne suis pas intéressé par le sujet, donc que je me suis retiré de l'article.

Pas de problème. J’ai raflé tout le monde histoire de dire, mais si vous n’avez pas envie de participer, c’est pas grave, on vous en voudra pas.

Faut-il privilégier les abréviations dans certains cas ? Par exemple, j’ai changé zestedesavoir et zeste de savoir en zds et je me pose la question pour assembleur et asm.

Personnellement, je préférerais assembleur, car asm ne parle pas à tout le monde. Je dirais que conserver l’abréviation devrait être l’exception, à justifier : par exemple, zeste de savoir et zestedesavoir n’ont qu’un sujet chacun, alors que zds en a 61, clairement, les gens ont fait leur choix.

Parfait alors (et enlever le x86 pour assembleur ne me semble pas gênant). Je vois un autre problème avec algorithme et algorithmique. Les deux sont à peu près autant utilisés et pour le moment on garde les deux. Il faudrait n’en garder qu’un seul.

Parfait alors (et enlever le x86 pour assembleur ne me semble pas gênant).

D’autant qu’il y a un tag x86 séparé, donc autant en profiter.

Je vois un autre problème avec algorithme et algorithmique. Les deux sont à peu près autant utilisés et pour le moment on garde les deux. Il faudrait n’en garder qu’un seul.

D’où ma double proposition. N’hésite pas à mettre ton avis / tes commentaires directement dans l’article, c’est le meilleur moyen qu’on s’y retrouve. Et on verra bien ce qui finit par l’emporter.

Je n'ai pas accès à l'article, mais je trouve l'initiative très intéressante et bonne.

Du coup, j'aimerais juste revenir sur les systèmes de version, sachant que je me vois mal "surveiller" plusieurs tags juste pour une technologie appelée à évoluer…

Reprenons l'idée de Symfony. Je cherche volontiers les nouveaux sujets "pertinents" avec le simple tag [symfony], (voire sa forme non-recommandée [sf] que je semble être le seul à avoir utilisée  ) plutôt que de rechercher tous les tags potentiels [symfony 2], [symfony 2.6], etc.

Avec ce qui est en préparation, est-ce que la version finale serait plutôt :

• un dédoublement des tags ([symfony][symfony 3] — que je serais tenté de proposer comme solution actuelle) ?
• le tag de version uniquement ([symfony 3.2]), avec un système qui permettrait que si on recherche le tag [symfony], les tags [symfony x] et autres [symfony x.x] sortent aussi ?
• le tag du nom et un tag de version ([symfony][3.2]), avec une possibilité de rechercher une combinaison de tags ?

Je viens apporter mon grain de sel.

Malgré que c'est un peu le bordel, le fait de préciser ces tags directement dans le titre est pour moi un avantage: je pense que les tags seraient beaucoup mois employés si, comme pour les contenus, il fallait les sélectionner. On pourrait s'arranger avec de l'auto-complétion, mais il faudra bien faire attention à ce qu'on fait.

Je ne suis pas d'accord. C'est vrai que nous renseignons l'usage dans le champs du titre mais je ne pense pas qu'un utilisateur va éviter un champs, sans même le regarder. Puis, rajouter ce champs nous permettrait d'appliquer un style et de faire une recherche sur les tags pendant que l'utilisateur le remplit.

La version actuelle du champ est contre-intuitive aussi : les gens s'attendent à ce que les tags apparaissent comme ils les ont saisis : juste avant le titre. En conséquence, on a le titre qui n'est pas suffisant pour comprendre de quoi il s'agit et ce sont les tags qui donnent nombre d'infos essentielles.

Là où ça devient un problème, c'est que les tags ne sont pas affichés directement devant le titre, voire pas affichés du tout. Quand je viens sur le site depuis mon téléphone portable, c'est un peu la merde. Je vois un sujet « Problème avec mon jeu » (exemple fictif) sans sa tripotée de tags « [compilation][unity][c++] » : du coup on n'y comprend rien au premier coup d'œil.

Du coup je suis très gros partisan de la séparation du champ en deux :

• un champ titre, ce qui donnerait pour mon exemple fictif « Problème de compilation en C++ avec Unity ».
• un champ pour les tags séparés par des virgules, facultatif. Il faudrait dans l'idéal indiquer que ça sert à trier les sujets uniquement, pas à qualifier le titre. Dans mon exemple, ce serait « C++, Unity ». Si les gens savent pas quoi mettre, ils mettent rien, puis au pire, quelqu'un leur conseillera d'en rajouter.

Édit. : Exemple tout frais du problème.

Je n'ai pas accès à l'article

Tu veux participer ? Il suffit de demander.

Ça. Sachant que le fameux système ne sera pas mis en place tout de suite, évidemment, y’aura une période où il faudra continuer à suivre plusieurs tags. Sachant aussi que, autant que possible, à moins que le sujet soit vraiment lié à une version précise, on privilégiera le tag de base symfony.

Je pense que dans la plupart des cas, il vaut mieux favoriser la forme pleine.

Qu'en est-il du cas de maths ? Cette étiquette est beaucoup plus utilisée que mathématiques. Est-ce préférable de la garder ?