Changeset 81239 in spip-zone


Ignore:
Timestamp:
Mar 6, 2014, 3:10:58 PM (5 years ago)
Author:
severo@…
Message:

tickets - MAJ arguments pour/contre la migration

de 7 champs de la table spip_tickets en mots-clés.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • _plugins_/tickets/trunk/README.md

    r81233 r81239  
    2121[ ] crayon d'assignation du ticket : afficher la trombinette si gravatar est activé dans le contrôleur -> Non, en tout cas, pas tant que le contrôleur sera un <select> (pas d'images dans les select)
    2222
    23 ## En cours
     23## En cours de discussion
    2424
    2525### Migration de 7 champs en groupes de mots clés
     
    2727Actuellement la table spip_tickets contient sept champs qui servent à décrire sémantiquement les tickets. Pour trois d'entre eux, les choix possibles sont fixés en dur dans le code : severite (bloquant, important, normal, peu_important), tracker (probleme, tache, amélioration) et navigateur (android, firefox...) Les quatre autres sont désactivés par défaut, et ne proposent aucun choix par défaut, mais il est possible d'en ajouter via la page de configuration ou les variables globales : projet, composant, version, jalon.
    2828
    29 Maintenant que les mots-clés peuvent être associés aux tickets, on a tout intérêt, pour faciliter la personnalisation de ces champs et des choix proposés, à migrer ces 7 champs sous la forme de mots/groupes de mots.
     29On pourrait migrer ces 7 champs sous la forme de mots/groupes de mots.
    3030
    31 Il sera ensuite possible aux responsables du site d'ajouter/modifier/supprimer des niveaux de sévérité du bug, par exemple, modifier la liste de navigateurs, voire également supprimer des critères (si tracker ou composant ne leur paraît pas utile, par exemple) ou en ajouter d'autres (thème du ticket, région géographique concernée, ou tout autre critère qui leur paraisse pertinent).
     31À noter que la création des mots-clés n'aurait lieu que lors de la migration, et pour une installation fraiche, aucun groupe de mots ne serait créé.
    3232
    33 À noter que ça ne vaut que pour la migration à la nouvelle version du plugin. Pour une installation fraiche, aucun groupe de mots créé.
     33#### Arguments contre la migration
     34
     35Plusieurs problèmes se posent :
     36
     37* gestion des langues (il faudra éditer tous les mots-clés si on ajoute une nouvelle langue, alors que dans le cas des champs, c'est géré par les fichiers de langue, puisque la liste des choix est fermée)
     38* tri des tables de tickets : comment choisir les colonnes à afficher si ce sont des groupes de mots-clés, et non plus des champs ? Tous les mots-clés ? Une sélection configurée dans la page de conf des tickets ? Aucun groupe ? Et pour chaque groupe affiché dans la table, comment gérer le tri par colonne dans ces cas ?
     39* risques de tout casser pendant la migration
     40* sortir de l'idée originale des tickets, faits pour du débuggage de logiciel, à la redmine.
     41
     42#### Arguments pour la migration
     43
     44Les avantages à migrer les champs sous la forme de mots/groupes de mots sont :
     45
     46* faciliter la personnalisation des champs et des choix proposés pour chaque champ (objets éditoriaux, au lieu de valeur en configuration = pénible à changer, ou en dur dans le code). Il sera ensuite possible aux responsables du site d'ajouter/modifier/supprimer des niveaux de sévérité du bug, par exemple, modifier la liste de navigateurs, voire également supprimer des critères (si tracker ou composant ne leur paraît pas utile, par exemple) ou en ajouter d'autres (thème du ticket, région géographique concernée, ou tout autre critère qui leur paraisse pertinent).
     47* github fait comme ça : chaque projet décide de la sémantique et la classification de ses tickets (encore plus à plat pour github : un seul groupe de mots)
    3448
    3549#### Partie base de données
Note: See TracChangeset for help on using the changeset viewer.