Tweet
Tweet

Slide 1

Slide 1 text

Gerenciando Projetos OpenSource 1

Slide 2

Slide 2 text

$ whoami • carlosbecker.dev • SRE @ TOTVSLabs 2

Slide 3

Slide 3 text

Gerenciando Projetos OpenSource 3

Slide 4

Slide 4 text

GoReleaser • ~4.7k stars • ~500 issues total • ~700 prs total • ~100 contributors • nfpm, godownloader, goreleaser-action 4

Slide 5

Slide 5 text

Agenda 1. Organizar issues 2. Padronização 3. Evitando "problemas evitáveis" 4. Lidando com breaking changes 5. Mantendo a casa limpa 5

Slide 6

Slide 6 text

1. Organizar issues • "qual versão?" • "pode rodar com --debug e compartilhar o log?" • "qual OS?" • label bug/feature/lalala 6

Slide 7

Slide 7 text

1. Organizar issues • Issue e PR templates com labels • Bots pra "auto-label" • Poucas labels 7

Slide 8

Slide 8 text

8

Slide 9

Slide 9 text

2. Padronização • commit log zoado • debates infinitos sobre: • tabs vs spaces • ; ou não ; • onde por as chaves 9

Slide 10

Slide 10 text

2. Padronização • Conventional Commits • Commit Lint Bot / Semantic Pull Requests Bot 10

Slide 11

Slide 11 text

11

Slide 12

Slide 12 text

2. Padronização • gofmt • jsonfmt • shfmt • terraform fmt • prettier • etc 12

Slide 13

Slide 13 text

2. Padronização • Enforce no build! • CONTRIBUTING.md • make fmt pra rodar local • .editorconfig 13

Slide 14

Slide 14 text

Mas... padronizar essas coisas muda o que? 14

Slide 15

Slide 15 text

Mas... como decidir as regras de formatação? 15

Slide 16

Slide 16 text

16

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

3. Evitando problemas evitáveis • golangci-lint • tflint • shellcheck • yamllint • jslint • etc 19

Slide 20

Slide 20 text

3. Evitando problemas evitáveis Mantendo deps up to date: • Renovate • Dependabot • Security Alerts 20

Slide 21

Slide 21 text

21

Slide 22

Slide 22 text

4. Lidando com breaking changes • "ué, ontem isso aqui funcionava ! " 22

Slide 23

Slide 23 text

4. Lidando com breaking changes "Rule #1 of OpenSource: No is temporary, yes is forever." — Solomon Hykes 23

Slide 24

Slide 24 text

24

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

4. Lidando com breaking changes Mas... e se acontecer? • https://goreleaser.com/deprecations • 6 meses de deprecated warning • !" 27

Slide 28

Slide 28 text

28

Slide 29

Slide 29 text

29

Slide 30

Slide 30 text

30

Slide 31

Slide 31 text

5. Mantendo a casa limpa • "quantas dessas 425234242 issues ainda fazem sentido?" • "bah, tem 32423 branches, tenho que fazer uma limpa nisso" 31

Slide 32

Slide 32 text

5. Mantendo a casa limpa • Stale bot pra fechar issues/prs abandonados • Bots pra "auto-lock" issues • "Automatically delete head branches" 32

Slide 33

Slide 33 text

33

Slide 34

Slide 34 text

Conclusão 34

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

T.Hanks! 36