Rechazar una solicitud de funcionalidad sin perder a quien la propuso

Objetivo

Cerrar una solicitud que el proyecto no va a implementar de una manera que quien la pidió pueda aceptar, que otras personas lectoras puedan aprender de ella, y que quien mantiene el proyecto no tenga que repetir.

Requisitos previos

Un alcance escrito (para qué sirve el proyecto y qué deja fuera deliberadamente) y, si es posible, una lista de «no planificado» en la documentación. Las Open Source Guides lo expresan con claridad: dejar las cosas por escrito facilita decir que no, porque un rechazo vinculado a los criterios declarados del proyecto se siente menos personal que uno vinculado al gusto de quien mantiene el proyecto.

Pasos

1. Responder dentro del plazo indicado en CONTRIBUTING. Las guías desaconsejan dejar abierta una solicitud no deseada por culpabilidad; un hilo abierto se lee como un «quizá» y atrae más trabajo.
2. Agradecer la solicitud o el pull request; si se escribió código, indicar qué tenía de bueno.
3. Enunciar la decisión en una frase, y después el motivo en una frase más, vinculado al alcance, al costo de mantenimiento o a un principio de diseño, no al gusto.
4. Ofrecer una vía: un punto de extensión o de enganche (hook o plugin), un paquete externo, un fork, o una solución alternativa. Las guías describen los forks y los puntos de extensión como resultados legítimos, no como fracasos.
5. Indicar qué cambiaría la decisión, si algo lo hiciera (un caso de uso concreto de varios usuarios, una persona que mantenga la nueva área). Si nada lo haría, decirlo así.
6. Cerrar el issue con una etiqueta de «no planificado» para que la decisión sea localizable, y añadir las solicitudes repetidas a la lista de «no planificado»; las guías sugieren documentar los rechazos recurrentes para evitar repetirlos.
7. Si el hilo se caldea, mantenerlo público y objetivo, no reabrirlo sin información nueva, y dejar de responder una vez que la postura se haya enunciado dos veces.

Resultado esperado

Los rechazos toman pocos minutos, se leen de forma consistente entre issues, y quienes solicitan algo más tarde encuentran la respuesta anterior antes de abrir un duplicado. Algunas personas solicitantes regresan con una corrección de errores o documentación en su lugar.

Límites y base de verificación

La estructura de la respuesta es la propuesta del agente colaborador basada en la guía citada; no se mide ninguna reducción de solicitudes reabiertas. Un pull request que ya contiene trabajo sustancial puede merecer una respuesta más larga y, cuando una parte resulta útil (una prueba, una corrección pequeña), una sugerencia de enviar esa parte por separado.