Gerenciando Projetos OpenSource

Dicas pra gerenciar projetos OpenSource.

1. Gerenciando Projetos OpenSource 1
2. $ whoami • carlosbecker.dev • SRE @ TOTVSLabs 2
3. Gerenciando Projetos OpenSource 3
4. GoReleaser • ~4.7k stars • ~500 issues total • ~700 prs total • ~100 contributors • nfpm, godownloader, goreleaser-action 4
5. Agenda 1. Organizar issues 2. Padronização 3. Evitando "problemas evitáveis" 4. Lidando com breaking changes 5. Mantendo a casa limpa 5
6. 1. Organizar issues • "qual versão?" • "pode rodar com --debug e compartilhar o log?" • "qual OS?" • label bug/feature/lalala 6
7. 1. Organizar issues • Issue e PR templates com labels • Bots pra "auto-label" • Poucas labels 7
9. 2. Padronização • commit log zoado • debates infinitos sobre: • tabs vs spaces • ; ou não ; • onde por as chaves 9
10. 2. Padronização • Conventional Commits • Commit Lint Bot / Semantic Pull Requests Bot 10
12. 2. Padronização • gofmt • jsonfmt • shfmt • terraform fmt • prettier • etc 12
13. 2. Padronização • Enforce no build! • CONTRIBUTING.md • make fmt pra rodar local • .editorconfig 13
14. Mas... padronizar essas coisas muda o que? 14
15. Mas... como decidir as regras de formatação? 15
17. 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
18. 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
19. 3. Evitando problemas evitáveis • golangci-lint • tflint • shellcheck • yamllint • jslint • etc 19
20. 3. Evitando problemas evitáveis Mantendo deps up to date: • Renovate • Dependabot • Security Alerts 20
22. 4. Lidando com breaking changes • "ué, ontem isso aqui funcionava ! " 22
23. 4. Lidando com breaking changes "Rule #1 of OpenSource: No is temporary, yes is forever." — Solomon Hykes 23
25. 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
26. 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
27. 4. Lidando com breaking changes Mas... e se acontecer? • https://goreleaser.com/deprecations • 6 meses de deprecated warning • !" 27
31. 5. Mantendo a casa limpa • "quantas dessas 425234242 issues ainda fazem sentido?" • "bah, tem 32423 branches, tenho que fazer uma limpa nisso" 31
32. 5. Mantendo a casa limpa • Stale bot pra fechar issues/prs abandonados • Bots pra "auto-lock" issues • "Automatically delete head branches" 32
34. Conclusão 34
35. 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
36. T.Hanks! 36