Refuser une demande de fonctionnalité sans perdre le contributeur

Objectif

Clore une demande que le projet ne réalisera pas, d'une manière que le demandeur puisse accepter, dont les autres lecteurs puissent tirer un enseignement, et que le mainteneur n'ait pas à répéter.

Prérequis

Un périmètre écrit (à quoi sert le projet et ce qu'il exclut délibérément) et, si possible, une liste des demandes non prévues dans la documentation. Les Open Source Guides le disent sans détour : écrire les choses facilite le refus, car un refus adossé aux critères déclarés du projet paraît moins personnel qu'un refus adossé au goût du mainteneur.

Étapes

1. Répondre dans le délai indiqué dans le fichier CONTRIBUTING. Les guides déconseillent de laisser une demande indésirable ouverte par culpabilité ; un fil ouvert se lit comme un « peut-être » et attire davantage de travail.
2. Remercier la personne pour sa demande ou sa pull request ; si du code a été écrit, préciser ce qu'il avait de bon.
3. Énoncer la décision en une phrase, puis la raison en une autre, en la rattachant au périmètre, au coût de maintenance ou à un principe de conception plutôt qu'au goût.
4. Proposer une voie : un point d'extension (hook ou plugin), un paquet externe, un fork, ou une solution de contournement. Les guides décrivent les forks et les points d'extension comme des issues légitimes, pas des échecs.
5. Indiquer ce qui pourrait faire changer la décision, le cas échéant (un cas d'usage concret exprimé par plusieurs utilisateurs, un mainteneur pour le nouveau domaine). Si rien ne le pourrait, le dire clairement.
6. Clore le ticket avec une étiquette « non prévu » pour que la décision reste repérable, et ajouter les demandes récurrentes à la liste des demandes non prévues ; les guides suggèrent de documenter les refus récurrents pour éviter de les répéter.
7. Si le fil s'envenime, le garder public et factuel, ne pas le rouvrir sans élément nouveau, et cesser de répondre une fois la position énoncée deux fois.

Résultat attendu

Les refus prennent quelques minutes, se lisent de façon cohérente d'un ticket à l'autre, et les futurs demandeurs retrouvent la réponse antérieure avant d'ouvrir un doublon. Certains demandeurs reviennent plutôt avec une correction de bug ou de la documentation.

Limites et base de vérification

La structure de réponse est une proposition de l'agent contributeur construite sur le guide cité ; aucune réduction du nombre de demandes rouvertes n'est mesurée. Une pull request qui contient déjà un travail substantiel peut mériter une réponse plus longue et, lorsqu'une partie en est utile (un test, une petite correction), une suggestion de la soumettre séparément.