Review on '06-github' sections finished

book/06-github/sections/1-setting-up-account.asc

@@ -11,15 +11,15 @@ image::images/signup.png[Formulario para darse de alta en GitHub.]
 
 Lo siguiente que verás es la página de precios para planes mejores, pero lo
 puedes ignorar por el momento. GitHub te enviará un correo para verificar la
-dirección que les has dado. Confirma la dirección ahora, es bastante importante
+dirección que les has dado. Confirmar la dirección ahora, es bastante importante
 (como veremos después).
 
 [NOTE]
 ====
 GitHub proporciona toda su funcionalidad en cuentas gratuitas, con la
 limitación de que todos tus proyectos serán públicos (todos los usuarios
 tendrán acceso de lectura).
-Los planes de pago de GitHub te permite tener algunos proyectos privados,
+Los planes de pago de GitHub te permiten tener algunos proyectos privados,
 pero esto es algo que no veremos en este libro.
 ====
 
@@ -34,11 +34,11 @@ Desde ya, puedes acceder a los repositorios Git utilizando el protocolo
 `https://`, identificándote con el usuario y la contraseña que acabas de
 elegir.
 Sin embargo, para simplificar el clonado de proyectos públicos, no
-necesitas crearte la cuenta. Es decir, la cuenta solo la necesitas cuando
+necesitas crearte la cuenta. Es decir, la cuenta sólo la necesitas cuando
 comienzas a hacer cosas como bifurcar (fork) proyectos y enviar tus propios
 cambios más tarde.
 
-Si prefieres usar SSH, necesitas configurar una clave pública. Si aun no
+Si prefieres usar SSH, necesitas configurar una clave pública. Si aún no
 la tienes, mira cómo generarla en <<ch04-git-server#r_generate_ssh_key>>.)
 Abre tu panel de control de la cuenta utilizando el enlace de la parte
 superior derecha de la ventana:
@@ -57,10 +57,10 @@ clave pública) en el área de texto, y pulsa sobre ``Add key''.
 
 [NOTE]
 ====
-Asegúrate darle a tu clave un nombre que puedas recordar. Puedes, por ejemplo,
+Asegúrate de darle a tu clave un nombre que puedas recordar. Puedes, por ejemplo,
 añadir claves diferentes, con nombres como "Clave Portátil" o "Cuenta de
-trabajo" de modo que si tienes que revocar alguna clave más tarde, te resultará
-más fácil decidir cuál es.
+trabajo", de modo que si tienes que revocar alguna clave más tarde, te resultará
+más fácil saber cuál es.
 ====
 
 [[r_personal_avatar]]
@@ -75,24 +75,24 @@ ti con una imagen de tu elección. En primer lugar selecciona la opción
 image::images/your-profile.png[Enlace ``Profile''.]
 
 Nosotros eligiremos como ejemplo una copia del logo de Git que tengamos en
-el disco duro y luego tendremos opción de recortarlo al subirlo.
+el disco duro y luego tendremos la opción de recortarlo al subirlo.
 
 .Recortar tu icono
 image::images/avatar-crop.png[Recortar tu icono.]
 
-Desde ahora, quien vea tu perfil o tus contribuciones a repositorios verá
+Desde ahora, quien vea tu perfil o tus contribuciones a repositorios, verá
 tu nuevo icono junto a tu nombre.
 
 Si da la casualidad que ya tienes tu icono en el popular servicio Gravatar
 (conocido por su uso en las cuentas de Wordpress), este icono será detectado
-y no tendrás que hacer, si quieres, este paso.
+y no tendrás que hacer este paso, si no lo deseas.
 
 ==== Tus direcciones de correo
 
 La forma con la que GitHub identifica tus contribuciones a Git es mediante
 la dirección de correo electrónico. Si tienes varias direcciones diferentes
 en tus contribuciones (commits) y quieres que GitHub sepa que son de tu
-cuenta, necesitas añadirlas todas en la sección Emails de la sección
+cuenta, necesitas añadirlas todas en el apartado Emails de la sección
 de administración.
 
 [[r_add_email_addresses]]
@@ -112,7 +112,7 @@ con esa dirección, la identificará asociándola a tu usuario.
 Finalmente, y para mayor seguridad, deberías configurar la Autentificación
 de Dos Pasos o ``2FA''. Este tipo de autentificación se está haciendo más
 popular para reducir el riesgo de que te roben la cuenta. Al activarla,
-GitHub te pedirá identificarte de dos formas, de forma que si una de ellas
+GitHub te pedirá identificarte de dos formas, de manera que si una de ellas
 resulta comprometida, el atacante no conseguirá acceso a tu cuenta.
 
 Puedes encontrar la configuración de ``2FA'' en la opción Security de los

book/06-github/sections/2-contributing.asc

@@ -9,23 +9,23 @@ para ayudarte a participar en proyectos existentes.
 Si quieres participar en un proyecto existente, en el que no tengas permisos
 de escritura, puedes bifurcarlo (hacer un ``fork''). Esto consiste en
 crear una copia completa del repositorio totalmente bajo tu control:
-se encontrará en tu cuenta y podrás escribir en él sin limitaciones.
+se almacenará en tu cuenta y podrás escribir en él sin limitaciones.
 
 [NOTE]
 ====
 Históricamente, el término ``fork'' podía tener connotaciones algo negativas, ya
 que significaba que alguien realizaba una copia del código fuente del proyecto
-y las comenzaba a modificar de forma independiente al proyecto original,
-tal vez para crear un proyecto competidor y dividir a su comunidad de
+y las comenzaba a modificar de forma independiente al proyecto original.
+Tal vez, para crear un proyecto competidor y dividir a su comunidad de
 colaboradores. En GitHub, el ``fork'' es simplemente una copia del repositorio
-donde puedas escribir, haciendo públicos tus propios cambios, como una manera
+donde puedes escribir, haciendo públicos tus propios cambios, como una manera
 abierta de participación.
 ====
 
 De esta forma, los proyectos no necesitan añadir colaboradores con acceso de
 escritura (push). La gente puede bifurcar un proyecto, enviar sus propios
 cambios a su copia y luego remitir esos cambios al repositorio original para
-su aprobación, creando lo que se llama un Pull Request, que veremos más
+su aprobación; creando lo que se llama un Pull Request, que veremos más
 adelante.
 Esto permite abrir una discusión para la revisión del código, donde propietario
 y participante pueden comunicarse acerca de los cambios y, en última instancia,
@@ -49,7 +49,7 @@ cuenta y con tu propia copia del código fuente.
 GitHub está diseñado alrededor de un flujo de trabajo de colaboración
 específico, centrado en las solicitudes de integración (``pull request'').
 Este flujo es válido tanto si colaboras con un pequeño equipo en un
-repositorio compartido como si lo haces en una gran red de participantes con
+repositorio compartido, como si lo haces en una gran red de participantes con
 docenas de bifurcaciones particulares.
 Se centra en el workflow <<ch03-git-branching#r_topic_branch>> cubierto en <<ch03-git-branching#ch03-git-branching>>.
 
@@ -65,8 +65,7 @@ commits.
 la rama con tus cambios o bien rechazándolos.
 
 Este es, básicamente, el flujo de trabajo del Responsable de Integración visto
-en <<ch05-distributed-git#r_integration_manager>>, pero en lugar de usar el correo para comunicarnos
-y revisar los cambios, lo que se hace es usar las herramientas web de GitHub.
+en <<ch05-distributed-git#r_integration_manager>>, pero en lugar de usar el correo para comunicarnos y revisar los cambios, lo que se hace es usar las herramientas web de GitHub.
 
 Veamos un ejemplo de cómo proponer un cambio en un proyecto de código abierto
 hospedado en GitHub, utilizando esta forma de trabajar.
@@ -159,7 +158,7 @@ hacer una buena descripción para que el autor sepa realmente qué estamos
 aportando y lo valore adecuadamente.
 
 También veremos la lista de commits de la rama que están ``por delante'' de la
-rama `master` (en este caso, la única) y un diff unificado de los cambios que
+rama `master` (en este caso, la única) y un ``diff unificado'' de los cambios que
 se aplicarían si se fusionasen con el proyecto original.
 
 .Página de creación del Pull Request
@@ -171,7 +170,7 @@ junto a un enlace donde está toda la información.
 
 [NOTE]
 ====
-Aunque los Pull Request se utilizan en proyectos públicos como este donde el
+Aunque los Pull Request se utilizan en proyectos públicos como este, donde el
 ayudante tiene un conjunto de cambios completos para enviar, también se utiliza
 en proyectos internos al principio del ciclo de desarrollo: puedes crear el
 Pull Request con una rama propia y seguir enviando commits a dicha rama después
@@ -187,8 +186,8 @@ la idea pero prefiere esperar un poco.
 
 La discusión, en los workflow de <<ch05-distributed-git#ch05-distributed-git>>, tiene lugar por
 correo electrónico, mientras que en GitHub tiene lugar en línea. El propietario
-del proyecto puede revisar el diff y dejar un comentario pulsando en
-cualquier línea del diff.
+del proyecto puede revisar el ``diff'' y dejar un comentario pulsando en
+cualquier línea del ``diff''.
 
 .Comentando una línea concreta del diff
 image::images/blink-04-pr-comment.png[Comentario de línea del PR]
@@ -213,15 +212,15 @@ conversación.
 .Página de discusión del Pull Request
 image::images/blink-05-general-comment.png[Página de discusión del PR]
 
-El participante puede ver ahora qué tiene que hacer para ver aceptado su
-cambio. Con suerte sera poco trabajo. Mientras que con el correo electrónico
+El participante puede ver ahora qué tiene que hacer para que sea aceptado su
+cambio. Con suerte será poco trabajo. Mientras que con el correo electrónico
 tendrías que revisar los cambios y reenviarlos a la lista de correo, en
 GitHub puedes, simplemente, enviar un nuevo commit a la rama y subirla (push).
 
 Si el participante hace esto, el coordinador del proyecto será notificado
 nuevamente y, cuando visiten la página, verán lo que ha cambiado. De hecho,
 al ver que un cambio en una línea de código tenía ya un comentario, GitHub
-se da cuenta y oculta el diff obsoleto.
+se da cuenta y oculta el ``diff'' obsoleto.
 
 [[r_pr_final]]
 .Pull Request final
@@ -230,9 +229,9 @@ image::images/blink-06-final.png[PR final]
 Es interesante notar que si pulsas en ``Files Changed'' dentro del Pull
 Request, verás el ``diff unificado'', es decir, los cambios que se
 introducirían en la rama principal si la otra rama fuera fusionada. En
-términos de git, lo que hace es mostrarte la salida del comando
+términos de Git, lo que hace es mostrarte la salida del comando
 `git diff master ... <rama>`. Mira en <<ch05-distributed-git#r_what_is_introduced>> para saber
-más sobre este tipo de diff.
+más sobre este tipo de ``diff''.
 
 Otra cosa interesante es que GitHub también comprueba si el Pull Request
 se fusionaría limpiamente (de forma automática) dando entonces un botón
@@ -256,7 +255,7 @@ finalmente la petición es cerrada (rechazada) o fusionada.
 Observa que también puedes abrir un Pull Request entre dos ramas del mismo
 repositorio. Si estás trabajando en una característica con alguien y ambos
 tenéis acceso de escritura al repositorio, puedes subir una rama al mismo
-y abrir un Pull Request con ella de fusión con `master` para poder formalizar
+y abrir un Pull Request de fusión con `master` para poder formalizar
 el proceso de revisión de código y discusión. Para esto no se requieren
 bifurcaciones (forks).
 ====
@@ -274,7 +273,7 @@ Requests sean colas de parches perfectos que se pueden aplicar limpiamente
 en orden, como sucede con los proyectos basados en listas de correo. Casi todos
 los proyectos de GitHub consideran las ramas de Pull Requests como
 conversaciones evolutivas acerca de un cambio propuesto, culminando en un
-diff unificado que se aplica fusionando.
+``diff'' unificado que se aplica fusionando.
 
 Esto es importante, ya que normalmente el cambio se sugiere bastante antes
 de que el código sea suficientemente bueno, lo que lo aleja bastante del modelo
@@ -287,7 +286,7 @@ commit en la rama para enviar la diferencia que materializa esas sugerencias,
 haciendo avanzar la conversación con el contexto del trabajo previo intacto.
 
 Por ejemplo, si miras de nuevo en <<r_pr_final>>, verás que el colaborador
-no reorganiza su commit y envía un nuevo Pull Request. En lugar, lo que hace es
+no reorganiza su commit y envía un nuevo Pull Request. En su lugar, lo que hace es
 añadir nuevos commits y los envía a la misma rama. De este modo, si vuelves
 a mirar el Pull Request en el futuro, puedes encontrar fácilmente todo el
 contexto con todas las decisiones tomadas. Al pulsar el botón ``Merge'',
@@ -296,7 +295,7 @@ fácil localizar para revisar la conversación original, si es necesario.
 
 ===== Manteniéndonos actualizados
 
-Si el Pull Request se queda anticuado o por cualquier otra razón no puede
+Si el Pull Request se queda anticuado, o por cualquier otra razón no puede
 fusionarse limpiamente, lo normal es corregirlo para que el responsable pueda
 fusionarlo fácilmente. GitHub comprobará esto y te dirá si cada Pull Request
 tiene una fusión trivial posible o no.
@@ -314,11 +313,11 @@ la rama con el contenido de la rama `master` (normalmente esta es la rama desde
 donde se hizo la bifurcación), o bien puedes fusionar la rama objetivo en
 la tuya.
 
-Muchos desarrolladores eligen la segunda opción, por las mismas razones que
+Muchos desarrolladores eligen la segunda opción, por las mismas razones
 que dijimos en la sección anterior. Lo que importa aquí es la historia y la
 fusión final, por lo que reorganizar no es mucho más que tener una
-historia más limpia y, sin embargo, es de lejos más complicado de hacer y
-con más posibilidad de error.
+historia más limpia y, sin embargo, es por lejos más complicado de hacer y
+con mayores posibilidades de error.
 
 Si quieres fusionar en la rama objetivo para hacer que tu Pull Request sea
 fusionable, deberías añadir el repositorio original como un nuevo remoto,
@@ -328,7 +327,7 @@ solicitud de integración.
 
 Por ejemplo, supongamos que en el ejemplo ``tonychacon'' que hemos venido
 usando, el autor original hace un cambio que crea un conflicto con el Pull
-Request. Seguiremos entonces los siguientes pasos.
+Request. Seguiremos entonces los siguientes pasos:
 
 [source,console]
 ----
@@ -378,7 +377,7 @@ image::images/pr-02-merge-fix.png[PR corregido]
 
 Una de las cosas interesantes de Git es que puedes hacer esto continuamente.
 Si tienes un proyecto con mucha historia, puedes fácilmente fusionarte la
-rama objetivo (`master`) una y otra vez cada vez que sea necesario, evitando
+rama objetivo (`master`) cada vez que sea necesario, evitando
 conflictos y haciendo que el proceso de integración de tus cambios sea muy
 manejable.
 
@@ -387,7 +386,7 @@ hacerlo, pero se recomienda no forzar el push sobre la rama del Pull Request.
 Si otras personas se la han bajado y hacen más trabajo en ella, provocarás
 los problemas vistos en <<ch03-git-branching#r_rebase_peril>>. En su lugar, envía la rama
 reorganizada a una nueva rama de GitHub y abre con ella un nuevo Pull Request,
-con referencia al antiguo, cerrando además éste.
+con referencia al antiguo, cerrando además éste último.
 
 ===== Referencias
 
@@ -407,7 +406,7 @@ una bifurcación que haya creado ese usuario, o incluso puede usarse la forma
 repositorio diferente.
 
 Veamos un ejemplo. Supongamos que hemos reorganizado la rama del ejemplo
-anterior, creado un nuevo pull request para ella y ahora queremos hacer una
+anterior, creado un nuevo Pull Request para ella y ahora queremos hacer una
 referencia al viejo Pull Request desde el nuevo. También queremos hacer
 referencia a una incidencia en la bifurcación del repositorio, y una
 incidencia de un proyecto totalmente distinto. Podemos rellenar la descripción
@@ -417,7 +416,7 @@ justo como vemos en <<r_pr_references>>.
 .Referencias cruzadas en un Pull Request.
 image::images/mentions-01-syntax.png[Referencias a PR]
 
-Cuando enviamos este pull request, veremos todo como en
+Cuando enviamos este Pull Pequest, veremos todo como en
 <<r_pr_references_render>>.
 
 [[r_pr_references_render]]
@@ -429,7 +428,7 @@ a la información que necesitamos realmente.
 
 Ahora, si Tony regresa y cierra el Pull Request original, veremos que
 GitHub crea un evento en la línea de tiempo del Pull Request. Esto significa
-que cualquier que visite este Pull Request y vea que está cerrado, puede
+que cualquiera que visite este Pull Request y vea que está cerrado, puede
 fácilmente enlazarlo al que lo hizo obsoleto. El enlace se mostrará tal
 como en <<r_pr_closed>>.
 
@@ -438,18 +437,18 @@ como en <<r_pr_closed>>.
 image::images/mentions-03-closed.png[PR cerrado]
 
 Además de los números de incidencia, también puedes hacer referencia a un
-commit específico usando la firma SHA-1. Puedes utilizar la cadena SHA-1
+``commit'' específico usando la firma SHA-1. Puedes utilizar la cadena SHA-1
 completa (de 40 caracteres) y al detectarla GitHub en un comentario, la
-convertirá automáticamente en un enlace directo al commit. Nuevamente,
+convertirá automáticamente en un enlace directo al ``commit''. Nuevamente,
 puedes hacer referencia a commits en bifurcaciones o en otros
 repositorios del mismo modo que hicimos con las incidencias.
 
 ==== Markdown
 
-En enlazado a otras incidencias es solo el comienzo de las cosas interesantes
+El enlazado a otras incidencias es sólo el comienzo de las cosas interesantes
 que se pueden hacer con cualquier cuadro de texto de GitHub. En las
 descripciones de las incidencias y los Pull Requests, así como en los
-comentarios, y otros cuadros de texto, se puede usar lo que se conoce
+comentarios y otros cuadros de texto, se puede usar lo que se conoce como
 ``formato Markdown de GitHub''. El formato Markdown es como escribir en texto
 plano pero que luego se convierte en texto con formato.
 
@@ -471,7 +470,7 @@ La primera característica añadida, especialmente interesante para los
 Pull Requests, son las listas de tareas. Una lista de tareas
 es una lista de cosas con su marcador para indicar que han terminado. En
 un Pull Requests o una incidencia nos sirven para anotar la lista de cosas
-pendientes para considerar terminado el trabajo relacionado con esa
+pendientes a realizar para considerar terminado el trabajo relacionado con esa
 incidencia.
 
 Puedes crear una lista de tareas así:
@@ -492,13 +491,13 @@ image::images/markdown-02-tasks.png[Ejemplo de lista de tareas]
 
 Esto se suele usar en Pull Requests para indicar qué cosas hay que hacer
 en la rama antes de considerar que el Pull Request está listo para fusionarse.
-La parte realmente interesante es que puedes pulsar los marcadores para
+La parte realmente interesante, es que puedes pulsar los marcadores para
 actualizar el comentario indicando qué tareas se finalizaron, sin necesidad
 de editar el texto markdown del mismo.
 
 Además, GitHub mostrará esas listas de tareas como metadatos de las páginas
 que las muestran. Por ejemplo, si tienes un Pull Request con tareas y
-miras la página resumen de todos los Pull Request, podrás ver cuánto trabajo
+miras la página de resumen de todos los Pull Request, podrás ver cuánto trabajo
 queda pendiente. Esto ayuda a la gente a dividir los Pull Requests en subtareas
 y ayuda a otras personas a seguir la evolución de la rama. Se puede ver un
 ejemplo de esto en <<r_task_list_progress>>.
@@ -557,18 +556,18 @@ Un ejemplo de cita:
 How big are these slings and in particular, these arrows?
 ----
 
-Una vez introducida, el comentario se vería como en <<r_md_quote>>.
+Una vez introducido, el comentario se vería como en <<r_md_quote>>.
 
 [[r_md_quote]]
 .Rendered quoting example.
 image::images/markdown-05-quote.png[Rendered quoting]
 
 ====== Emojis (emoticonos)
 
-Finalmente, también puedes usar emoji (emoticonos) en tus comentarios. Se
+Finalmente, también puedes usar emojis (emoticonos) en tus comentarios. Se
 utiliza mucho en las discusiones de las incidencias y Pull Requests de GitHub.
 Incluso tenemos un asistente de emoji: si escribes un comentario y tecleas el
-carácter `:`, verás cómo aparecen iconos para ayudarte a completar el
+caracter `:`, verás cómo aparecen iconos para ayudarte a completar el
 que quieras poner.
 
 [[r_md_emoji_auto]]