Gérer son temps bénévole

Compte-rendu du 25 janvier 2019

Participantes : Léna, Anne-LaureM, Exilexi

Une première chose à noter, c'est qu'avec un ordre du jour, on fait des réunions beaucoup plus efficaces Sur cette rencontre, nous n'avions pas préparé de choses à discuter. Nous avons donc exploré un certain nombre de sujets et de problématiques qui pourront servir de base à des prochaines discussions.

Le contexte de la réunion était : "Comment se dégager du temps et rester constant sur des projets longs ?" Nous avons beaucoup parlé de projets étendus dans le temps qui nécessitent de l'organisation (partenariats GLAM, développement d'applications, etc.), et relativement peu de la contribution "simple" (création d'articles, d'éléments).

Aperçu des problématiques

Trois problèmes principaux se dégageaient dès le début de la réunion :

Comment évaluer la charge de travail avant de se lancer et prioriser les tâches si nécessaire ?
Comment arrêter de délaisser un projet pendant plusieurs mois, que ce soit volontaire (lassitude) ou non (oubli) ?
Comment dégager des blocs de temps pour contribuer à des projets qui nécessitent de la concentration et ne permettent pas de travailler par blocs de quelques dizaines de minutes ou en multitaskant ?

Comment évaluer la charge de travail ?

Pour planifier le temps passé à faire du bénévolat, la solution devrait être simple : "Quand j'en ai marre, j'arrête !". Bien sûr, ça ne se concrétise presque jamais. Comment faire pour réagir et s'adapter si on a passé trop ou trop peu de temps à contribuer pendant une période donnée ? Il est presque impossible de compter les heures passées à contribuer, puisqu'on passe beaucoup de temps à multitasker (ex. contribuer au bureau) et à effectuer des petites tâches (ex. répondre à un mail) difficilement quantifiables. On manque donc cruellement de visibilité pour s'organiser dans son travail, mais aussi dans son énergie disponible.

Comment contribuer de manière constante à un projet d'envergure ?

Un problème que nous rencontrons toutes les trois est le fonctionnement par périodes intensives : du travail intensif pendant quelques heures/jours/semaines, puis une pause soudaine qui dure assez longtemps pour qu'il soit très difficile de reprendre le projet (quelques semaines ou quelques mois). Résultat : on n'a pas la satisfaction d'avoir mené un projet à son terme et d'avoir avancé suffisamment. Il faut aussi combattre la tendance à se disperser sur plusieurs projets et à oublier de revenir sur le premier.

Sur les projets Wikipédia, par exemple, on identifie très facilement des petites tâches qui apportent une gratification immédiate : ajouter un bandeau d'ébauche, avancer d'un cran dans l'évaluation d'un article (désébauchage par exemple), ajouter une image... Sur un projet d'envergure, peut-on diviser le travail en petites tâches satisfaisantes plutôt que d'avoir un énorme objectif qui semble insurmontable et n'apportera aucune satisfaction tant qu'il n'est pas mené à son terme ?

Comment dégager du temps pour des projets ?

Nous avons toutes les trois tendance à contribuer au bureau, pour des raisons différentes. Une de ces raisons est le besoin de se sentir utile : dans ce cas, Wikimédia serait presque une stratégie d'évitement des tâches les moins intéressantes de son travail. Dans d'autres cas, il s'agit simplement d'ennui, ce qui est beaucoup moins grave ! En tout cas, il est intéressant, quand on se laisse happer par Wikimédia au bureau, de chercher à comprendre pourquoi on a autant procrastiné : est-ce pour une raison saine ou parce que quelque chose ne va pas au travail ?

En dehors de tout jugement moral, la contribution au travail a ses limites : sur un projet d'envergure comme un partenariat ou le développement d'un module, il faut dégager des blocs de temps ininterrompu. Pour revenir sur un projet en cours, on compte déjà une vingtaine de minutes pour retrouver le contexte, l'avancement de la fois précédente et où il faut reprendre. Ensuite, le travail lui-même, pour être productif, doit durer plusieurs heures. Comment éviter la frustration d'une idée à laquelle on ne peut pas donner suffisament de temps ? En parallèle, on ne peut pas forcément assurer un bon équilibre mental en consacrant son jour de repos hebdomadaire à un travail bénévole ; d'un autre côté, si on ne contribue pas pendant le week-end, il est presque impossible de rester constant sur les projets.

Diviser pour mieux régner (à peu près)

Pour répondre à certains des problèmes évoqués plus haut, la collaboration nous paraît essentielle.

Mieux collaborer sur les projets

Il est essentiel de documenter tout ce qu'on fait. Les avantages sont multiples :

Retrouver facilement son avancement
Permettre aux autres d'apporter leur expertise sans être perdus dans le système de quelqu'un d'autre
Rendre les projets facilement trouvables...
...pour s'éviter à tous de réinventer la roue à chaque nouvelle initiative.

Il est essentiel que nous trouvions une suite d'outils adaptée, qui utilise des normes communes à Wikimédia. Si actuellement la création de processus est extrêmement valorisée, il s'agirait de transférer la reconnaissance du travail vers un modèle qui permet de survivre au bus factor : si le développeur principal est écrasé par un bus, le projet sera-t-il encore viable ? Pour cela, il faut que tout soit compréhensible et facile à maintenir, par tout le monde.

Impliquer les personnes techniques

Les projets open source en général valorisent le profil du hacker qui crée un outil entier seul. Pour une collaboration pérenne et efficace, mieux vaudrait s'appuyer sur l'utilisation des compétences différenciées de chacun : une personne crée une script de grande qualité, une autre travaille sur une interface utilisateur intuitive, par exemple.

On obtient une collaboration :

Facile : chacun a son expertise et contribue sans avoir besoin de sortir de sa zone de confort
Optimale : plutôt qu'un travail moyen partout par une personne aux compétences variées, un assemblage de compétences maximales mais spécialisées
Durable : si une personne quitte le projet, on perd un seul aspect de son développement et on peut la remplacer, plutôt que de perdre 100 % de l'implication

Impliquer les personnes non techniques

Léna et Anne-Laure remarquent qu'aux hackathons Wikimédia, les utilisateurs et les développeurs se retrouvent avec des niveaux de compréhension technique variés. Ils ont tous beaucoup à apprendre les uns des autres ! Dans ces événements, les bénévoles n'hésitent pas à poser des questions "bêtes" qu'une personne aux compétences techniques développées n'aurait pas besoin de poser. Loin d'être une perte de temps, ces questions permettent d'établir une documentation qui peut être utilisée par n'importe qui, n'importe quand.

Il faudrait presque que les documentations d'utilisation des outils soient toujours faites par des personnes les moins techniques possibles pour être compréhensibles par le plus grand nombre.

Mieux collaborer

D'après nous, les espaces de collaboration de Wikimédia ne sont pas suffisament accueillants pour des nouvelles personnes.

En termes d'espaces en personne en France, en dehors de Paris, on ne sait que rarement où se retrouver. À Paris, un local comme celui de Wikimédia France exige des efforts, même minimes : les bénévoles doivent connaître le chemin (une personne qui vient pour la première fois a intérêt à être accompagnée pour ne pas trouver une porte fermée), apporter de quoi manger et boire (c'est un effort minime, mais ça représente une charge de temps et financière à la fin d'une journée parfois chargée qui peut décourager certains de venir).

Pour les espaces en ligne, ce n'est pas beaucoup mieux : les espaces communautaires sont difficiles à trouver sur les wikis sans expérience, les plateformes de type IRC sont peu intuitives pour des utilisateurs plus jeunes ou non techniques, et Phabricator est un outil très complexe, difficile à apprendre pour des personnes dont ce n'est pas le coeur de métier. Pour faciliter la tâche aux bénévoles techniques ou non, nous proposons de plutôt nous appuyer sur des outils de to-do lists comme Framemo. Sur ces outils faciles à manier, on peut utiliser un tableau par projet et des colonnes par avancement ou par équipe impliquée. Nous avons aussi insisté sur la place primordiale des référents pour suivre et faciliter l'avancement de ces projets d'envergure.

Concrètement...

Sur les événements de contribution, nous suggérons de toujours proposer un mélange de tâches importantes (ex. création d'un projet, numérisation d'un fonds ou d'un livre, etc.) et de tâches faciles et rapides pour permettre à chacun de participer à hauteur de sa disponibilité en termes de temps et d'énergie. C'est déjà le cas sur les événements en personne comme les ateliers Wikidata de Paris, qui sont très engageants, mais sur Internet, nous pourrions faire beaucoup mieux pour valoriser le travail de chacun à son échelle.
Les référents ont pour mission d'aider les gens qui ne savent pas valoriser leur travail ou auraient du mal à partager leur avancement ou leurs actions avec des équipes. C'est un travail difficile qui demande des compétences spécifiques, on ne peut pas se contenter de "jeter" un bénévole dessus.
Il faudrait aider les gens à mettre en valeur leurs contributions. Nous avons émis l'idée d'un timer qui montrerait le temps passé sur la session et permettrait aux utilisateurs d'être satisfaits d'avoir passé ce temps sur les projets qui leur tiennent à coeur, en plus de faciliter leur gestion du temps. Nous devrions également revoir les communications pour toujours proposer un objectif concret : "numérisez la collection de tel musée" au lieu de "apprenez à utiliser Commons" par exemple. Avoir un objectif concret pousse les débutants à avoir envie de participer.
Il faudrait aussi mettre en avant les microfinancements pour ceux qui ont le temps, mais pas les moyens de s'engager sur des projets d'envergure (bénévolat en semaine, déplacement pour une couverture d'événement ou investissement personnel dans un musée non partenaire).

Focus : #WikiRecap

Pourquoi : Il est important pour nous de participer au sein d'une communauté. Il faut avoir des partenaires (cf. expertises diversifiées), mais aussi pouvoir valoriser son propre travail sur une plate-forme où il y a des échanges. Enfin, le fait de partager publiquement ses objectifs crée un sentiment de responsabilité et de motivation mutuelle - des études sont arrivées à cette conclusion dans le contexte de la perte de poids entre autres.

Quoi/Comment : Nous suggérons un moment de partage au sein de la communauté. En public, nous partageons ce que nous avons réussi à faire cette semaine et nos objectifs de la semaine prochaine. Nous parlons des blocages que nous pensons rencontrer et nous répondons aux blocages des autres personnes du projet. Nous félicitons ceux qui ont réussi à atteindre leur objectif, nous encourageons ceux qui réussiront la prochaine fois.

Quand : Toutes les semaines environ.

Où : Il faudrait utiliser une plate-forme où les gens sont présents et n'ont pas d'étapes d'apprentissage ou d'inscription nécessaire pour participer, par exemple Twitter où nous avons déjà beaucoup de membres actifs (l'idée étant d'avoir une participation maximale, d'où le choix d'une plate-forme populaire à défaut d'être open source). Dans le cas de Twitter, nous pourrions utiliser un hashtag comme #WikiRecap.

Qui : Toute personne qui veut partager ses questions, ses blocages et ses réussites. Toute personne qui cherche à collaborer sur des projets. Wikimédia France en soutien pour assurer une véritable interaction et de ne pas "poster dans le vide", ce qui serait pire que de ne rien faire du tout.

D'autres questions abordées pendant la réunion

Sur le plan personnel, comment dégager des blocs de temps dans son calendrier ? (Productivité)
Comment évaluer la charge de travail et apprendre à diviser en sous-tâches quand on n'a pas d'expérience collaborative préalable ?
Qui doit être le référent et quelle est sa mission exactement ?
Que faire des demandes de bénévolat en semaine (par exemple la formation de professionnel) ?