Action 3 - Organisation des plugins

J'ai fait un petit essai en ajoutant les champs extra "categorie" et "prefixe" ce qui permet dans l'espace privé de mieux comprendre à mon avis où on se situe. Je joins les captures d'écran.

1) La liste des rubriques. Je n'ai pas tout modifié mais uniquement deux secteurs qui représente les catégories date et auteur. Voir les cercles rouges.

2) Le secteur "auteur" : on voit le fil d'ariane, le contenu de la rubrique qui contient la valeur auteur. Ensuite pour les sous-rubriques on voit les catégories "auteur/connexion", "auteur/extension"... Enfin sous la rubrique "auteur/extension" on voit les plugins avec entre parenthèses le préfixe.

3) Enfin la rubrique d'un plugin (Adresse Jabber) avec l'affichage de son préfixe. Ce qui est dommage c'est que le fil d'ariane n'affiche pas l'alias de la catégorie mais ça peut être fait facilement.

oki pour cette solution :)

D'accord pour tout sauf un point :

une sous-sous-rubrique par plugin qui possède un champ extra "prefixe" rempli avec le préfixe dudit plugin

=> Les sous-sous-rubriques sont n'importe quel projet qui rentre dans la sous-catégorie, et ceux des projets qui sont des plugins ont le champ "préfixe" rempli, mais c'est donc optionnel suivant le projet. Et ces rubriques peuvent donc être automatiques ou semi-automatiques pour les plugins OU manuel quand le projet n'est pas un plugin (mais rentre quand même dans l'arbo principale).

Oui c'est possible mais j'avoue être toujours réticent à mélanger les projets en conception avec les plugins en production.
J'ai proposé de transférer les projets en conception dans l'arbo des plugins une fois le développement achevé en plugin ce qui permet de transférer l'arborescence complète en modifiant correctement les articles de conception pour ne pas les mélanger avec les articles utilisateurs à venir.

Mais c'est exact que l'approche que tu proposes peut fonctionner :
- on crée une rubrique projet x sans remplir le préfixe mais en l'identifiant par exemple dans le texte;
- on rédige des articles de conception (faut-il les tagguer "conception" ?)
- le plugin pouvant passer en production, on saisit le préfixe (ou on clique sur un bouton "Passer en plugin") et on crée un article "principal" en même temps que l'on taggue les articles existants en "conception" pour les identifier différemment.
C'est ce point qui me gêne si on ne trouve pas un moyen de s'assurer que ce sera fait.
Pour compléter le schéma on peut iconifier la liste des rubriques-plugin avec un icone plugin et les projets en cours avec un autre icone pour repérer ça plus facilement. Dans le dashboard dont j'ai déjà parlé on pourrait aussi faire un état des lieux des projets en cours et des projets récemment clos.

Oui, les articles de conception devraient être marqués de type conception immédiatement, c'est impératif. Car comme dit dans l'autre fil, ce n'est pas que pour l'intérieur de la rubrique-projet : ça vaut aussi pour l'accueil général du site.

À tout moment quand un nouvel article apparait, on doit pouvoir savoir de quel grand type il est, et l'afficher dans une liste différente. On ne doit pas afficher un article de conception (que ce soit pour un nouveau projet en cours ou une refonte) dans la même liste qu'une nouvelle doc d'utilisation, qu'un article principal d'un nouveau plugin, ça ne s'adresse pas aux mêmes. Donc ça vaut bien en permanence, dès qu'on crée l'article, que ce soit une nouvelle rubrique, ou un plugin déjà existant depuis longtemps.

En fait, j'ai un peu la même obsession depuis le début. Essayer de ne pas obliger à remplir un champ ou mot-clé pour chaque article qui soit impliqué dans l'organisation et la structuration de Contrib mais privilégier les rubriques beaucoup moins nombreuses.
Ne peut-on pas imaginer l'organisation suivante :
1) je suis dans une rubrique-plugin en "production" :
- les articles d'utilisation (normalement les principaux) sont directement dans la rubrique-plugin.
- les articles de conception sont dans une sous-rubrique identifiée comme telle (champ à définir)
- les articles d'actualité sont aussi dans sous-rubrique identifiée comme telle.

2) je suis dans une rubrique-projet (le préfixe est vide et le champ x défini conception):
- je fais des articles forcément de conception.
- je clos le projet dans un plugin : dans ce cas je crée la bonne rubrique-plugin avec le préfixe choisi et j'y transfère le rubrique-projet pour me retrouver dans la situation 1).

Ce qui est intéressant dans ce mécanisme c'est que l'on peut avoir une interface utilisateur pour s'assurer qu'on reste cohérent.

Une pièce à casser.

On peut avoir une interface pour s'assurer qu'on reste cohérent aussi
sans passer par le rubriquage. Et je dirais même, plus facilement, parce
qu'on déjà les outils techniques pour ca (champ extra obligatoire, ou
mot clé lié obligatoire)

Pour le 1) la plupart des plugins ont peu d'articles en tout, dans de très nombreux cas, yora quoi, 1 article de doc, et 1 article de conception peut-être. Ça parait sur-compliqué de devoir faire cette sous-organisation en plus à l'intérieur du projet, au lieu de juste ajouter un mot clé sur l'article.

Éventuellement, pour avoir moins de choses à typer, on peut partir du fait que tout ce qui n'a pas de type est une documentation. Et qu'on ne type donc que quand c'est de la conception, ou une annonce de nouveauté, donc carrément pas souvent.

De plus, avec la méthode de typer avec un mot (ou autre du genre), c'est la même méthode tout le temps, c'est à la fois beaucoup plus simple à comprendre pour les rédacteurs, mais aussi plus simple à manipuler dans les squelettes pour construire l'ergonomie qu'on voudra. Ya beaucoup moins de test à faire : ya le mot-clé "conception", c'est une conception, point. C'est pas dans un cas faut "deviner" que c'est conception parce que pas plugin fini, puis ensuite la méthode change et c'est en rangeant autrement, etc. Non, explicite et toujours la même manière. Plus simple pour tout le monde à mon avis.

Oui c'est une bonne remarque.
Par contre, deux choses :
- je pense qu'il vaut mieux préremplir avec utilisation plutôt que de laisser vide, c'est toujours plus simple à tester.
- je serais plus pour utiliser un champ obligatoire comme préfixe, par exemple, type_article, afin de laisser les mots-clés uniquement pour de la sémantique non obligatoire.

Après, un jeu d'icone ou de couleur ou autre pourrait être utile pour visualiser rapidement le type d'article en plus du libellé.
Bon encore un pas de plus. Je vais essayer de faire un résumé demain pour tenter une conclusion rapide sur ces sujets.

je vois deux avantages aux champ extra par rapport aux mot clé:
- en terme d'interface, c'est immédiatement lors de la rédaction
- en terme de requetage, et donc de filtrage, pas besoin de table de liaison > plus optimal

pour un site associatif on utilise cela pour étiquetter, et je trouve ca plus pratique