Como devo contribuir para um projeto (principalmente) abandonado do GitHub?


43

Recentemente, tenho tentado entrar em colaboração de código aberto no GitHub e me deparei com uma situação na qual estou curioso para saber qual é a maneira preferida de proceder.

Há cerca de um mês, encontrei um projeto no GitHub para uma biblioteca que já usava há algum tempo e na qual encontrei (e consertei) alguns bugs.

Como uma incursão inicial na colaboração do GitHub, encontrei o repositório que parecia ter o maior volume de atividades recentes, corrigi um bug, adicionei testes de unidade, subi ao GitHub e fiz uma solicitação de recebimento. Dentro de algumas horas, o mantenedor do repositório que eu peguei havia aceitado o PR e fundido em alguns outros PRs de outras pessoas que estavam esperando também.

Impulsionado por isso, corrigi mais três erros que encontrei, cada um em uma ramificação separada de meu próprio repositório, e arquivei um problema e solicitei cada um separadamente.

Isso foi há pouco mais de um mês, e os pedidos de recebimento estão intactos desde então. O usuário cujo repo bifurquei não parece muito ativo, tendo apenas 7 contribuições totais no GitHub no ano passado, e esse repo não teve nenhum commit desde a primeira solicitação pull que fiz.

Então, minha pergunta:

Como se proceder nessa situação? Idealmente, eu gostaria de evitar a fragmentação da biblioteca, realizando várias alterações em meu próprio repositório que não são mescladas no repositório pai. No entanto, gostaria de continuar fazendo correções de bugs e adicionando recursos, mas se mesclar tudo no meu ramo principal e basear todas as novas correções nesse ramo, se o mantenedor do repo que formei voltar, ganhei não é possível dividir todas as alterações em solicitações pull separadas para cada recurso / correção de bug (eu li que solicitações pull geralmente devem ser uma solicitação pull por recurso ou correção de bug).

Devo manter um ramo que esteja de acordo com o repositório original, basear todos os meus novos ramos fora desse e manter todos os commits mesclados em meu ramo mestre? Parece que isso me deixaria com uma tonelada de galhos e uma tarefa cada vez mais onerosa toda vez que eu precisar mesclar novas mudanças no meu ramo principal.

Qual é o modo típico de abordar uma situação como essa? Parece ser bastante comum que um projeto seja abandonado com os colaboradores originais que não estão por perto para revisar novas solicitações de recebimento. É uma situação em que alguém deveria simplesmente assumir o comando e correr com ele? Parece que isso criaria fragmentação se os colaboradores originais voltarem e quiserem trabalhar no projeto novamente.


4
Quando você achar essa pergunta interessante, também poderá estar interessado na proposta de um novo site de troca de pilha de código aberto .
Philipp

Gostaria de compartilhar o que saiu da conversa por e-mail apenas para nós, curiosos? :)
winkbrace 20/02

@winkbrace Até agora, nada. Não recebi uma resposta, mas enviei o e-mail apenas dois dias atrás. Avisarei a todos se algo se desenvolver.
JLRishe

Respostas:


39

Ainda não tive essa situação, mas é o que tentaria:

Tente entrar em contato com o proprietário

Talvez eles realmente tenham perdido o interesse, mas estejam dispostos a transferir o projeto para outra pessoa, em particular alguém que já demonstrou um compromisso considerável.

Mas talvez eles estejam apenas ocupados com outra coisa (trabalho, férias, doença, outros projetos) e não tenham tempo para lidar com o seu PR, mas planejam fazê-lo mais tarde.

Ou talvez eles realmente pararam de trabalhar permanentemente no projeto por qualquer motivo.

Sem perguntar, você não descobrirá.

Entre em contato com a comunidade

Certamente há outras pessoas que contribuíram ou pelo menos usaram o projeto. Verifique quem bifurcou o projeto (mesmo que não tenha feito nenhuma alteração, eles ainda podem estar interessados ​​em ver esse projeto prosperar); verifique quem relatou problemas ou comentou sobre eles. Talvez haja também uma comunidade fora do GitHub, por exemplo, uma lista de discussão, fórum ou membros do StackOverflow.

Sou você eventualmente assume o projeto, pode querer o apoio deles. E eles precisam saber onde está o novo repositório principal.

Continue fazendo boas solicitações de recebimento

Isso mostra ao proprietário e à comunidade que você está falando sério e vamos julgar suas contribuições.


1
Obrigado. Após um pouco mais de pesquisa, parece que esse conselho é semelhante às diretrizes disponíveis para esse tipo de situação com os pacotes npm . Acabei de enviar um e-mail ao proprietário e vou ver o que ele / ela responde.
JLRishe

É muito difícil encontrar alguém com a capacidade de aprovar PRs para um repositório específico quando o "proprietário" do repositório é na verdade uma organização com dezenas de usuários.
cowlinator

15

Se o proprietário do repositório original não for encontrado em nenhum lugar e ausente por um período considerável, eu publicaria meu próprio repositório como uma versão diferente do projeto.

Com isso, você assume a liderança do desenvolvimento da biblioteca e não a deixa morrer em um canto sem ser atualizada novamente. Se o proprietário original fechar o repositório, o mundo ainda poderá usar a versão bifurcada.


1
Sim, simplesmente forko projeto e no README.md, deixe uma referência e "obrigado" ao proprietário original.
Jared Burrows

Obrigado pela sua resposta (+1). Você definitivamente faz alguns bons pontos. Por fim, posso recorrer a isso, mas, por enquanto, seguirei os conselhos da oefe e verificarei se consigo entrar em contato com o proprietário do repo por e-mail.
JLRishe

Obviamente, não deixe o repositório cair no esquecimento. Muitos códigos bons devem estar ocultos em algum lugar no Github, pois os proprietários originais não existem mais.
cllamach

Estou em uma situação semelhante e talvez seja necessário usar essa opção - o proprietário original de um projeto não respondeu a tentativas repetidas de contato. É kosher manter o nome do projeto e continuar incrementando o número da versão da última versão oficial? Preocupa-me que, se eu mudar o nome, será mais difícil encontrar os usuários existentes do projeto.
pericynthion

1
Eu também posso estar nessa situação. Mas o projeto original já está registrado no Bower. Manter o nome significaria ter que pedir ao autor original para cancelar o registro para você, ou entrar em contato com os mantenedores da Bower e pedir que eles intervissem. Eu não me importo muito em fazer o último, no entanto. Renomear pode ser a melhor opção.
Lawrence I. Siden

0

Como a maioria dos projetos gratuitos e de código aberto de pequeno a médio porte atualmente são hospedados no github, gitlab ou similar, seria possível automatizar parte do processo , usando suas APIs da Web.

Supondo que o repo original esteja em https://github.com/someUserX/projectY/, o processo pode ser assim:

  1. ("manual") Entre em contato com o autor original de maneiras diferentes, pelo menos através do e-mail do git committer e de um problema (se ativado).

    No caso de uma permissão recebida ou nenhuma resposta dentro de algumas semanas, é possível executar um script que usaria a API da Web hosters para executar etapas como estas:

  2. crie uma nova organização (GitHub) chamada projectY, e bifurque o repositório original ->https://github.com/projectY/projectY/

  3. adicione o autor original e todos os autores de solicitações pull (já mescladas e ainda abertas) como administradores da organização
  4. recrie todas as solicitações pull (abertas) do repositório original no novo fork
  5. faça o mesmo com os problemas (abertos)
  6. notifica todos os administradores do novo repositório
  7. crie uma última solicitação de recebimento no repositório antigo, adicionando um aviso "abandonado" / "arquivado" e vincule-o ao novo repositório na parte superior do README

O principal problema que vejo com essa abordagem é que alguns colaboradores "ruins" podem ter acesso de administrador, mas, como explica o evangelista do Software Livre Pieter Hintjens (por exemplo, nesta palestra) , os commits ruins podem ser simplesmente revertidos e não representam nenhum problema. um projeto que está vivo e pode ajudar o mau colaborador a se tornar um bom projeto ao longo do tempo.
hoijui 16/06
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.