¿Cómo deben ser gestionados los propietarios por los aportes a un proyecto de código abierto?

Al administrar un proyecto de código abierto (utilizando un servicio como GitHub), ¿cómo se respondería a lo siguiente:

Alguien ha enviado amablemente un parche para agregar una nueva función o solucionar un problema. Se produce cualquiera de las siguientes situaciones:

El código fuente no cumple con una o más convenciones de nomenclatura, etc.
Siento que el código fuente podría mejorarse de cierta manera. Quizás se pueda lograr el mismo efecto con una fuente mucho más simple, o quizás se necesitaría otra característica útil.

Q1. ¿Es aceptable para mí alterar la fuente enviada? (¿Es esto posible en GitHub?)

Q2 ¿Deberían rechazarse todas estas presentaciones de acuerdo con las pautas de presentación?

Q3. En caso afirmativo a Q2, ¿qué pasa con una idea realmente clara que se implementó de manera deficiente? ¿Es aceptable para mí seguir adelante y crear el mío?

Quiero alentar la contribución, pero al mismo tiempo es importante mantener un cierto estándar.

open-source github

— Lea Hayes
fuente

Respuestas:

Configure, si aún no lo ha hecho, un documento que describa los estándares del proyecto. Asegúrese de describir todo lo que considere importante al contribuir con código a su proyecto.

Luego, responda a la persona que proporcionó el código que detalla que aprecia mucho la contribución y que le gustaría incluir el parche, pero hay algunos problemas. Proporcione un enlace al documento y cite los problemas particulares que ve. Luego, pídale a esa persona que solucione los problemas y vuelva a enviar el código.

— Jeremy Heiler
fuente

Creo que Linux Kernel tiene algún tipo de área de "cambios que necesita mejoras" para este escenario.

— seppo0010

A la larga, beneficiará al proyecto y a la comunidad en general si logra que las personas mejoren sus propios envíos. Pero está bien volver a implementar la función usted mismo, siempre que sea cortés al respecto.

— David Schwartz

He visto bastantes proyectos que automatizan algunas de estas cosas cada vez que solicitas un tirón.

— Andrew T Finnell

Solo una nota para aquellos que usan GitHub, si nombra el documento al que se hace referencia anteriormente CONTRIBUTING, se mostrará un enlace a este documento al enviar una solicitud de extracción. Puede ayudar a ahorrar algo de tiempo por adelantado si las personas pueden resolver problemas comunes por su cuenta primero.

— Michael Mior

Si no hay demasiados contribuyentes, y esta contribución es bastante valiosa, puede aceptar el parche como está, y luego, en la próxima confirmación, reescribir partes usted mismo, o formatearlo para confirmar los estándares de codificación. - Luego, luego, enviaría un correo electrónico al contribuyente, con un enlace a una diferencia de los cambios que realizó. Esperemos que el colaborador estudie el diff y envíe un parche mejor la próxima vez, que no necesita modificar.

Esta podría ser una buena idea, si aún no ha escrito ninguna guía de contribuyentes o documentos de estilo de codificación . De hecho, podría continuar de esta manera (aceptar y modificar parches, enviar enlaces por correo electrónico a diffs) durante un tiempo, hasta que haya notado los errores que cometen la mayoría de los contribuyentes. Y luego incluye solo esos errores en una Guía de contribuyentes y una Guía de estilo .

Si hace las cosas de esta manera, las respuestas a Q1-Q3 serían:

P1: Sí, edite el envío, en una confirmación posterior
P2: No corresponde (asumí que aún no ha escrito ninguna guía)
P3: Da las gracias y vuelve a escribirlo :-) (Quizás no tenga sentido aplicar un parche, si, en la próxima confirmación, lo reescribes por completo de todos modos)

— KajMagnus
fuente