Como faço para lidar com um programador difícil se juntar a um projeto de código aberto?

1. Você pode sair. Não é a coisa mais construtiva a ser feita, mas às vezes é a única opção. Se você fizer isso, não se sente e lamente sobre como você teve que desistir, pegar essa energia e colocá-la diretamente em outra coisa - 'seguir em frente' em outras palavras.

2. Você pode pagar por ele. Não há motivos para trabalhar com ninguém. Garfo, melhore o código e deixe que os outros continuem a ter um pequeno ego-fest próprio. Seu novo projeto irá simplesmente competir com o antigo e cabe a você se você o fizer com sucesso, ou se o antigo vencer você 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 faça isso de maneira pessoal, mas descubra que você está insatisfeito com a rotatividade de código, ou a falta de processos de qualidade estabelecidos, ou insatisfeito com o fato de as novas decisões serem simplesmente eliminadas sem o consentimento de todos. Você será informado de que nada está errado o suficiente para mudar, ou você terá alguns outros concordando com você que a equipe precisa consertar as coisas. Isso pode acabar com o cara perturbador perdendo seu acesso de commit. Talvez todos vocês 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 maciço de opiniões arraigadas.)

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 vindo e sacudir as velhas e aconchegantes práticas são coisas boas 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 estiver fazendo commits que você não gosta sem consultá-lo, remova o acesso direto dele. Ele pode bifurcar o projeto e fazer pedidos pull para mesclar seus commits. Isso é como o código aberto deve funcionar até que um usuário crie confiança. Você não precisa e não deve dar acesso total imediatamente.

Se alguém controla o repo

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

Por favor, perdoe a minha franqueza, mas seu post parece um discurso.

Você diz que é o outro cara que quer mudanças estúpidas, mas depois você se contradiz quando fala sobre esse novo e brilhante programa Java seu.

Faça uma pausa; não é uma rua de mão única, por favor, tente encontrar compromissos (se você quiser continuar trabalhando no projeto - bifurcação é a decisão mais fácil, mas não vai te levar a lugar nenhum, embora possa seu ego).

Por favor, pense também cuidadosamente sobre a divisão do trabalho no projeto - guerras territoriais são inevitáveis se você não tem limites claros dizendo a você quem é competente no que . Sim, você precisa confiar no julgamento de outras pessoas às vezes.

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

1. Equilibrar produtividade vs. estabilidade. Para emprestar uma analogia dos jogos de estratégia, uma equipe deve consistir de uma mistura de Boom, Turtle and Rush , e os colegas de equipe devem estar preparados para mudar de função em resposta à situação.
   • Quando se está em uma mania de produtividade, outros podem trabalhar em:
   • Outros recursos
   • Correção de erros
   • Especificações (gerenciando novas solicitações de recursos e verificando se o software atende aos critérios acordados)
   • Garantia de qualidade
     • Testes manuais (exploratórios)
     • Teste automatizado
   • Documentação
   • Refatoração e limpeza de código
   • Realize estudos de usuários para coletar ideias para melhorias
   • etc.
2. Um projeto pode ser modularizado (como na arquitetura de software), ou mesmo compartimentalizado (como no gerenciamento de projetos) para que cada módulo possa ser trabalhado de forma independente.
   • Em geral, a maioria dos softwares que contêm um front-end e um back-end devem ser modularizados, porque eles têm uma velocidade de desenvolvimento diferente.
   • O software rico em UX pode ser difícil de modularizar devido ao uso intenso de roteamento de eventos entre módulos.
   • O mantenedor de um projeto pode querer manter o projeto simples, evitando a modularização.
3. Filial de recursos . Cada desenvolvedor pode bifurcar o projeto, trabalhar em seu recurso de estimação favorito e solicitar mesclagem quando a implementação for concluída. O desenvolvedor líder pode ter a palavra final sobre a aceitação da mescla.

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

Por que a governança é importante? Imagine um dia um ex-colega de equipe pegou um pedaço do software e processou a equipe por infração. Ou a equipe processada por trolls de patentes. Ou ninguém sabe quem decidiu enviar avisos de 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 uma nova licença pública seja solicitada, como obter o consentimento de cada colaborador
• Quem pode ter acesso administrativo ao projeto
• Quem será designado para responder a solicitações legais (como avisos do DMCA ou trolls de patentes)
• Quem administrará o financiamento do projeto (pagando as despesas do servidor e contabilizando a receita ou as doações do anúncio)
• 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 controle 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 deixar o projeto . Pode não funcionar para você, mas o problema é fundamentalmente que pessoas diferentes pensam de maneiras diferentes. Recursos que você acha que são muito importantes não são importantes para outras pessoas.

Um bom plano seria dividir tarefas de pessoas diferentes. Se você puder concordar com as pessoas que parte do projeto é de responsabilidade de cada pessoa, então apenas uma pessoa está tomando decisões sobre 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 é o suficiente.

O objetivo comum concentrará seus esforços nas coisas importantes. Todo mundo trabalhando na mesma direção é difícil de obter, e os conflitos acontecerão de qualquer maneira. A definição de um objetivo comum exige saber qual é o status atual do projeto e, depois, decidir onde ele precisa estar depois de algum tempo.

Aqui está um exemplo de coisas para evitar: Por exemplo, um grande número de programadores em C ++ acha que o código que não está usando a biblioteca STL está quebrado. Outros programadores acham que toda dependência de bibliotecas externas é quebrada, incluindo o STL. Tais conflitos simplesmente não podem ser resolvidos adequadamente - ambas as situações não podem ser cumpridas simultaneamente - e as pessoas mais problemáticas irão empurrar suas opiniões, não importando que oposição eles encontrem.

Quatro escolhas, eu acho.

1. Expulse-o. Você (supostamente) ainda é o cara principal neste projeto; revogar seus privilégios push e chamá-lo um dia. O resultado mais provável é que ele bifurque o projeto, dividindo sua comunidade, e então uma guerra se desfaz, e quando a poeira baixar, um dos garfos será o popular.
2. Bifurcação e continue em outro lugar. Menos agressivo que 1., mas as conseqüências são as mesmas. Você terá que ser ativo na comunidade para atrair as pessoas para o seu lado.
3. Deixe: deixe-o fazer o que ele está fazendo, acalme-se e espere pelo melhor.
4. Discuta com a comunidade, comprometa-se conforme necessário e resolva a situação.

Pessoalmente, prefiro a opção 4.

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

1. Compreender : Entenda a motivação de sua comunidade para trabalhar em seu projeto em comparação com todos os outros custos de oportunidade e preserve essas razões.
2. Fortify : Construa uma comunidade saudável com normas sociais de polidez, respeito, confiança e humildade.
3. Identifique : Procure por sinais de pessoas venenosas (muitos para listar, mas se você estiver fazendo essa pergunta, provavelmente já conhece muitas delas).
4. Desinfectar : Mantenha a calma e mantenha-se firme, permaneça não reactivo a insultos, insultos, desrespeito, desrespeito, etc. e persistente no reforço das normas da sua comunidade.

Um esboço escrito abrangente também está disponível 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 isso pode ser difícil. Se você e os membros de sua equipe forem jovens o bastante para não experimentar em primeira mão muitos problemas sociais que acontecem em qualquer equipe de desenvolvimento, isso 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 aos seus amigos de confiança que não fazem parte da equipe e não têm nenhum ou pouco interesse no que você faz. Nesse caso, você pode obter um bom feedback para que a redação do seu e-mail não seja muito severa. Fique com os fatos embora. Não acuse ou culpe. Apenas fatos que é difícil fazer algo para você porque 'blah' está faltando. Por que 'blah' está faltando deve estar claro para todos os membros da equipe, ou seja, "o novo programador" excluiu ou não realizou algo.

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

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