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

65

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!

Nathan2055
fuente
46
¿Cómo puede una persona cambiar el sistema de versiones por sí mismo? Seguramente debe haber tenido un apoyo popular, al menos entre algunas de las personas. Y, a juzgar por otro comentario, hubo un cambio de licencia para limitarlo todo: ¿por qué no son más vociferantes cuando los fundamentos de su proyecto son sacudidos / reemplazados de repente?
Deer Hunter
32
Te estás perdiendo el punto de la pregunta. ¿Cómo se unió un recién llegado a su proyecto y aparentemente se hizo cargo de todo? Puede ser de código abierto, pero implica que hay un líder o un grupo de líderes, y presumiblemente esos / esos líderes serían los únicos que tienen la capacidad de cambiar porciones tan importantes de cómo se opera el proyecto.
alroc
35
Este es tu proyecto en Github, ¿correcto? ¿Hay alguna razón por la que no puede eliminar su acceso al proyecto? ¿O hacer que haga su propio tenedor del que puede sacar si le gustan los cambios? Si alguien solo tomara por su cuenta cambiar la versión del código en un proyecto mío, se iría de inmediato.
GrandmasterB
66
¿Qué haces? Publica en TheDailyWTF y comparte el enlace con todos. Lo avergonzarás para que se someta.
rath
24
Honestamente, e independientemente de los otros problemas en juego aquí, reemplazar un script de Python con un programa gráfico de Java para enviar software a un sitio web me parece una locura de ingeniería excesiva.
sam hocevar

Respuestas:

55
  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.

gbjbaanb
fuente
2
Propondría un tenedor ();
ott--
1
¿Por qué se deja salir como solución # 1? Si el proyecto es realmente tan emocionante, ¿no debería ser esa la última opción?
Deer Hunter
2
@DeerHunter: No leí el orden de las posibilidades como orden de preferencia, pero es útil tener 1,2 en primer lugar ya que estas posibilidades pueden informar la discusión de 3.
hardmath
36
las opciones se enumeran en orden de más fácil de escribir.
gbjbaanb
Cambia el # 3 con el # 1, tienes que retroceder porque un lobo solitario sin tener en cuenta nada más puede destruir un buen proyecto.
Jonathan Neufeld
39

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.

Ben McCormick
fuente
23

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.

Cazador de ciervos
fuente
44
@ Nathan2055 - Simple y trabajar es mejor, en mi libro (tal vez solo soy yo). De todos modos, parece que el proyecto está a la deriva sin mucha orientación.
Deer Hunter
1
Estoy de acuerdo con la parte a la deriva. Una de las cosas que olvidé mencionar es que el mismo desarrollador volvió a aplicar el proyecto al azar sin avisar a nadie.
Nathan2055
24
¿Cómo, exactamente, un nuevo desarrollador cambió unilateralmente la licencia en un cuerpo de código existente sobre el que no tiene control exclusivo de derechos de autor? ¿Cómo obtuvo ese acceso / autoridad y por qué no se lo han quitado?
KutuluMike
77
Toda esta situación no cuadra. Nadie puede ir y cambiar unilateralmente la licencia en un proyecto de sistema operativo. Como no lo has aceptado y (supongo) que has hecho contribuciones, su cambio significa ponerse en cuclillas.
Norcross
99
@ Nathan2055 Cambiar la licencia de un proyecto sin autorización probablemente sea motivo de despido instantáneo, incluso en proyectos de código abierto. El hecho de que sea de código abierto no significa que algún tipo aleatorio pueda entrar y asumir el control. No importa cuán épicas sean sus habilidades de programación, si no puede trabajar en un equipo, no lo quiere allí y necesita hablar con él y / o echarlo. A menos que no nos cuentes todo ..
Thomas
10

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.

rwong
fuente
1
+1 para la gobernanza. Tarde o temprano, todos los proyectos de código abierto necesitan algunas reglas escritas, así como algún código, ya sea una gobernanza completa para proyectos grandes, o simplemente un código de conducta simple (como wiki.gnome.org/CodeOfConduct ) para cualquier foro, lista de correo , bases de datos de errores o SCCS que todos comparten.
calum_b
9

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.

tp1
fuente
Un buen punto sobre la división del trabajo.
Deer Hunter
3
Nunca mire lo que decidieron otros programadores, solo confíe en ellos. Suena peligroso para mi. ¿Qué pasa con el control de calidad?
Stephan
6

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.

tdammers
fuente
6

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.

Curtosis
fuente
3
¿Le importaría ampliar un poco lo que tiene cada uno de estos recursos y por qué los recomienda como respuesta a la pregunta que se hace? Las "respuestas de solo enlace" no son bienvenidas en Stack Exchange
mosquito
1
Resumen agregado, ¿cómo es eso?
Kurtosis
5

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.

Schultz9999
fuente
77
"No puedes simplemente dejar de fumar" ... Sí, puedes . No es una opción tomar a la ligera, ya que significa que quemará todos los puentes con todos los demás en el equipo si lo hace, pero si la situación es lo suficientemente mala (hasta el punto de causar angustia emocional), alejarse siempre es una opción .
Shadur