Pour rappel, PeerTube est une application web, s'installe sur un serveur et tourne via NodeJS. Voir le sommaire pour plus d'informations.

Une fois la méthode de release choisie et le logiciel diffusé, le projet commence à prendre de l'ampleur et on reçoit de plus en plus de tickets. Il est temps d'organiser tout ça. Voici comment on s'y est pris avec PeerTube.

Utiliser un template d'issue

Nous utilisons un template d'issue, encourageant les personnes qui créent des tickets à l'utiliser. Ça permet d'éviter de poser 20 fois les mêmes questions ("Quelle est la version de NodeJS ?") et surtout d'accélérer les échanges (asynchrones, donc une réponse en plus peut prendre plusieurs jours).

Par exemple avec les bugs, on utilise le schéma suivant :

• Que s'est il passé ?
• Qu'est ce qu'il aurait dû se passer à la place ?
• Comment reproduire ?
• Informations complémentaires (versions des logiciels, logs du serveur ou du navigateur...)

Généralement, si les informations sont correctement renseignées, on comprend directement si c'est un bug ou non, où il se situe et ce qui a pu l'amener. Attention cependant à ne pas abuser de questions dans le template, pouvant décourager les utilisateurs à reporter des bugs.

Le template peut aussi servir pour indiquer aux personnes de lire la FAQ avant de créer leur issue, ou d'avertir de ne pas utiliser le système de tickets pour remonter des problèmes de sécurité (qui doivent passer par un canal séparé et non public).

Nous avons aussi un template pour les demandes de fonctionnalités, pour encourager les utilisateurs à structurer leur pensée :

• Décrivez le problème à résoudre
• Décrivez la solution que vous aimeriez
• Décrivez les alternatives que vous avez envisagé

Les labels

On a choisi de les organiser en 4 thèmes :

• Le composant associé à l'issue : chaînes vidéos, modération, player etc
• Le type de l'issue : amélioration, bug, discussion, question...
• Son statut : à reproduire, bloqué, en cours, en attente de réponse
• Et sa priorité : critique, moyenne, basse...

On se sert principalement des labels de type Composant et Type. On a encore une bonne marge d'amélioration sur ce point-là.

Le label Status: Waiting answer est très pratique pour fermer les issues dont vous n'avez pas de réponses depuis x jours. Ça évite d'utiliser un stale bot, qui est de mon avis une horreur absolue.

On utilise souvent les labels Status: To Reproduce et Type: Bug pour avoir une vue des problèmes soulevés, et donc à s'occuper assez rapidement (d'où l'intérêt de la couleur rouge pour le label Type: Bug).

Enfin, ne pas oublier d'ajouter un label good first issue pour aiguiller des développeurs qui voudraient se faire la main sur le logiciel.

Avoir un code de conduite

On n'y pense pas forcément au début, et on peut avoir du mal à en voir l'intérêt. Mais ajouter un code de conduite avant l'arrivée des contributeurs est quelque chose d'assez important. Plus le projet va devenir connu et plus vous allez devoir gérer des interactions au sein et autour du projet. Malheureusement, il va falloir à un moment donné gérer certaines de ces interactions, pour protéger votre projet, vous-même ou bien d'autres contributeurs.

Ajouter un code de conduite ne requière pas beaucoup de travail : de nombreux templates sont disponibles sur internet. Le tout est de s'assurer qu'outre les choses évidentes (sexisme, insultes etc), il couvre aussi les commentaires déplacés qui peuvent devenir irritants (commentaires désobligeants, trolls etc) et le harcèlement. Dans le cas de PeerTube (et de nombreux autres projets open-source), le harcèlement prend souvent la forme d'une personne un peu influente sur un réseau social qui met un lien vers un ticket ou un commentaire avec lequel il est en désaccord, et demande à sa communauté de faire pression de manière peu sympathique. Vous verrez alors tout un flot de nouveaux comptes se créer et "participer" à la discussion. C'est à ce moment que le code de conduite est utile : il vous permet de facilement arbitrer et bloquer les comptes/discussions afin de retrouver des échanges plus sereins.

Dire merci

Avant de répondre à une issue, ça ne coûte pas grand chose de débuter par un merci car la personne a pris le temps de vous remonter un problème ou une idée, chose précieuse dans un projet libre.

Les moteurs de recherche ne sont pas parfait, et les humains encore moins. Il arrive que certaines issues soient en fait des doublons. Là encore, un merci ne coûte pas grand chose : la personne ne l'a sans doute pas fait exprès, et les gestionnaires de tickets sont souvent dotés de "réponses rapides".

Prendre position

Il est souvent tentant de laisser une issue ouverte, même si on la trouve sans intérêt ou en désaccord avec l'idée principale du projet dans le but d'éviter un conflit avec le créateur du ticket. Il faut néanmoins savoir se faire violence et fermer ce genre d'issue afin que personne ne se fasse de faux espoirs sur la réalisation d'une fonctionnalité qu'on ne souhaite pas implémenter/accepter. L'autre intérêt est de garder le nombre d'issues ouvertes sous un certain seuil, sinon ça peut vite devenir compliqué à gérer.