Action 8 - Typologie des articles

Proposition :
- Documentation utilisateur·ice
- Documentation intégrateur·ice
- Documentation programmeur·euse

A mon sens, les élèements de conception SONT de la documentation. Mais @rastapopoulos a je crois une autre vision

Je renouvèle mon alerte sur l'utilisation des mots clés qu'il faudra appliquer à des centaines d'articles. Forcément cela dérivera et les mécanismes basés dessus deviendront quelque peu caduques.
Je pense que le rubricage est bien plus efficace et pérenne pour identifier les différentes documentation de plugins, de carnet et de projets.
Le mot-clé doit être un plus qui apporte de l'information supplémentaire mais qui ne casse pas la logique si il n'est pas présent.

je suis d'accord avec toi pour les problèems de mot clé s'ils ont une fonction thématiques (ce dont parle tel ou tel article), pas s'ils ont une fonction de nature (le type d'article dont il s'agit)

J'ai l'impression que je dis exactement le contraire non (corrige moi si j'ai mal interprété) : thématique => mot-clé, type => pas de mot-clé.

ah donc on est pas d'accord. Je vois pas l'interet d'avoir des mot clé thématique si on une arborescence hiérarchique par catégorie

Parce que tu ne peux pas tout exprimer en une arborescence. Si tu lis le message que j'ai envoyé hier sur la méthode que j'ai adoptée pour revoir les catégories, j'ai pris le parti d'éviter de ranger les plugins dans une catégorie "outil" qui finalement est devenue un fourre-tout innommable. Donc, si je range les outils dans une catégorie qui exprime leur fonctionnalité, je peux avoir envie de savoir que c'est un outil et pas une fonctionnalité utilisateur. Et là un mot-clé fait l'affaire car si je l'oublie et bien c'est dommage, je perd de l'information, mais ça ne m’empêche pas d'avoir une arborescence correcte.

C'est un peu comme ça que je vois l'organisation finale, mais ce n'est que ma vision.

Là on ne parle absolument pas de rangement donc non aucun rapport avec l'arborescence, avec la hiérarchie des rubriques. Et d'ailleurs pour ça peut-être changer le titre de la discussion : je ne parlerais pas de catégories du coup (rangement) mais de typage/typologie des articles (à quoi ils servent et non pas de quoi ils parlent).

Là on parle de permettre (mot-clé ou autre peu importe) la distinction du type d'article, afin de pouvoir très concrètement changer l'ergonomie du site, et notamment l'ergonomie de deux endroits principaux :
1) la page d'accueil générale
2) l'accueil d'un projet précis (plugin ou pas)

L'idée étant dans ces deux endroits de distinguer très clairement, du premier coup d'œil, ce qui est de l'aide pour utiliser, ce qui est de la conception technique, ce qui est de l'actus pour informer d'une nouveauté. Et ça ça n'a aucun rapport avec le rangement : on parle bien de type d'articles dans un MEME plugin, un même projet (donc dans la même rubrique).

On n'est absolument pas d'accord pour le moment avec @maieul sur ce typage. :)

Comme dit ailleurs, je pense qu'il en faut 5 grands maximums, et j'en vois seulement 3 pour l'instant. À mon sens il ne faut surtout pas détailler, mais bien faire quelques grands types quand le sens n'est pas du tout le même.

Par exemple, la doc d'utilisation d'un plugin, et un tutoriel pas-à-pas ou un screencast, ce n'est pas la même manière de rédiger, mais ça sert à la même chose et c'est destiné à peu près à la même personne : expliquer comment utiliser. Donc ça DOIT être dans le même type, et il ne faut pas détailler.

C'est pour cela que moi je voyais seulement :
- conception
- documentation
- actualité

Le mot "documentation" si tu vas par là @maieul ça peut être n'importe quoi en fait, car "documenter" c'est tout, dès qu'on écrit on documente, qu'on parle à l'utilisateur ou qu'on explique la conception technique à des devs. Je ne suis pas contre reformuler, mais mon découpage serait le même. Par exemple :
- conception
- aide
- actualité

Un article de conception peut être écrit avant même qu'il y ait le moindre code, mais pourtant le projet existe, que ce soit la création d'un plugin ou la refonte ergo d'un site de la galaxie. Mais ça peut aussi être après dans un projet déjà existe, pour la refonte d'un plugin par exemple, ça reste de la conception aussi.

La documentation (ou l'aide), c'est pour expliquer comment l'utiliser, que ce soit dans l'interface, dans des boucles, ou même pour une API en PHP pour des dévs.

L'actualité c'est des tous petits articles, pour dire qu'on a ajouté une fonctionnalité à un plugin existant par exemple. Ça nous déculpabiliserait et on fera plus d'annonces de ce genre, alors qu'on ne le fait à peu près jamais actualitement. Mais on le fera enfin souvent si ces articles n'étaient pas du tout mélangé au reste, et présentés dans une liste à part.

Donc voilà, moi je ne vois vraiment que ces trois là, sans détailler plus.

ok, je vois plus clair. Pour répondre rapidement.
- catégorisation ou typage, peut me chaud le terme, du moment qu'on est d'accord que ce n'est précisement pas une arborescence
- effectivement, documentation pourrait s'entendre au sens très large. Cela étant, après refelxion, je pense que "documentation" est mieux "qu'aide" car les gens l'entendent spontanéemnt au sens restreint
- ok pour pour ta tripartition.

Oui je plussoie.

Je propose comme Rasta qu'on parle de catégorisation pour les plugins au sens de l'organisation des rubriques. Pour les articles le terme typologie me parait très bien adapté.
D'accord aussi pour les 3 types, je pense qu'on pourrait remplacer aide par utilisation qui je trouve fait mieux le pendant à conception.

Je pense qu'on commence à s'approcher d'une vision d'ensemble de l'organisation des rubriques et des articles.

la typologie devrait être obligatoire : groupe de mot clé "impératif" + plugin "mot obligaoire" non?