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

1. Puedes salir. 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, tome esa energía y póngala directamente en otra cosa: "siga adelante" en otras palabras.

2. Puedes hacerlo. No hay razón para que tengas que trabajar con nadie. Ten cuidado, mejora el código y deja que los demás sigan teniendo un pequeño ego-fest propio. Su nuevo proyecto simplemente competirá con el anterior y depende de usted si lo logra, o el anterior lo supera en términos de usuarios y características.

3. Puede participar con el resto del equipo de desarrollo en el proyecto para expresar sus inquietudes. No lo haga personal, pero tenga en cuenta que no está satisfecho con la rotación de código, o la falta de procesos de calidad establecidos, o no está contento de que las nuevas decisiones se eliminen sin el consentimiento de todos. O bien se le dirá que no hay nada lo suficientemente malo como para cambiar, o que algunos otros coincidan con usted en que el equipo necesita arreglar las cosas. Eso podría terminar con el chico disruptivo perdiendo su acceso de compromiso. Tal vez todos estén de acuerdo en que algunos de los cambios no son mejoras y 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 se presenta y cambia las rutinas seguras y cómodas a las que se ha acostumbrado, pero se puede decir que tener a alguien que viene y agitar las viejas y acogedoras prácticas son cosas buenas en sí mismas.

Lo has dejado un poco claro exactamente cuál es tu función aquí. La respuesta depende de cómo encajas.

Si está liderando el proyecto y controlando el repositorio de git

Recuperar el control. Si este tipo está haciendo confirmaciones que no le gustan sin consultarle, elimine su acceso directo de confirmación. Él 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 genere confianza. No es necesario y no debes dar acceso completo de inmediato.

Si alguien más controla el repositorio

Exprese sus inquietudes a la persona que lo hace y fomente un proceso más disciplinado para planificar y aprobar cambios. Si el liderazgo no está sujeto a un proceso, entonces puede elegir aceptar el status quo y seguir contribuyendo, puede dividir el proyecto y trabajar en su propia versión (traer 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 tratando con esto.

Por favor, perdona mi franqueza, pero tu publicación se lee como una perorata.

Dices que es el otro chico que quiere cambios irreflexivos, pero luego te contradices cuando hablas de tu nuevo programa Java brillante.

Tómate un descanso; no es una calle de sentido único, intente encontrar compromisos (si desea continuar trabajando en el proyecto, forking es la decisión más fácil, pero no lo llevará a ningún lado útil, aunque puede ser difícil) tu ego).

También piense detenidamente sobre la división del trabajo en el proyecto - las guerras por el territorio son inevitables si no tiene límites limpios 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. Equilibrio entre productividad y estabilidad. Para tomar prestada una analogía de los juegos de estrategia, un equipo debe consistir en una combinación de Boom, Turtle and Rush , y sus compañeros de equipo deben estar preparados para cambiar roles en respuesta a la situación.
   • Cuando uno está en una locura por la 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)
   • garantía de calidad
     • Pruebas manuales (exploratorias)
     • Pruebas automatizadas
   • Documentación
   • Refactorización y limpieza de código
   • Realice estudios de usuarios para recopilar ideas para mejoras
   • etc.
2. Un proyecto puede ser modularizado (como en la arquitectura de software), o incluso compartimentarse (como en la gestión de proyectos) para que cada módulo pueda trabajarse de forma independiente.
   • En general, la mayoría de los programas que contienen tanto un front-end como un back-end deben modularizarse, ya que tienen una velocidad de desarrollo diferente.
   • El software rico en UX puede ser difícil de modular debido a su uso intensivo de enrutamiento de eventos entre módulos.
   • El mantenedor de un proyecto puede querer mantener el proyecto simple evitando la modularización.
3. Rama de funciones . Cada desarrollador puede bifurcar el proyecto, trabajar en su mascota favorita y solicitar la combinación cuando la implementación esté completa. El desarrollador principal puede tener la última palabra sobre si aceptar la fusión.

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

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

Como mínimo:

• La licencia que utilizará 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 las notificaciones de DMCA o los trolls de patentes)
• Quién administrará las finanzas para el proyecto (pagando los gastos del servidor y manteniendo en contabilidad los ingresos o donaciones de publicidad)
• ¿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 radica fundamentalmente en que diferentes personas piensan de diferentes maneras. Las características que consideras muy importantes no son en absoluto importantes para otras personas.

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

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

Este es un ejemplo de cosas que se deben evitar: por ejemplo, una gran cantidad de programadores de c ++ piensan que el código que no usa la biblioteca STL está roto. Otros programadores piensan que todas las dependencias de bibliotecas externas están dañadas, incluido STL. Dichos conflictos simplemente no pueden resolverse de manera adecuada (ambas situaciones no pueden satisfacerse de manera simultánea) y las personas más problemáticas presionarán su opinión sin importar con qué oposición se encuentren.

Cuatro opciones, diría yo.

1. echarlo fuera. Eres (supuestamente) todavía el tipo principal en este proyecto; revoca sus privilegios de empuje y llámalo día. El resultado más probable es que él finalice el proyecto, divida a su comunidad, y luego se desate una guerra, y cuando el polvo se asiente, uno de los tenedores será el popular.
2. Bifurca y continúa en otro lado. Menos agresivo que 1., pero las consecuencias son las mismas. Sin embargo, deberá estar activo en la comunidad para atraer a las personas a su lado.
3. Déjalo, deja que haga lo que está haciendo, cálmate y espera lo mejor.
4. Discuta con la comunidad, haga un compromiso según sea necesario y resuelva la situación.

Personalmente, prefiero la opción 4.

Google tuvo un par de charlas técnicas sobre esto hace unos años. Míralos: 1 , 2 . En pocas palabras:

1. Comprender: : 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. Fortificar : construir una comunidad saludable con normas sociales de cortesía, respeto, confianza y humildad.
3. Identificar : busque signos reveladores de personas venenosas (hay demasiadas para enumerarlas, pero si está haciendo esta pregunta, es probable que ya conozca a muchas de ellas).
4. Desinfecte : mantén la calma y mantente firme, sigue sin reaccionar ante insultos, desaires, desafíos, falta de respeto, etc., y persiste en reforzar las normas de tu comunidad.

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

No puede simplemente dejar de fumar sin hacer un esfuerzo por 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 ocurren en cualquier equipo de desarrollo, puede ser realmente difícil.

Habiendo dicho eso, creo firmemente que debería expresar sus inquietudes. Puede escribirlos en el correo electrónico y mostrárselos a sus amigos de confianza que no forman parte del equipo y tienen poco o ningún interés en lo que 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, se adhieren a los hechos. No acuses ni culpes. Solo datos que es difícil hacer algo por ti porque falta 'blah'. Por qué falta 'blah' debe quedar claro para todos los miembros del equipo, es decir, "el nuevo programador" se eliminó o no se logró algo.

Una vez más, 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.

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