On en parle depuis longtemps, et on en a reparlé en cercle ancrage cette semaine : l’un des gros points sur lesquels Fédération a des progrès à faire est celui du découpage des projets en tâches accessibles, les fameux « work packages. »
Pour faire avancer le sujet, j’ai entamé il y a plusieurs semaines la préparation d’un article d’actualité dédié. Je partage ici le brouillon à ce stade, pour qu’on l’enrichisse et l’affine en commun avant publication. Merci par avance pour vos contributions 
Dans le cadre des travaux menés autour de la pédagogie dans Fédération, l’un des éléments les plus importants qui apparaissent pour favoriser l’inclusion est la division des projets de façon à les former en somme de tâches classifiées par niveau et compétence. L’objectif est de pouvoir proposer des tâches projets (“work packages”) à des nouveaux venus qui ne veulent ou ne peuvent passer un temps significatif à absorber tout l’historique du projet avant de se lancer dans des actions concrètes.
- Sous quel format présenter ces tâches ?
Ce que font déjà aujourd’hui plusieurs projets est d’utiliser les Issues de Gitlab, associées à des labels. Par exemple : newcomer ou « good first issue », durée, priorité…
[Illustration tâche]
Parmi les labels utilisés :
- niveau de priorité pour le projet : Low / medium / high
- niveau : Novice / Advanced / Expert
- Durée estimée : short (1-2 hours), medium (3-10 hours), long (11 hours+), recurring
[screenshot de tâche type]
Dans le contenu, mentionner clairement ce qui a conduit à créer cette issue (date de réunion, post forum ou chat, etc.).
- l’importance de pouvoir proposer des tâches / missions de durée et de niveau d’implication variables
Au-delà de tâches ponctuelles telles que celles décrites ci-dessus, les équipes projets peuvent rechercher des rôles dans la durée. Par exemple un référent télécommunication, mécanique, fabrication additive… C’est pour cela que nous avons développé le concept des “appels à l’aide”, typiquement plus orientés rôle dans la durée, que les projets peuvent publier sur leur page vitrine.
- Sur la façon de maintenir ces work packages au fur et à mesure de la progression des projets.
Que ce soit pour les tâches dans Gitlab ou OpenProject, ou pour les rôles des “Appels à l’aide”, il est nécessaire que les référents du projet fassent un suivi régulier des issues ouvertes,de leur date limite. Cela peut passer par une revue régulière (mensuelle, trimestrielle…) en réunion de suivi projet, ou de façon individuelle par le référent projet – à chaque projet de trouver sa façon de fonctionner, l’important étant qu’un nouveau venu puisse trouver des éléments actualisés sur les voies d’implication dans le projet.
- Sur l’accessibilité pour les néophytes tout autant que sur l’intérêt du challenge pour les experts. Etc.
Il est recommandé aux équipes projets de créer des tâches pour différents niveaux de compétences, et en particulier de ne pas les focaliser que sur des besoins experts. Ne serait-ce que parce que cela limite la probabilité de trouver à court terme le contributeur projet pouvant prendre en charge cette tâche.