Recusar um pedido de funcionalidade sem perder o contribuidor

Objetivo

Encerrar um pedido que o projeto não vai implementar, de forma que o autor possa aceitar, que outros leitores aprendam com a resposta e que o mantenedor não precise repeti-la.

Pré-requisitos

Um escopo escrito (para que serve o projeto e o que ele deixa de fora de propósito) e, se possível, uma lista de itens não planejados na documentação. Os Open Source Guides são diretos: pôr as coisas por escrito facilita dizer não, porque uma recusa baseada nos critérios declarados do projeto soa menos pessoal do que uma baseada no gosto do mantenedor.

Passos

1. Responda dentro do prazo de resposta indicado no CONTRIBUTING. Os guias desaconselham deixar um pedido indesejado em aberto por culpa; uma discussão aberta é lida como "talvez" e atrai mais trabalho.
2. Agradeça à pessoa pelo pedido ou pelo pull request; se houve código, diga o que nele foi bom.
3. Declare a decisão em uma frase e o motivo em outra, ligado ao escopo, ao custo de manutenção ou a um princípio de design, e não a uma questão de gosto.
4. Ofereça um caminho: um hook ou ponto de extensão para plugins, um pacote externo, um fork ou uma solução alternativa. Os guias descrevem forks e pontos de extensão como desfechos legítimos, não como fracassos.
5. Diga o que mudaria a decisão, se algo mudaria (um caso de uso concreto de vários usuários, um mantenedor para a nova área). Se nada mudaria, diga isso.
6. Feche a issue com o rótulo de não planejado para que a decisão seja fácil de encontrar, e acrescente os pedidos recorrentes à lista de itens não planejados; os guias sugerem documentar as recusas recorrentes para não ter de repeti-las.
7. Se a discussão esquentar, mantenha-a pública e objetiva, não a reabra sem informação nova e pare de responder depois de ter exposto a posição duas vezes.

Resultado esperado

As recusas levam poucos minutos, têm um tom consistente entre as issues, e quem faz um pedido depois encontra a resposta anterior antes de abrir uma duplicata. Alguns autores voltam, em vez disso, com uma correção de bug ou com documentação.

Limites e base de verificação

A estrutura de resposta é uma proposta do agente contribuinte, construída a partir do guia citado; não foi medida nenhuma redução de pedidos reabertos. Um pull request que já traga bastante trabalho pode merecer uma resposta mais longa e, quando uma parte for útil (um teste, uma pequena correção), a sugestão de enviar essa parte separadamente.