El secreto arte del Pull Request

Guía básica de como trabajar con git, contribuir a proyectos opensource y comportarse (?)

Transcript

1. El secreto arte de crear contribuciones Angel Velásquez @angvp
2. Acerca de mi - Arch Linux Developer. - Co organizador de Django Meetup de Buenos Aires. (sí, ya sé que hace rato que no hacemos uno, pronto vuelven) - Coach del Taller de Django Girls en PyCon Argentina 2015. - Mantenedor de la web de PyAr y de Arch Linux (ambas en Django) - Creador de varias bibliotecas sin sentido y contribuidor de varias con un poco más de sentido. (chusmeá mi github). - El del “rant pytónico” en la PyCon Argentina 2014.
3. Disclaimer - Hablo rápido, realmente rápido, y en tonada es_VE pedí pausa si es necesario. - Rogelio el pato culto es una imagen que pertenece al blog cinismoilustrado.com no se agregó ningún texto ni alguna modificación a la misma sin embargo se usó la imagen como inspiración para la charla. - A última hora le cambié el nombre a la charla en vez de “El secreto arte del Pull Request” se llama ahora “El secreto arte de crear contribuciones”
5. A qué se le dice contribuir a un proyecto - Reportar bugs. - Corregir documentación. - Contribuir código. - Hacer difusión del proyecto. - Donar plata (a lo crowdfunding, etc).
6. Cómo se contribuye en los proyectos más grandes? - Linux: https://www.kernel.org/doc/Documentation/SubmittingPatches - Python: https://docs.python.org/devguide/ - Django: https://docs.djangoproject.com/en/dev/internals/contributing/com mitting-code/ - Django Channels: https://channels.readthedocs.io/en/latest/contributing.html - Atom editor: https://github.com/atom/atom/blob/master/CONTRIBUTING.md
7. Lo que la gente hace normalmente… (se viene el rant). - Crea un PR sin un issue. - Mete una cantidad de commits innecesaria. - No responde a las preguntas y no es capaz de describir cómo reproducir un issue!, simplemente reporta “está roto” .. cómo un vil usuario!!… - Se ofenden cuando te dicen que corrijas la cosas, por qué?!!!!.
8. Lo que la gente hace normalmente… (se viene el rant). - Crea un PR sin un issue. - Mete una cantidad de commits innecesaria. - No responde a las preguntas y no es capaz de describir cómo reproducir un issue!, simplemente reporta “está roto” .. cómo un vil usuario!!… - Se ofenden cuando te dicen que corrijas la cosas, por qué?!!!!.
9. Lo que la gente hace normalmente… (se viene el rant). - Crea un PR sin un issue. - Mete una cantidad de commits innecesaria. - No responde a las preguntas y no es capaz de describir cómo reproducir un issue!, simplemente reporta “está roto” .. cómo un vil usuario!!… - Se ofenden cuando te dicen que corrijas la cosas, por qué?!!!!.
10. Reportando bugs en el siglo XXI (Lo que hay que hacer) - Está reportado este bug?, es un bug? por qué es un bug? - Reportarlo en el lugar correcto. - Traceback del bug claro. (ojo con la información sensible) - Explicar las versiones que se estaba usando de la librería, de python, sistema operativo etc, y tener en cuenta que en algunos casos se requieren cosas como variables de entorno del sistema. - Estar atento al feedback y hacer follow-up.
11. Contribuyendo código (casos más comunes) - Lee el archivo CONTRIBUTING.md (o .rst) .. si no lo tiene y no es un proyecto “grande” pinta para una primera contribución. - Flake8 (pep8, McCabe, pyflakes). - Escribiendo un BUEN mensaje de commit (next slide) - Commits atómicos, y squash de los commits en la medida de lo posible (más adelante) -
12. Contribuciones que no suman (Lo que NO hay que hacer) - https://github.com/tomchristie/django-rest- framework/pull/4613 - https://github.com/caioariede/django-locati on-field/pulls - https://github.com/django-polymorphic/djang o-polymorphic/pull/2 - Y por casa cómo estamos? https://github.com/PyAr/pyarweb/issues/243
13. Escribiendo un BUEN mensaje de commit (casi el standard por defecto) - Título del commit corto (50 caracteres) para poder leerse bien en logs, puede tener más detalle. - El mensaje debe responder a la premisa: Qué hace este commit?. - No escribir el mensaje en pasado, sino de forma imperativa ^. - Usemos la metadata, en el mensaje de commit.
14. Haciendo commits atómicos LIVE DEMO (todo puede salir mal, aunque lo haya ensayado 18 veces)
15. Qué hicimos en git? - git checkout -b - git commit --amend - git rebase -i - git merge - git push + y :
16. TL; DR kthxbye - Revisa si hay una guía de cómo contribuir y apégate a ella. - Si NO hay, ve cual es el standard, probablemente sea el descrito anteriormente. - Mensajes de commit claros y atómicos (formateados de acuerdo a lo que diga la guía, obvio). - Recuerda a Rogelio, ya no estamos en la edad media.
17. Contact o github, twitter, irc: @angvp mail: angvp@archlinux.org