Como faço para lidar com um programador difícil ingressar em um projeto de código aberto?

Eu tenho um script de código aberto para um site específico (estou tentando não chamar nada pelo nome aqui) que eu e alguns outros desenvolvedores recentemente mudamos para o GitHub. Temos vários novos desenvolvedores desde que mudamos para o novo sistema, incluindo um muito ativo em particular. No entanto, este ativo começou a mudar grande parte do projeto.

Primeiro, ele excluiu nosso sistema de versões (não como o Git, mas assim - chamamos de versões v4.1.16) e disse que seria melhor simplesmente enviar o código para o site quando acharmos que está pronto. Agora não há lugar centralizado para colocar notas de lançamento, o que se tornou irritante.

O que me deixou quase pronto para arrumar minhas malas e partir foi o script push. Outro desenvolvedor do projeto escreveu um script simples baseado em Python. Como mantemos várias versões do script online em vários lugares, comecei a codificar um programa Java maior com uma interface gráfica que substituirá o script Python. Fui ao IRC para notificar a todos sobre isso, e recebi uma resposta muito irritante do programador dizendo que o script antigo baseado em Python pode fazer tudo o que o meu pode fazer e é muito mais leve (ele também comentou sobre o fato de que pensava Python era melhor que Java e assim por diante). Examinei o código do script de envio antigo e vi que nenhum dos recursos que ele disse existir estava lá.

Então agora eu quero saber o que fazer. Eu gastei muito do meu tempo nesse projeto, por isso não quero me levantar e sair, mas acho difícil trabalhar com esse novo desenvolvedor. Por outro lado, ele agora é o principal colaborador do projeto, com mais comprometimentos do que o desenvolvedor principal. Não tenho muita certeza do que fazer sobre isso. Alguém mais teve esse problema? Se sim, o que você fez?

ATUALIZAÇÃO 1 : Desabilitei o acesso de confirmação de todos e estou solicitando que as pessoas passem por solicitações de recebimento. Também propus várias medidas para corrigir os outros problemas. Todo mundo não mostrou nenhum suporte para isso. O desenvolvedor problemático simplesmente disse que as pessoas que não seguem de perto a "ação de confirmação" podem pensar que o projeto é desorganizado quando realmente não é. Obviamente, não concordo com isso, por isso estou pensando seriamente em me demitir do projeto.

ATUALIZAÇÃO 2 : O desenvolvedor líder começou a reclamar do fato de que um dos meus commit supostamente excluiu três novas linhas no código (o commit de reversão apareceu logo após eu postar a discussão e nem sequer faz referência ao meu "commit"), e então os dois começaram a discutir se revogariam meu acesso de confirmação. Então, eu fiz a coisa lógica e saí do projeto. Obrigado por sua ajuda com isso todos!

1. Você pode sair. Não é a coisa mais construtiva a fazer, mas às vezes é a única opção. Se o fizer, não se sente e geme sobre como teve que desistir, pegue essa energia e coloque-a diretamente em outra coisa - 'seguir em frente' em outras palavras.

2. Você pode bifurcar. Não há motivo para você trabalhar com alguém. Bifurque-se, melhore o código e deixe que os outros continuem tendo um pouco de festa do ego. Seu novo projeto simplesmente competirá com o antigo e depende de você, se você o obtém sucesso ou se o antigo o vence em termos de usuários e recursos.

3. Você pode se envolver com o restante da equipe de desenvolvimento no projeto para expressar suas preocupações. Não o torne pessoal, mas certifique-se de que você está insatisfeito com a rotatividade do código, ou com a falta de processos de qualidade estabelecidos, ou insatisfeito com o fato de as novas decisões serem adotadas sem o consentimento de todos. Você será informado de que nada está errado o suficiente para mudar ou fará com que outros concordem que a equipe precisa consertar as coisas. Isso pode acabar com o cara perturbador perdendo o acesso de confirmação. Talvez todos concordem que algumas das mudanças não são melhorias e o projeto precisa ser revertido. (Esta última opção é o resultado mais provável, a menos que se transforme em um argumento massivo de opiniões consolidadas.)

Pode ser difícil quando alguém aparece e muda as rotinas seguras e confortáveis ​​com as quais você se acostumou, mas pode-se dizer que ter alguém aparecendo e agitando as práticas antigas e aconchegantes são boas coisas em si.

Você deixou um pouco claro exatamente qual é o seu papel aqui. A resposta depende de como você se encaixa.

Se você está liderando o projeto e controlando o repositório git

Retome o controle. Se esse cara está fazendo confirmações que você não gosta sem consultá-lo, remova o acesso direto da confirmação. Ele pode dividir o projeto e fazer solicitações pull para mesclar seus commits. É assim que o código aberto deve funcionar até que um usuário crie confiança. Você não precisa e não deve fornecer acesso completo imediatamente.

Se outra pessoa controla o repositório

Expresse suas preocupações à pessoa que o faz e incentive um processo mais disciplinado para planejar e aprovar mudanças. Se a liderança não é passível de processo, você pode aceitar o status quo e continuar contribuindo, pode dividir o projeto e trabalhar em sua própria versão (trazendo alguém que concorda com você) ou pode optar por sair e trabalhar em outras coisas. De qualquer forma, você não precisa continuar lidando com isso.

Por favor, perdoe minha franqueza, mas seu post parece um discurso retórico.

Você diz que é o outro cara que quer mudanças sem sentido, mas depois se contradiz ao falar sobre esse seu novo e brilhante programa Java.

Dar um tempo; não é uma via de mão única, tente encontrar compromissos (se você quiser continuar trabalhando no projeto - bifurcação é a decisão mais fácil, mas não o levará a nenhum lugar útil, embora possa acariciar seu ego).

Por favor, pense bem sobre a divisão do trabalho no projeto - as guerras territoriais são inevitáveis ​​se você não tiver limites limpos, informando quem é competente em quê . Sim, às vezes você precisa confiar no julgamento de outras pessoas.

Já é mencionado em várias respostas que a divisão do trabalho é uma maneira de reduzir conflitos. Aqui estão alguns exemplos concretos:

1. Equilibre produtividade versus estabilidade. Para emprestar uma analogia aos jogos de estratégia, uma equipe deve consistir em uma mistura de Boom, Turtle e Rush , e os colegas de equipe devem estar preparados para mudar de função em resposta à situação.
   • Quando alguém está em mania de produtividade, outros podem trabalhar em:
   • Outras características
   • Corrigindo erro
   • Especificações (gerenciando solicitações de novos recursos e verificando se o software atende aos critérios acordados)
   • Garantia da Qualidade
     • Teste manual (exploratório)
     • Teste automatizado
   • Documentação
   • Refatoração e limpeza de código
   • Realizar estudos com usuários para coletar idéias para melhorias
   • etc.
2. Um projeto pode ser modularizado (como na arquitetura de software) ou até mesmo compartimentado (como no gerenciamento de projetos), para que cada módulo possa ser trabalhado independentemente.
   • Em geral, a maioria dos softwares que contém um front-end e um back-end deve ser modularizada, porque possui velocidade de desenvolvimento diferente.
   • O software rico em UX pode ser difícil de modularizar devido ao uso intenso do roteamento de eventos entre módulos.
   • O mantenedor de um projeto pode querer manter o projeto simples, evitando a modularização.
3. Ramo de recursos . Cada desenvolvedor pode bifurcar o projeto, trabalhar em seu recurso favorito para animais de estimação e solicitar a mesclagem quando a implementação estiver concluída. O desenvolvedor líder pode ter uma opinião final sobre a aceitação da mesclagem.

Além do aspecto de evitar conflitos, é evidente que o projeto pode ter governança insuficiente .

Por que a governança é importante? Imagine um dia um ex-companheiro de equipe pegou um pedaço do software e processou a equipe por infração. Ou a equipe processada pelo troll de patentes. Ou alguém que não sabe quem decidiu enviar avisos do DMCA para o site de hospedagem do projeto e exigir que o código-fonte do projeto seja apagado.

No mínimo:

• A licença a ser usada por todo o código-fonte contribuído
• A (s) licença (s) sob a qual o código-fonte do projeto pode ser publicado
  • Caso seja solicitada uma nova licença pública, como obter o consentimento de todos os colaboradores
• Quem pode ter acesso administrativo ao projeto
• Quem será designado para responder a solicitações legais (como avisos da DMCA ou trolls de patentes)
• Quem gerenciará o financiamento do projeto (pagando as despesas do servidor e contabilizando as receitas ou doações de publicidade)
• Quem terá direito de voto para incluir novos membros e expulsar membros.
• etc.

A maioria dos sites de projetos de código aberto pode fornecer cartas de governança de projetos prontas.

Eu já vi o problema antes. Mas depois de alguns anos você realmente se cansa do projeto, então minha solução foi sair do projeto . Pode não funcionar para você, mas o problema é fundamentalmente que pessoas diferentes pensem de maneiras diferentes. Os recursos que você considera muito importantes não são de todo importantes para outras pessoas.

Um bom plano seria dividir tarefas de pessoas diferentes. Se você pode concordar com as pessoas que parte do projeto é de responsabilidade de cada pessoa, apenas uma pessoa está tomando decisões em determinada parte do projeto. Mas o trabalho em equipe é sempre difícil. Você nunca vai gostar das decisões tomadas por outros programadores. A melhor solução é nunca olhar para o que outros programadores decidiram. Apenas confie neles para fazer a coisa certa é suficiente.

Objetivo comum concentrará seus esforços nas coisas importantes. Todo mundo que trabalha na mesma direção é difícil de conseguir, e os conflitos de qualquer maneira acontecem. Decidir um objetivo comum exige saber qual é o status atual do projeto e, em seguida, decidir onde ele deve estar após algum tempo.

Aqui está um exemplo de coisas a serem evitadas: Por exemplo, um grande número de programadores de c ++ acha que o código que não está usando a biblioteca STL está quebrado. Outros programadores pensam que todas as dependências de bibliotecas externas estão quebradas, incluindo STL. Tais conflitos simplesmente não podem ser resolvidos adequadamente - ambas as situações não podem ser preenchidas simultaneamente - e as pessoas mais problemáticas vão expor sua opinião, independentemente da oposição que encontrarem.

Quatro opções, eu diria.

1. Chute-o para fora. Você (supostamente) ainda é o cara principal nesse projeto; revogar seus privilégios push e encerrar o dia. O resultado mais provável é que ele bifurque o projeto, divida sua comunidade e, em seguida, uma guerra se solte; e quando a poeira baixar, um dos garfos será o popular.
2. Bifurque-o e continue em outro lugar. Menos agressivo que 1., mas as consequências são as mesmas. Você precisará ser ativo na comunidade para atrair as pessoas para o seu lado.
3. Deixe assim: deixe-o fazer o que está fazendo, acalme-se e torça pelo melhor.
4. Discuta com a comunidade, faça concessões conforme necessário e resolva a situação.

Pessoalmente, eu prefiro a opção 4.

O Google teve algumas conversas sobre tecnologia há alguns anos. Assista-os:1 ,2 . Em poucas palavras:

1. Compreender : entenda a motivação da sua comunidade para trabalhar em seu projeto versus todos os outros custos de oportunidade e preserve esses motivos.
2. Fortificar : Construa uma comunidade saudável com normas sociais de cortesia, respeito, confiança e humildade.
3. Identifique : procure sinais reveladores de pessoas venenosas (muitas para listar, mas se você está fazendo essa pergunta, provavelmente já conhece muitas delas).
4. Desinfetar : Fique calmo e mantenha-se firme, permaneça não reativo a insultos, negligências, desafios, desrespeito, etc., e persistente no reforço das normas da sua comunidade.

Também está disponível um esboço detalhado, se você preferir ler em vez de assistir.

Você não pode simplesmente desistir sem se esforçar para expressar suas preocupações e dificuldades. Eu sei que pode ser difícil. Se você e os membros de sua equipe são jovens o suficiente para não experimentar em primeira mão muitos problemas sociais que acontecem em qualquer equipe de desenvolvimento, pode ser muito difícil.

Dito isto, acredito firmemente que você deve expressar suas preocupações. Você pode anotá-las no e-mail e mostrá-las a seus amigos de confiança que não fazem parte da equipe e têm pouco ou nenhum interesse no que fazem. Nesse caso, você pode obter um bom feedback para que as palavras do seu e-mail não sejam muito severas. Atenha-se aos fatos embora. Não acuse ou culpe. Apenas fatos de que é difícil fazer algo por você porque falta 'blá'. Por que falta 'blá' deve ser claro para todos os membros da equipe, ou seja, "o novo programador" excluiu ou não realizou nada.

Novamente, enviar este e-mail é difícil, mas por si só é uma ótima experiência que pode ser muito útil para você. Ótima lição para aprender.

PS: Eu não quis parecer muito parental. No entanto, é algo que eu diria para qualquer pessoa, incluindo meus filhos.