Contribuindo com projetos OpenSource: a teoria na prática.

Transcript

1. Contribuindo com projetos OpenSource a teoria na prática
2. @lucasmazza
3. http:/ /www.casadocodigo.com.br/products/livro-html-css
5. Open Source wat?
7. Open Source
8. Open Source Você
9. OSS Ruby Ruby on Rails jQuery Redis Git Django Bootstrap Backbone Node.JS Debian PHP Elixir MySQL Java Android AngularJS Docker MongoDB H5BP Android Play
10. Open Source não é trabalhar de graça
11. Open Source não é uma competição
12. Open Source é sobre cultura
13. Colaboração Comunicação Aprendizado
14. Desenvolvedores ajudando desenvolvedores
15. (Obrigado GitHub <3)
16. Participando dos projetos você pode aprender muito sobre o código que você usa no seu dia a dia
17. Como as coisas funcionam
18. Como as coisas funcionam Design de APIs
19. Como as coisas funcionam Design de APIs Performance
20. Como as coisas funcionam Design de APIs Performance Como fazer software melhor
21. Ler o código existente é uma bagagem incrível
22. Você pode ajudar a definir o rumo da comunidade
23. E dos projetos que são importantes para você
24. E o importante é começar a participar
25. “Dude, sucking at something is the first step towards being sorta good at something.”
26. como faz?
27. Reportando bugs
28. Reportando bugs Enviando patches
29. Reportando bugs Enviando patches Participando de discussões
30. Reportando bugs Enviando patches Participando de discussões Revisando colaborações
31. Todo mundo começa reportando bugs
32. Confira as issues existentes
33. Confira as issues existentes StackOverflow e mailing lists
34. Confira as issues existentes StackOverflow e mailing lists Explique como reproduzir o bug
35. Confira as issues existentes StackOverflow e mailing lists Explique como reproduzir o bug Stacktraces, versões e tudo mais
36. Não reporte falhas de segurança publicamente
37. security@djangoproject.com security@rubyonrails.org security@nodejs.org
38. Aprenda as regras de cada projeto
40. Contributing to Ghost 1. Reporting An Issue 2. Working on Ghost Core 3. Coding standards 4. Submitting Pull Requests 5. Grunt Toolkit 6. Troubleshooting / FAQ 7. Contributor License Agreement CONTRIBUTING.md @ TryGhost/Ghost
41. twbs/bootstrap joyent/node rails/rails jashkenas/backbone plataformatec/devise
42. Triagem de issues e test drive de correções
50. o papel de “suporte” é muito importante
51. Detalhes de configuração
52. Detalhes de configuração APIs alternativas
53. Detalhes de configuração APIs alternativas Issues duplicadas
54. Detalhes de configuração APIs alternativas Issues duplicadas Benchmarks das suas apps
55. Tente corrigir sozinho e envie um Pull Request
56. $ git clone https://github.com/voce/repo.git $ git checkout -b fix-things # hack hack hack hack hack $ rake test # Pull Request time! $ git commit $ git push origin fix-things -u
58. Busque opiniões sobre o código
59. Busque opiniões sobre o código merge / rebase / squash a vontade
60. Busque opiniões sobre o código merge / rebase / squash a vontade Tome o seu tempo para acabar
61. Busque opiniões sobre o código merge / rebase / squash a vontade Tome o seu tempo para acabar Repita tudo de novo
62. Feedback é a maior recompensa que você pode receber em um Pull Request
63. “[...] Remember that a PR is the start of a conversation, not the end of one.” CONTRIBUTING.md @ boxen/puppet-git
64. “Build First, Discuss Later” Mark McSpadden @ Your First Rails Pull Request
65. https:/ /help.github.com/articles/using-pull-requests
66. http:/ /guidelines.plataformatec.com.br/pull-requests
67. Nem tudo é sobre escrever código
68. Documentação e guias
69. Wikis
70. Typos, warnings e código obsoleto
71. rails/docrails github/developer.github.com janl/waaa
72. não se esqueça
73. Não existe contribuição “pequena demais”
75. Existe um zilhão de formas de participar
77. Não tenha medo de pedir ajuda
79. Colocando o seu código no mundo
80. “Porque eu colocaria o meu código no GitHub?”
81. Manter o seu código para o futuro
82. Manter o seu código para o futuro Receber ajuda de outros devs
83. Manter o seu código para o futuro Receber ajuda de outros devs Vale mais que o seu LinkedIn
85. 1 Escolha uma licença
86. “Choosing a n OSS license doesn’t need to be scary” http:/ /choosealicense.com
87. “Choosing a n OSS license doesn’t need to be scary” http:/ /choosealicense.com TL;DR: Apache 2.0 ou MIT
88. 2 Escreva um README
89. Readme Driven Development - @mojombo “Consider the process of writing the Readme for your project as the true act of creation.”
90. 3 Escreva o seu código
91. Dave Thomas @ elixir-lang-core “[...]In the meantime, the only truth is code.”
92. Faça ser fácil contribuir com o seu projeto
93. O que eu preciso instalar?
94. O que eu preciso instalar? Como eu testo o que eu fiz?
95. O que eu preciso instalar? Como eu testo o que eu fiz? Qual o workflow do projeto?
96. Cuide do seu README.md e CONTRIBUTING.md
97. Abuse do ferramental da comunidade
98. Automatize as partes mecânicas
99. source 'https://rubygems.org' gemspec gem 'country_select', '~> 1.1.1' gem 'railties', '>= 4.0.0', '< 4.1' gem 'activemodel', '>= 4.0.0', '< 4.1' gem 'actionpack', '>= 4.0.0', '< 4.1' gem 'rake' gem 'rdoc' gem 'tzinfo' Bundler
100. Travis CI
101. Documentação
102. Vagrant Boxes
103. WebHooks
104. Dedique um tempo para revisar as contribuições
105. E ajude os outros a melhorar o seu software
106. Retrocompatibilidade
107. Retrocompatibilidade APIS e styleguides
108. Retrocompatibilidade APIS e styleguides Promova contribuidores
109. Retrocompatibilidade APIS e styleguides Promova contribuidores Lidere por exemplo
110. Não tenha medo de começar de novo
112. “I have learned that in the open- source world, you are not your code. A critique of your project is not tantamount to a personal attack.” http:/ /sstephenson.us/posts/you-are-not-your-code
113. Open Source e código fechado
114. Open Source é baseado em:
115. Colaboração
116. Colaboração Comunicação
117. Colaboração Comunicação Aprendizado
118. Desenvolvimento de Sofware é baseado em:
119. Colaboração
120. Colaboração Comunicação
121. Colaboração Comunicação Aprendizado
122. O que funciona de um lado pode funcionar do outro
123. Descentralização
124. Descentralização Visibilidade do que é feito
125. Descentralização Visibilidade do que é feito Comunicação aberta
126. Descentralização Visibilidade do que é feito Comunicação aberta Autoria coletiva
127. “Your team should work like an open source project.” http:/ /tomayko.com/writings/adopt-an-open-source-process-constraints
128. Obrigado! https:/ /twitter.com/lucasmazza https:/ /speakerdeck.com/lucas