Difference: LesQuestionsReunion1 ( vs. 1)

Revision 12013-06-03 - AndreSchaaff

 
META TOPICPARENT name="LesQuestions"

Objectif de la réunion

Le but de la première réunion est de remettre à plat le fonctionnement actuel du compte Question, donc de revoir l'ensemble du processus allant de la formulation de la question jusqu'à la réponse définitive d'une personne du CDS. Il est également prévu d'aborder rapidement l'aspect outil afin de trouver une alternative (outils avec système de ticket par exemple) à une gestion via un WebMail. Il serait également intéressant de discuter des possibilités d'exploitation des questions, des réponses ainsi que d'autres données sous forme de base de connaissances afin de faciliter le travail des personnes en charge du compte à un instant donné.

Compte-rendu

Suite à la première réunion nous avons donc la feuille de route suivante :

  • installation de RT et osTicket
  • une première phase de tests courte afin d'adapter au mieux les 2 outils (on pourrait appeler cela une phase de calibrage des outils)
  • une phase plus longue (jusqu'à 2 mois) de tests en situation réelle simulée

  • un bilan des 2 outils
  • un choix définitif et une mise en production

La partie technique ne devant pas prendre le pas sur l'aspect "processus de traitement des questions" mais étant tout de même intimement liée à ce dernier il faudra prendre en compte un certain nombre de remarques issues de cette première réunion. La mise en place d'un outil de gestion de tickets s'accompagnera de facto d'une remise à plat de la gestion actuelle du compte Question.

(osTicket (http://osticket.com/, un outil open source simple à mettre e oeuvre et à utiliser) et RT (Request Tracker) utilisé par le CRC et qui offre des fonctionnalités plus étendues)

Remarques/questions (sans ordre de priorité):

(pour lever les ambiguïtés , le terme "utilisateur" représente la personne qui a soumis une demande au Compte question, le terme "outils" fait référence à RT et osTicket)

au niveau d'un utilisateur

  • passage uniquement par un formulaire, phase mixte, réponse automatique, etc. (il y a un rapport direct avec l'évacuation au maximum des spams qui représentent une partie extrêmement importante des messages) (une piste : mixte au départ avec une annonce explicite dans les réponses ("à partir de telle date vous devrez saisir vos questions / messages via l'interface Web dédiée") avant le passage définitif au système de tickets (à partir de là : une réponse automatique aux messages via mails "merci d'utiliser l'interface Web...")
  • possibilité d'échanger des messages hors du système avec réintégration des messages
  • l'envoi d'un ticket avec un numéro de confirmation est-il suffisant (doit-on / peut-on inclure une copie du message initial ?) ?
  • les outils permettent de fixer des délais raisonnables de réponse et d'alerter automatiquement en cas de dépassement et d'envoyer éventuellement un deuxième messages à l'utilisateur afin de lui préciser que son message est en cours de traitement et non oublié
  • utilisation de captcha ?
  • ...

au niveau interne :

  • gardera-t-on à terme "une personne en charge de question à un instant donné" ?
  • quelle granularité au niveau des groupes ? (Aladin, VizieR, Simbad, ... certains messages s'adressant plutôt aux astronomes et d'autres aux développeurs pour un même service), est-il possible de faire suivre le message à un groupe ainsi qu'à la personne "de garde" ?
  • les réponses prédéfinies (à creuser)
  • l'envoi de pièces jointes vers l'utilisateur
  • peut-on taguer les messages à des fin de recherche ultérieures ?
  • lien avec Redmine ? (discussion durant la réunion : pourrait-on se contenter d'un seul outil ?, peut-on considérer qu'un outil de gestion de bugs est équivalent à un outil de gestion de tickets ?, ... à priori nous partons du principe que ce n'est pas la même chose, l'outil de gestion de bugs étant tout de même plus orienté développeurs)
  • facilité de mise en oeuvre et de maintenance des outils (choix objectif de l'outil en tenant compte également de ces aspects)
  • évaluer les statistiques fournies pas les outils
  • conserver la possibilité de migrer vers un autre outil d'ici quelques années
  • les données générées sont-elles facilement exploitables hors des outils (lié également à la remarque précédente, export des données vers un autre outil par exemple)
  • ...
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback