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

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

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

5a90a67fa1a92e6a4b605cfd8da5e375?s=128

Lucas Mazza

October 19, 2013
Tweet

Transcript

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

  2. @lucasmazza

  3. http:/ /www.casadocodigo.com.br/products/livro-html-css

  4. None
  5. Open Source wat?

  6. None
  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

  39. None
  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

  43. None
  44. None
  45. None
  46. None
  47. None
  48. None
  49. None
  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
  57. None
  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”

  74. None
  75. Existe um zilhão de formas de participar

  76. None
  77. Não tenha medo de pedir ajuda

  78. None
  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
  84. None
  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

  111. None
  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