Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Gerenciando Projetos OpenSource

Gerenciando Projetos OpenSource

Dicas pra gerenciar projetos OpenSource.

Carlos Alexandro Becker

October 08, 2019
Tweet

More Decks by Carlos Alexandro Becker

Other Decks in Technology

Transcript

  1. GoReleaser • ~4.7k stars • ~500 issues total • ~700

    prs total • ~100 contributors • nfpm, godownloader, goreleaser-action 4
  2. Agenda 1. Organizar issues 2. Padronização 3. Evitando "problemas evitáveis"

    4. Lidando com breaking changes 5. Mantendo a casa limpa 5
  3. 1. Organizar issues • "qual versão?" • "pode rodar com

    --debug e compartilhar o log?" • "qual OS?" • label bug/feature/lalala 6
  4. 1. Organizar issues • Issue e PR templates com labels

    • Bots pra "auto-label" • Poucas labels 7
  5. 8

  6. 2. Padronização • commit log zoado • debates infinitos sobre:

    • tabs vs spaces • ; ou não ; • onde por as chaves 9
  7. 11

  8. 16

  9. 3. Evitando problemas evitáveis • "esqueci do .Close()" • "putz

    eu já tinha arrumado esse bug" • "ih mano esqueci de tratar o erro que retorna na função ali" • "nao sei pq meu script não funciona direito no linux" • "ah tem que atualizar a batatalib pra v2.5.6" 17
  10. 3. Evitando problemas evitáveis • escreva testes!!!!!!!!!! • meça a

    cobertura e reporte no pull request • coveralls • codecov • evite mergear coisas que pioram a cobertura de testes 18
  11. 3. Evitando problemas evitáveis Mantendo deps up to date: •

    Renovate • Dependabot • Security Alerts 20
  12. 21

  13. 4. Lidando com breaking changes "Rule #1 of OpenSource: No

    is temporary, yes is forever." — Solomon Hykes 23
  14. 24

  15. 4. Lidando com breaking changes Como um mantenedor, antes de

    mergear algo: • Eu tenho 100% de certeza que X faz sentido? • Eu tenho 100% de certeza que esse é o melhor jeito de fazer X? 25
  16. 4. Lidando com breaking changes Como um contribuidor, querendo contribuir

    com algo: • Abrir uma issue pra discutir a feature antes de implementar • Não levar para o lado pessoal • Se tudo der errado, mantenho meu fork 26
  17. 4. Lidando com breaking changes Mas... e se acontecer? •

    https://goreleaser.com/deprecations • 6 meses de deprecated warning • !" 27
  18. 28

  19. 29

  20. 30

  21. 5. Mantendo a casa limpa • "quantas dessas 425234242 issues

    ainda fazem sentido?" • "bah, tem 32423 branches, tenho que fazer uma limpa nisso" 31
  22. 5. Mantendo a casa limpa • Stale bot pra fechar

    issues/prs abandonados • Bots pra "auto-lock" issues • "Automatically delete head branches" 32
  23. 33

  24. Conclusão • Simplicidade nos labels • Issue/PR templates • Definir

    padrões o mais cedo possivel, documentar e enforçar no build ou com bots • Escrever testes e medir cobertura • Não se sentir obrigado a dizer sim • Não ter medo de fechar issue parada 35