¿De quién es la responsabilidad de un parche de corrección de errores?

Una situación que ha surgido varias veces en proyectos de código abierto es la siguiente:

1. Noto un error en nuestro despliegue y descubro un parche de pirateo rápido. (Por ejemplo, simplemente comentando el código que realmente no necesitamos).
2. Dedico un poco de esfuerzo extra para descubrir el error real, crear un parche y enviarlo a través de una solicitud de extracción de Git o similar.
3. Mi solicitud de extracción es rechazada. Quizás el parche fue imperfecto (por ejemplo, incluyó líneas que no debería tener), quizás violó el estilo de codificación, quizás tuvo otras ramificaciones. O tal vez hice algo mal en Git: la solicitud de extracción debería haber sido modificada o algo así. Un responsable de mantenimiento proporciona comentarios sobre cómo mejorar el parche y solicita que lo vuelva a enviar.

En este punto, estoy confundido acerca de qué tan lejos debo proceder. En lo que a mí respecta, no tengo ningún problema: lo arreglé nuevamente en el paso 1. Informé el problema, incluso tomé medidas para solucionarlo en otros. Pero no creo que sea "mi" solicitud de extracción, por lo que no creo que deba asumir la responsabilidad de mejorar el parche.

Una situación particular que me molesta es que después de discutir sobre las fallas de mi parche, lleguemos a un acuerdo sobre una lista de correo sobre cuál sería el parche correcto (es decir, cómo debería comportarse, a veces incluyendo cada línea de código enunciada). Entonces, todavía se presume que es mi responsabilidad generar y enviar el parche.

¿Existe una etiqueta estándar en estas situaciones? ¿Cómo se resuelven? ¿Mi reacción es inusual? ¿Hasta dónde se espera que llegue para que se acepte su corrección de errores?

(Tenga en cuenta que cuando digo "proyecto de código abierto", algunos de estos son muy pequeños, pero pueden no ser pasatiempos, simplemente pequeños proyectos de software que son útiles para varias organizaciones, que comprometen recursos de desarrolladores para trabajar en ellos. En caso de que la respuesta sea obvia es "arreglar el parche y volver a enviarlo", entiendo que tengo responsabilidades con mi empleador para trabajar en cosas que son beneficiosas para ellos. Pasar tiempo arreglando un error que no nos afecta estaría mal ...)

En lo que a mí respecta, si encuentra un error o tiene una solicitud de mejora, no contribuye al proyecto y ha enviado un informe de defectos a través de los canales apropiados, ya está. En términos de retribución a la comunidad, cualquier persona que esté utilizando un proyecto de código abierto y encuentre un defecto debe informarlo.

Intentar encontrar una solución, diseñarla e implementarla es una ventaja para el proyecto. Si ha hecho esto, puede ser una buena idea enviarlo, ya sea a través de una solicitud de extracción o quizás enviando deltas de archivos al equipo de desarrollo junto con el informe de defectos o la solicitud de mejora para darles algo con lo que trabajar. Sin embargo, no tienen la obligación de aceptar su contribución al proyecto.

Esperar que un usuario contribuya con parches me parece incorrecto. Es bastante fácil participar en una discusión sobre un problema, pero es una inversión de tiempo mucho mayor encontrar una solución. Ningún proyecto debe esperar que los no contribuyentes se conviertan en contribuyentes solo para solucionar un solo problema.

Proceda tan lejos como esté dispuesto a soportarlo. Sería bueno arreglar tu parche y compartirlo con el mundo en el enlace principal, pero si el responsable no lo quiere, encoge de hombros. Puede publicar su problema en algún lugar y el parche para solucionarlo, de modo que otros en el mismo barco puedan buscar una solución.

Y no estás sin problema. Su parche no estará en la próxima actualización. Por lo tanto, tendrá que volver a armar y esperar que funcione o masajearlo en su lugar, cada vez que tome una nueva versión. Por lo tanto, incluirlo en el proyecto principal le ahorrará a usted y a su empresa tiempo a largo plazo.

Es un dolor para ti, pero estás contribuyendo a la comunidad. Ciertamente aprecio todo el trabajo que aportaron los colaboradores. No es como un software de calidad, solo por arte de magia de las masas. Alguien tiene que hacer el trabajo. (Entonces, ¿quién es increíble? Eres increíble). Si no lo desea, anuncie a la comunidad que, si bien aprecia la discusión sobre cómo debería ser, simplemente está demasiado ocupado para hacerlo. Quiero decir, ¿qué van a hacer? ¿Cortar tu salario?

Hay un principio que hace que la cultura de código abierto sea más fácil de entender: la persona que hace el trabajo decide en qué trabajar. Este es uno de sus atractivos en comparación con los trabajos diarios de los desarrolladores. Su prioridad n. ° 1 podría ser la n. ° 50 en su cartera de pedidos. Si no arregla su solicitud de extracción, es probable que finalmente llegue a la parte superior y se encargarán de ello. Sin embargo, si se lo pone fácil, se encargarán de ello ahora.

La otra razón por la que le piden que arregle su solicitud de extracción es más magnánima. Quieren que obtenga crédito por su contribución, por pequeña que sea. Si hace la corrección, su nombre es el que está en el campo de autor de la confirmación. La mayoría de las personas están lo suficientemente orgullosas de su contribución como para querer verlo, por lo que el modus operandi predeterminado de los mantenedores es dejarlos.

En lo que respecta a su responsabilidad con su empleador, si su empresa se basa en este código, no le está perjudicando. Los empleadores conocen el beneficio de que un trabajador se tome el tiempo para afilar sus herramientas.

AFAIK, la forma de código abierto es que la responsabilidad de corregir los errores recae en quien se preocupa lo suficiente por el error para manejar la carga y garantizar que se solucione. Dependiendo de las circunstancias, he hecho todo, desde simplemente ignorar un problema hasta luchar (proporcionar parches y discutir para que sean aceptados) para asegurarme de que se solucionó.

Todo está bien, simplemente no dejes que las personas que administran el proyecto esperen algo incorrecto de ti (es decir, dales la esperanza de que solucionarás el problema adecuadamente mediante las opciones de discusión y luego no harás nada), probablemente estén al tanto de más problemas que ellos. pueden manejarse solos e intentarán hacer un contribuyente recurrente de usted si pueden.

El error original solo puede afectarlo, por lo que le interesa obtener el envío haciendo lo que sea necesario para que su parche cumpla con los requisitos. De lo contrario, la próxima versión que extraiga (porque necesita otras soluciones) no tendrá su solución.

No desea mantener una lista de parches que necesita aplicar cada vez que extrae una nueva copia del proyecto, es demasiado problema. Tómese un poco de tiempo extra y arreglelo permanentemente para que no tenga que lidiar con eso nuevamente.

Para un desarrollador de código abierto, hay dos tipos de problemas:

• (a) problemas sin parche
• (b) problemas causados ​​por un parche

Creo que a la mayoría de los desarrolladores / desarrolladores de paquetes de código abierto les ENCANTA la idea de ayudar a que un contribuyente no principal esté al día con sus parches.

Sin embargo, su objetivo principal es minimizar el número de problemas de tipo b. Es por eso que el listón está bastante alto.

Algunas personas lo superan. Se convierten en contribuyentes, o tal vez incluso en contribuyentes principales. Otros se rinden. El código abierto tiene una cierta naturaleza darwiniana: la supervivencia del más apto.

Te animo a seguir adelante y escupir tu contribución al punto donde el equipo la acepta. Una vez que haya hecho algunas contribuciones, confiarán en usted aún más, pero aún así debe asegurarse de que sus contribuciones sean impecables.

El resultado final lo vale totalmente. Cosas como poder decir "¿Codifico? Sí ... Estás ejecutando algo que escribí todos los días".