¿Cómo trato con un programador difícil que se une a un proyecto de código abierto?

Tengo un script de código abierto para un sitio específico (estoy tratando de no llamar a nada por su nombre aquí) que yo y algunos otros desarrolladores recientemente mudamos a GitHub. Hemos tenido varios desarrolladores nuevos desde que nos mudamos al nuevo sistema, incluido uno muy activo en particular. Sin embargo, este activo ha comenzado a cambiar gran parte del proyecto.

En primer lugar, eliminó nuestro sistema de versiones (no como Git, sino así, lo llamamos versiones v4.1.16) y dijo que sería mejor simplemente empujar el código al sitio cuando creamos que está listo. Ahora no hay un lugar centralizado para poner notas de lanzamiento, lo que se ha vuelto molesto.

Lo que me ha preparado para hacer las maletas e ir fue el guión de inserción. Otro desarrollador del proyecto escribió un simple script push basado en Python. Como mantenemos múltiples versiones del script en línea en varios lugares, comencé a codificar un programa Java más grande con una interfaz gráfica que reemplazará al script Python. Fui a IRC para notificar a todos al respecto, y recibí una respuesta muy molesta del programador diciendo que el viejo script basado en Python puede hacer todo lo que el mío puede hacer y es mucho más liviano (también comentó sobre el hecho de que pensaba Python era mejor que Java y así sucesivamente). Revisé el código del antiguo script de inserción y vi que ninguna de las características que dijo que existían estaban allí.

Así que ahora quiero saber qué hacer. He pasado gran parte de mi tiempo en este proyecto, así que no quiero levantarme e irme, pero me resulta difícil trabajar con este nuevo desarrollador. Por otro lado, ahora es el confirmador número 1 en el proyecto, con incluso más confirmaciones que el desarrollador principal. No estoy realmente seguro de qué hacer al respecto. ¿Alguien más ha experimentado este problema? Si asi es, ¿Qué hiciste?

ACTUALIZACIÓN 1 : he desactivado el acceso de confirmación de todos y solicito que las personas realicen solicitudes de extracción. También propuse varias medidas para solucionar los otros problemas. Todos los demás no han mostrado ningún apoyo para ello. El problemático desarrollador simplemente ha dicho que las personas que no siguen de cerca la "acción de compromiso" pueden pensar que el proyecto está desorganizado cuando realmente no lo es. Obviamente no estoy de acuerdo con esto, así que estoy considerando seriamente renunciar al proyecto.

ACTUALIZACIÓN 2 : El desarrollador principal comenzó a despotricar sobre el hecho de que una de mis confirmaciones supuestamente eliminó tres líneas nuevas en el código (la confirmación de reversión apareció justo después de publicar la discusión, y ni siquiera hace referencia a mi "confirmación"), y luego los dos comenzaron a discutir si revocar mi acceso de confirmación. Entonces, hice lo lógico y abandoné el proyecto. ¡Gracias por su ayuda con esto a todos!

1. Puedes dejarlo. No es lo más constructivo, pero a veces es la única opción. Si lo hace, no se siente y gime sobre cómo tuvo que renunciar, tomar esa energía y ponerla directamente en otra cosa: 'seguir adelante' en otras palabras.

2. Puedes bifurcarlo. No hay razón por la que tengas que trabajar con alguien. Bifurca, mejora el código y deja que los demás sigan teniendo un pequeño festival de ego propio. Su nuevo proyecto simplemente competirá con el anterior y depende de usted si tiene éxito o si el anterior lo supera en términos de usuarios y características.

3. Puede colaborar con el resto del equipo de desarrollo en el proyecto para expresar sus inquietudes. No lo haga personal, pero asegúrese de que no está contento con el cambio de código o la falta de procesos de calidad establecidos, o que no está satisfecho con el hecho de que las nuevas decisiones se eliminen sin el acuerdo de todos. Le dirán que nada está lo suficientemente mal como para cambiar, o algunos otros estarán de acuerdo con usted en que el equipo necesita arreglar las cosas. Eso podría terminar con el tipo disruptivo que pierde su acceso de confirmación. Tal vez todos estén de acuerdo en que algunos de los cambios no son mejoras y que el proyecto debe revertirse. (Esta última opción es el resultado más probable, a menos que se convierta en un argumento masivo de opiniones arraigadas).

Puede ser difícil cuando alguien viene y cambia las rutinas seguras y cómodas a las que te has acostumbrado, pero se podría decir que hacer que alguien venga y sacuda las viejas y acogedoras prácticas es algo bueno en sí mismo.

Has dejado un poco claro exactamente cuál es tu papel aquí. La respuesta depende de cómo encajas.

Si lideras el proyecto y controlas el repositorio git

Retoma el control. Si este tipo está haciendo confirmaciones que no te gustan sin consultarte, elimina su acceso de confirmación directa. Puede bifurcar el proyecto y hacer solicitudes de extracción para fusionar sus compromisos. Así es como debería funcionar el código abierto hasta que un usuario acumule confianza. No necesita, y no debe, dar acceso completo de inmediato.

Si alguien más controla el repositorio

Exprese sus inquietudes a la persona que lo hace y aliente un proceso más disciplinado para planificar y aprobar los cambios. Si el liderazgo no es susceptible a un proceso, entonces puede elegir aceptar el status quo y seguir contribuyendo, puede bifurcar el proyecto y trabajar en su propia versión (trayendo a cualquiera que esté de acuerdo con usted), o puede optar por irse y trabajar en otras cosas. En cualquier caso, no es necesario que continúe lidiando con esto.

Perdona mi franqueza, pero tu publicación se lee como una queja.

Dices que es el otro tipo que quiere cambios sin sentido, pero luego te contradices cuando hablas de este nuevo y brillante programa Java tuyo.

Tomar un descanso; no es una calle de sentido único, intente encontrar compromisos (si desea continuar trabajando en el proyecto, bifurcar es la decisión más fácil, pero no lo llevará a ningún lugar útil, aunque puede afectar su ego).

También piense detenidamente sobre la división del trabajo en el proyecto: las guerras territoriales son inevitables si no tiene límites claros que le indiquen quién es competente en qué . Sí, a veces tienes que confiar en el juicio de otras personas.

Ya se menciona en varias respuestas que la división del trabajo es una forma de reducir el conflicto. Aquí hay algunos ejemplos concretos:

1. Equilibre la productividad frente a la estabilidad. Para tomar prestada una analogía de los juegos de estrategia, un equipo debe consistir en una mezcla de Boom, Turtle y Rush , y los compañeros de equipo deben estar preparados para cambiar los roles en respuesta a la situación.
   • Cuando uno está en una locura de productividad, otros pueden trabajar en:
   • Otras características
   • Corrección de errores
   • Especificaciones (gestión de solicitudes de nuevas funciones y verificación de que el software cumple con los criterios acordados)
   • Seguro de calidad
     • Pruebas manuales (exploratorias)
     • Pruebas automatizadas
   • Documentación
   • Refactorización y limpieza de código
   • Realizar estudios de usuarios para recopilar ideas para mejoras
   • etc.
2. Un proyecto se puede modularizar (como en la arquitectura de software), o incluso compartimentar (como en la gestión de proyectos) para que cada módulo se pueda trabajar de forma independiente.
   • En general, la mayoría del software que contiene un front-end y un back-end debe modularizarse, ya que tienen una velocidad de desarrollo diferente.
   • El software rico en UX puede ser difícil de modularizar debido al uso intensivo del enrutamiento de eventos entre módulos.
   • El mantenedor de un proyecto puede querer mantener el proyecto simple evitando la modularización.
3. Característica rama . Cada desarrollador puede bifurcar el proyecto, trabajar en su característica favorita de mascotas y solicitar la fusión cuando se complete la implementación. El desarrollador principal puede tener la última palabra sobre si acepta la fusión.

Aparte del aspecto de evitar conflictos, es evidente que el proyecto puede tener una gobernanza insuficiente .

¿Por qué es importante la gobernanza? Imagine un día que un ex compañero de equipo tomó una parte del software y demandó al equipo por infracción. O el equipo demandado por el troll de patentes. O alguien que no sabe quién decidió enviar avisos DMCA al sitio de alojamiento del proyecto y exigir que se borre el código fuente del proyecto.

Como mínimo:

• La licencia para ser utilizada por todo el código fuente contribuido
• La (s) licencia (s) bajo las cuales se puede publicar el código fuente del proyecto
  • En caso de que se busque una nueva licencia pública, cómo obtener el consentimiento de cada contribuyente
• ¿Quién puede tener acceso administrativo al proyecto?
• Quién será designado para responder a solicitudes legales (como los avisos de DMCA o los trolls de patentes)
• Quién administrará la financiación del proyecto (pagando los gastos del servidor y contando los ingresos publicitarios o las donaciones)
• Quién tendrá derecho de voto para incluir nuevos miembros y expulsar a los miembros.
• etc.

La mayoría de los sitios de proyectos de código abierto pueden proporcionar cartas de gobierno de proyectos listas para usar.

He visto el problema antes. Pero después de unos años realmente te cansas del proyecto, así que mi solución fue abandonar el proyecto . Puede que no funcione para usted, pero el problema es fundamentalmente que diferentes personas piensan de diferentes maneras. Las características que crees que son muy importantes no lo son para otras personas.

Un buen plan sería dividir las tareas de diferentes personas. Si puede acordar con las personas qué parte del proyecto es responsabilidad de cada persona, entonces solo una persona está tomando decisiones en cierta parte del proyecto. Pero el trabajo en equipo siempre es difícil. Todavía nunca te van a gustar las decisiones tomadas por otros programadores. La mejor solución es nunca mirar lo que decidieron otros programadores. Solo confiar en ellos para hacer lo correcto es suficiente.

El objetivo común centrará sus esfuerzos en las cosas importantes. Es difícil llegar a todos los que trabajan en la misma dirección, y de todos modos se producirán conflictos. Decidir un objetivo común requiere saber cuál es el estado actual del proyecto y luego decidir dónde debe estar después de un tiempo.

Aquí hay un ejemplo de cosas para evitar: Por ejemplo, una gran cantidad de programadores de c ++ piensan que el código que no está usando la biblioteca STL está roto. Otros programadores piensan que cada dependencia de bibliotecas externas está rota, incluida STL. Tales conflictos simplemente no pueden resolverse adecuadamente, ambas situaciones no pueden cumplirse simultáneamente, y las personas más problemáticas presionarán su opinión sin importar la oposición que encuentren.

Cuatro opciones, creo.

1. Échalo afuera. Eres (supuestamente) todavía el tipo principal en este proyecto; revocar sus privilegios de empuje y llamarlo un día. El resultado más probable es que él bifurque el proyecto, dividiendo a su comunidad, y luego se desate una guerra, y cuando el polvo se calme, uno de los tenedores será el popular.
2. Bifurcarlo y continuar en otro lugar. Menos agresivo que 1., pero las consecuencias son las mismas. Sin embargo, tendrá que estar activo en la comunidad para atraer a las personas a su lado.
3. Déjalo así: solo déjalo hacer lo que está haciendo, cálmate y espera lo mejor.
4. Discuta con la comunidad, comprométase según sea necesario y resuelva la situación.

Personalmente, preferiría la opción 4.

Google tuvo un par de charlas tecnológicas sobre esto hace unos años. Miralos:1 ,2 . En una palabra:

1. Comprenda : comprenda la motivación de su comunidad para trabajar en su proyecto frente a todos los demás costos de oportunidad y conserve esas razones.
2. Fortifique : Construya una comunidad saludable con normas sociales de cortesía, respeto, confianza y humildad.
3. Identificar : Busque signos reveladores de personas venenosas (demasiados para enumerar, pero si hace esta pregunta, probablemente ya conozca a muchos de ellos).
4. Desinfectar : mantén la calma y mantente firme, no reacciones a los insultos, desaires, desafíos, falta de respeto, etc., y persiste en reforzar las normas de tu comunidad.

Un resumen escrito completo también está disponible si prefiere leer en lugar de mirar.

No puede dejar de fumar sin hacer un esfuerzo para expresar sus preocupaciones y dificultades. Sé que puede ser difícil. De hecho, si usted y los miembros de su equipo son lo suficientemente jóvenes como para no experimentar de primera mano muchos problemas sociales que suceden en cualquier equipo de desarrollo, puede ser realmente difícil.

Dicho esto, creo firmemente que debe expresar sus preocupaciones. Puede escribirlos en el correo electrónico y mostrárselos a sus amigos de confianza que no son parte del equipo y que tienen poco o ningún interés en lo que usted hace. En este caso, puede obtener una buena respuesta para que la redacción de su correo electrónico no sea demasiado dura. Sin embargo, atenerse a los hechos. No acusar ni culpar. Solo hechos de que es difícil hacer algo por ti porque falta 'bla'. Por qué falta 'bla' debe quedar claro para todos los miembros del equipo, es decir, "el nuevo programador" eliminado o no logró algo.

Nuevamente, enviar este correo electrónico es difícil, pero eso en sí mismo es una gran experiencia que puede ser muy útil para usted en el futuro. Gran lección para aprender.

PD: No quise sonar demasiado parental. Sin embargo, es algo que le diría a cualquiera, incluidos mis hijos.