Existen muchos tutoriales sobre este tema, pero hacen las cosas demasiado complicadas al asumir que uno tiene que contribuir con código a un proyecto.

¿Y si solo necesitan editar un archivo, tal vez el README de un proyecto para arreglar una errata?

No necesitas saber cómo programar o cómo usar Git para hacerlo. Pero una vez que empieces a hacer Pull Requests, podrás hacer muchas más cosas y colaborar en proyectos con otras personas. Y tal vez esto te empuje a contribuir también con código más adelante.

Supongo que ya tienes una cuenta de GitHub (gratuita). Si no la tienes, entonces ve a github.com y consigue una.

Déjame mostrarte el proceso.

Fui a esta página https://web.dev/prefers-color-scheme/ y encontré una posible errata. A esta línea le falta un punto al final.

article-i-want-to-edit
No soy muy riguroso con la gramática, esto es sólo para encontrar un ejemplo...

Sé que ese sitio está alojado en GitHub, y que el artículo exacto está alojado aquí: https://github.com/GoogleChrome/web.dev/tree/master/src/site/content/en/blog/prefers-color-scheme

github-folder-for-article

Abro el archivo index.md https://github.com/GoogleChrome/web.dev/blob/master/src/site/content/en/blog/prefers-color-scheme/index.md directamente en GitHub y presiono el icono del lápiz en la barra de herramientas del archivo. Al pasar el ratón por encima de él dice: "Fork this project and edit the file".

the-index-md-file

Esto trae una vista de editor con esta información:

Estás editando un archivo en un proyecto al que no tienes acceso de escritura. Enviando un cambio a este archivo lo escribirá a una nueva rama en su fork flaviocopes/wev.dev, para que puedas enviar un pull request.
the-editor-view

Puedo ir y agregar ese punto, luego en el formulario de abajo explico los cambios que hice:

propose-file-change

Presioné el botón "Propose File Change" y apareció una vista comparativa.

compare-view

Allí puedo revisar los cambios que hice, para asegurarme de que todo está bien, y finalmente puedo hacer clic en el botón "Create Pull Request". Actualmente los cambios se han hecho en el fork del proyecto, que fue hecho automáticamente por GitHub cuando hiciste clic en el icono del lápiz.

open-pull-request

En la parte superior de esta vista pueden ver que estoy a punto de enviar un PR (Pull Request) al proyecto GoogleChrome/web.dev desde mi formulario flaviocopes/web.dev, desde mi rama patch-2 a su rama master.

Al pulsar el botón "Create Pull Request" se muestra otro formulario donde puedo escribir una descripción detallada del Pull Request.

Los Pull Requests puede contener muchos cambios diferentes, así que en teoría podrías tener muchos archivos editados en el mismo PR, por eso puedes agregar un resumen.

Este repositorio tiene una plantilla para el texto del PR, para ayudar al equipo a manejarlo. Nuestro PR es muy simple, así que quito la plantilla y solo pego el contenido del mensaje de confirmación de antes.

¿Notas la pista de la derecha? Me dice que el proyecto tiene un archivo CONTRIBUTING.md, que explica cómo contribuir y las directrices. Bastante genial.

contributing

Parece que necesitamos firmar un CLA (Acuerdo de Licencia de Contribuyente) para completar nuestro PR. Ya firmé un CLA de Google en el pasado, así que este paso está claro para mí, pero puede que tengas que arreglarlo. La mayoría de los proyectos no lo necesitan realmente.

¡Hice clic en "Create pull request" y ahora se envía el PR!

pull-request-sent

Ahora depende de que los que mantienen el proyecto intervengan y lo acepten, solo tienes que esperar a que te envíen un correo electrónico diciéndote que se ha fusionado, o cualquier comentario que otras personas hayan hecho.

[... un par de horas pasaron...]

Recibí un correo electrónico de vuelta, el PR fue rechazado ¡porque ese punto este en el lugar correcto! (No sabía eso).

Pero de todos modos, aquí hay una cosa que quería añadir: no te enfades o te molestes si un PR que presentas no es aceptado. Los que mantienen el proyecto trabajan en él durante meses o años y saben mejor que tú lo que es mejor para él.

Además, especialmente con el código, los puntos de vista pueden ser muy diferentes y un PR que creas que es genial puede no ser bienvenido.

También es mejor preguntar antes de trabajar en un PR sustancial, para ver si es algo que el proyecto realmente necesita.

La corrección de bugs (errores) es un comienzo fácil.

Traducido del artículo de Flavio Copes - How to make your first Pull Request on GitHub