« Compte-rendu réunion Animation 2010-01-20 » : différence entre les versions

De April MediaWiki
Aller à la navigationAller à la recherche
Ligne 168 : Ligne 168 :
*présentations, car trop d'attente entre chaque : demander aux participants de préparer à l'avance
*présentations, car trop d'attente entre chaque : demander aux participants de préparer à l'avance
*modération un peu rigide au début
*modération un peu rigide au début
*certaines questions auraient gagné a être préparée a l'avance pour que chacun y pense
*certaines questions auraient gagné à être préparée a l'avance pour que chacun y pense
*inciter a remplir son bénévolat valorisé : http://www.april.org/my/?action=benevalo
*inciter à remplir son bénévolat valorisé : http://www.april.org/my/?action=benevalo


[[Catégorie:Animation]]
[[Catégorie:Animation]]

Version du 21 janvier 2010 à 23:04

Elle se déroulera à partir de 21h sur le canal #april-animation du réseau Freenode (irc.freenode.net)

Contexte

Documents de référence : Roadmap/Feuille de route du groupe Animation

Document de référence Communauté

Lors de la réunion précédente du 8 décembre, on avait passé en revue les points suivants :

  • fonctionnement de liste-infos@
  • choix d'un outil de gestion des tâches
  • gestion des groupes
  • outil de gestion des tâches (Redmine)

Todo list réunion décembre

Todo list réunion Redmine

Ordre du jour

Ajouter des points à l'ordre du jour : rendez-vous sur Redmine https://redmine.april.org/projects/animation entrez-y les tâches que vous voulez voir discutées d'ici la réu si elles n'y sont pas dejà

L'ordre du jour est pour l'instant le suivant :

  1. Tour de table
  2. Passer en revue les tâches du projet Animation sur Redmine (https://redmine.april.org/projects/animation)
  3. Point sur le test FudForum, et étape suivante : site de test http://sebix2.chateau-dutier.com/
  4. Point sur les Appels à discussion (AAD) sur april@
  5. Gestionnaire des tâches (Redmine) : bilan des tests
  6. Vue d'ensemble - quels sont les defis pour l'animation de l'April ? Etablissement des objectifs 2010 et d'une roadmap pour les faire aboutir
  7. Reprendre la liste des tâches des réunions précédentes : vérifier ce qui a été fait, ce qui reste à faire, déterminer qui fait quoi

Déroulé

  • parler à tour de rôle (modérateur : Xavier)
  • à la fin de chaque point abordé, noter clairement la liste des décisions et des tâches qui en découlent, en leur attribuant un volontaire et une échéance
  • compte-rendu : Eva et Rayna

Compte-rendu

La réunion est modérée (ceux qui veulent intervenir envoient un message en privé à Xavier Antoviaque) : on fera le point sur les avantages de cette méthode.

Présentations : Antoviaque, Eva, Bookinette, Bouteille de lait, Lionel Allorge, Gilles Coulais, Malicia, Sébastien Chateau-Ditier, Benoît Sibaud, Frédéric Couchet, François Poulain, Rémi Mathieu (peon), Raphaël Flores, Vincent-Xavier Jumel (et cpm_, nca, quesh, taziden, theocrite)

(21h30)

Présentation des tests Fudforum par Seb

Contexte : Les listes de discussion sont très vite empilées et les sujets se perdent dans le temps ; les gens (les non geeks surtout) évitent de chercher dans les archives. Ainsi, l'idée qu'un forum permettrait un meilleur archivage, une meilleure visibilité des sujets et une plus grande participation a émergé et FUDforum a été choisi.

  • Au début, FUDforum a été mis en place dans le but d'archiver des messages de la liste de diffusion animation@. Pour faire simple, l'outil récupère les mails et les place dans un forum en les regroupant par conversation.
  • Pour le moment, le test se fait dans le sens liste de diffusion => forum ; l'inverse n'a pas été testé.

Action suivante : Tester le fait de poster sur le forum directement pour vérifier que le message arrive bien sur la liste animation@ (durée du test ~30 min) => SebiCbo

  • Question adminsys : est-ce que FUDforum supporte LDAP ? Cet outil sera utilisé pour la synchronisation des comptes April et de la liste de discussion.

R : FUDforum supporte parfaitement les login LDAP

  • Les admins prévoient également une migration vers une version plus morderne de sympa [interface de gestion des listes de discussion], certainement sympa v5.4 (Depot Debian) - à faire dans l'année.

Vincent-Xavier et Sébastien se coordonnent pour faire des tests sur un vserver et tiennent la liste au courant (dans 1 ou 2 semaines).

Action suivante : Vincent-Xavier communique les infos pour test à SebiCbo ; SebiCbo testera le login LDAP avec FUDforum

  • Prévoir une liste des listes de discussions et décider lesquelles peuvent être sur FUDforum, sachant que toutes n'ont pas la même politique de confidentialité.

Action suivante : Lionel vérifie avec le CA quelle politique on applique.


21h57

Appels à discussion (AAD)

  • Xavier présente le principe : il y a parfois besoin d'avoir des discussions dont la portée dépasse le cadre d'un groupe. Et il y a également besoin de valider des choses auprès du CA. L'AAD est un parcours guide pour y parvenir.

Tout le monde peut lancer un AAD. Pour ce faire, il suffit d'un mail avec la bonne étiquette. L'idee de le noter dans le tracker a été avancée, mais cette partie demande ) être confirmée. Le concept d'AAD a manqué de clarté ; ceux lancés jusqu'ici n'ont pas trop suivi le principe.

Action suivante : Xavier doit faire une nouvelle version de l'AAD-1 en intégrant les échanges et remarques déjà existant.

Tests Redmine

Contexte : l'idée de départ était d'avoir une liste de tâches à faire pour que n'importe qui ayant du temps et de l'envie de participer puisse le faire. Comme il y a moult groupes de travail avec des dynamiques d'activité différentes, on ne peut se contenter d'une liste wiki : il faut un outil pour compléter. D'où émerge le besoin de gestionnaire de tâches. Ce dernier permet d'avoir un état des lieux d'un action à un instant T : fait ? pas fait ? par qui ?

  • Lionel trouve l'interface assez "geek" et pas du tout adaptée au débutant (exemple : pas de liste claire des tâches sur la page de garde). Donc, l'outil pourra faire l'affaire pour les animateurs de groupe mais probablement pas pour les utilisateurs finaux. Ce qui implique de prévoir en plus une génération de pages très simples, genre liste des tâches à faire avec un bouton "je prends", etc.

=> travail a prévoir assez en amont, en collaboration avec les listes siteweb et admins.

Donc, actuellement il y a deux obstacles :

  1. la définition des tâches pour qu'elles soient réalisables sans obligatoirement en connaître le contexte,
  2. la présentation hors de Redmine pour être moins rebutant => solution technique à déterminer
  • Remarques de Malicia :
    • Quelle est la différence entre observateur et les autres ? => définition des types de contributeurs
    • Distinguer l'objectif du Redmine de celui du wiki => rédaction de doc en conséquence
    • Où est la documentation évoquée plus haut ? Il est très important qu'elle soit de niveau non geek et qu'on suive l'avancement de l'écriture pour tempérer le ton au fur et à mesure.
  • Adopter Redmine ?
    • Position adminsys : pour le moment, nous ne sommes toujours pas prêts à sérieusement déployer l'outil, nous ne l'avons pas réellement mis en concurrence avec d'autres. Il y a un certain nombres de tâches de coté du SI avant de le sortir du test ; les admins sont débordés.
    • (+++) De tous les outils envisagés, c'est le plus pertinent. Rémi en a testé plusieurs sans trouver mieux. Flyspray était plus simple, mais pas aussi bien maintenu (niveau sécurité). Raphaël l'utilise au travail et ne conteste pas son utilité.
    • (-+) Plus adapté aux animateurs de groupe qu'au simple débutant
    • (-) Ce qui semble manquer pour les tests, c'est un workflow détaillé, avec des scenarii
    • (+) Assez simple d'utilisation et en français

Wishlist, choses à faire :

    • Vérifier la possibilité de forcer les tâches à avoir une échéance (même si non tenue) ;
    • Former les animateur de groupes sur l'utilisation de l'outil ;
    • Une documentation sur le flux de travail que nous désirons utiliser est en cours de réalisation ;
    • Faire un didacticiel pour les premières utilisations : comment être membre d'un projet, s'assigner une tache,... Il devra être accessible via le menu Aide [celui du haut Accueil/ Ma page / Projets / Aide] => cf. le début de rédaction du didacticiel ;
    • Mediawiki est en cours de test en tant que gestionnaire de tâches aussi : Agir April. On comparera les fonctionnalités ;
    • Faire le test d'extraction des tâches de Redmine vers Drupal (ou autre interface).

Action suivante Redmine : documenter le parcours d'une tâche dans Redmine, de l'idée à la réalisation en passant par la publication auprès des adhérents en tâche "agir april" => Raphaël, Rémi, Rayna, Eva, Bookinette, Vincent-Xavier et François.


Action suivante pour tous : Désencombrez vos listes de tâches en supprimant les non importantes.

Au-delà du gestionnaire de tâches

  • Remarque de Frédéric : se focaliser sur les outils si on ne travaille pas les démarches d'organisation est inutile. Il est peu probable que 300 adhérents vont saisir des tâches et les prendre.

Il y en aura toujours qui, quel que soit l'outil, auront besoin d'accompagnement. L'outil qui doit être choisi doit avant tout permettre un suivi par les animateurs, permanents,... ; c'est le plus important.

  • Ne pas oublier le wiki
  • Exemple de page pour les participants : http://www.mozilla.org/contribute/
  • On doit arriver, en tant que groupes, à faire le tri dans les choses à faire => identifier les tâches qu'on voudrait donner a d'autres.
  • En parallèle, il faudrait penser à comment amener un adhérent à participer avant de lui dire "va donc jeter un œil sur Redmine". Si l'on ne met en face une véritable démarche d'intégration des adhérents volontaires dans les projets, on aura aussi bien fait de colle des post-it sur un frigo, ce sera aussi (in)efficace.

Compléments aux fonctionnement de liste-infos@

  • Quel est l'objectif de la liste ? Ce point est mal défini dans la charte de liste-infos@.

Cela pose le problème des types et formats de messages qui y sont adressés. Les rejets des messages non conformes ne sont pas argumentés (ou pas tout le temps), ce qui implique que la personne ayant envoyé ne sait toujours pas pourquoi. => proposition : est-il possible de créer un modèle et/ou de clarifier au possible les types de messages acceptés sur cette liste ? Une page peut être créée sur le wiki de la liste-infos@ où sont explicitées les raisons les plus probables d'un rejet. Le lien vers cette page servira aux modérateurs et leur évitera de récrire le même message à de fréquentes reprises.

  • La question de la redirection sur april@ se pose aussi. Quand on répond à un message envoyé à liste-infos@, il se retrouve sur april@. Or, cette dernière n'est pas forcément adaptée à recevoir certaines catégories de réponses.

=> question : est-il techniquement possible de positionner les reply-to vers une liste donnée ? Ou la personne souhaitant répondre doit le faire manuellement ?

Action suivante : envoyer une proposition de modification de charte sur animation@ et liste-infos-moderateurs@ pour inscrire dans les règles que les rejets doivent être motivés + suggestions de complétion du mode d'emploi pour les réponses à certaines listes (différentes d'april@ ) => Malicia

Todo List

  • Test FudForum : Tester le fait de poster sur le forum directement (durée 30 min) ; il faut aussi tester que ça ne casse pas les fils de discussions s'il y a des messages envoyés via la liste et via le forum => SebiCbo
  • Finir de transcrire les taches animation@ issues de la roadmap (puis faire le ménage, clarifier certaines tâches) => Xavier
  • Redmine : vérifier la possibilité de forcer les tâches à avoir une échéance (même si non tenue) => Vincent-Xavier

Points forts, points de vigilance

Points forts

  • ++++ modération réussie, on s'écoute "parler"
  • + préparation de la réunion
  • + compte-rendu en direct
  • + nombre de participants, des jeunes, des vieux et des anciens
  • + présentations mais trop long
  • + réunions régulières (une par mois) pour qu'elles soient moins touffues et moins longues
  • + attribution des tâches
  • + l'annonce à l'avance

Points de vigilance

  • ordre du jour trop large
  • réunion trop longue
  • trop de points à discuter, peu de temps à disposition
  • horaire tardif
  • trop de réunions qui se suivent
  • présentations, car trop d'attente entre chaque : demander aux participants de préparer à l'avance
  • modération un peu rigide au début
  • certaines questions auraient gagné à être préparée a l'avance pour que chacun y pense
  • inciter à remplir son bénévolat valorisé : http://www.april.org/my/?action=benevalo