Guidelines de tri des problèmes

Guidelines pour le tri des problèmes etcd

Tâche

Objectif

Accélérer la gestion des problèmes.

Les problèmes liés à etcd sont répertoriés sur https://github.com/etcd-io/etcd/issues et sont identifiés par des étiquettes. Par exemple, un problème identifié comme un bogue sera éventuellement étiqueté area/bug . Les nouveaux problèmes apparaissent initialement sans étiquette, mais les responsables etcd et les contributeurs actifs ajoutent des étiquettes en fonction de leurs constatations. La liste détaillée des étiquettes est disponible sur https://github.com/kubernetes/kubernetes/labels

Voici quelques recherches prédéfinies sur les problèmes, pour plus de commodité :

Portée

Ces directives servent de document principal pour trier les problèmes reçus dans etcd. Tous sont invités à aider à la gestion des problèmes et des demandes de tirage, mais le travail et les responsabilités décrits dans ce document sont destinés aux mainteneurs et contributeurs actifs de etcd.

Vérifier qu’un problème est un bogue

Vérifiez si le problème est bien un bogue. Si ce n’est pas le cas, ajoutez un commentaire avec vos constatations et fermez l’issue mineure. Pour une issue non mineure, attendez de recevoir une réponse du rapporteur d’incident et vérifiez s’il y a une objection. Si le rapporteur d’incident ne répond pas dans les 30 jours, fermez l’issue. Si le problème ne peut pas être reproduit ou s’il nécessite des informations supplémentaires, laissez un commentaire pour le rapporteur d’incident.

Problèmes inactifs

Les problèmes qui manquent d’informations fournies par le rapporteur doivent être fermés si ce dernier ne fournit pas d’informations dans les 60 jours.

Problèmes en double

Si un problème est en double, ajoutez un commentaire indiquant cette situation, accompagné d’une référence vers le problème original, puis clôturez-le.

Problèmes qui n’appartiennent pas à etcd

Parfois, des problèmes sont signalés qui appartiennent en réalité à d’autres projets utilisant etcd. Par exemple, des problèmes liés à grpc ou golang. Ces problèmes doivent être traités en demandant au signalement de créer une issue dans le projet approprié. Fermer l’issue, sauf si un mainteneur et le signaleur estiment nécessaire de la laisser ouverte pour des raisons de suivi.

Vérifier que les étiquettes importantes sont présentes

Assurez-vous que l’issue dispose des étiquettes correspondant aux domaines auxquels elle appartient, que les assignataires appropriés sont ajoutés et que l’échéance est définie. Si l’une de ces étiquettes est manquante, ajoutez-la. Si les étiquettes ne peuvent pas être attribuées en raison de privilèges limités ou si l’étiquette correcte ne peut pas être déterminée, cela ne pose pas de problème ; contactez les responsables si nécessaire.

Poke le propriétaire de l’issue si nécessaire

Si une issue dont le propriétaire est un développeur n’a pas de demande de fusion (PR) créée en 30 jours, contactez le propriétaire de l’issue et demandez une PR ou la libération de la propriété si nécessaire.