add es/community/ruby-core (#2708)

* add es/community/ruby-core

* Remove blank line at the end of the file

* Attend pr comments

Author: emerak

es/community/ruby-core/index.md

@@ -0,0 +1,136 @@
+---
+layout: page
+title: "Ruby Core"
+lang: es
+---
+
+Ahora es un momento fantástico para seguir el desarrollo de Ruby.
+Con la mayor atención que Ruby ha recibido en los últimos años,
+existe una creciente necesidad de buenos talentos para ayudar a mejorar Ruby
+y documentar sus partes. Entonces, ¿por dónde empezar?
+{: .summary}
+
+Los temas relacionados con el desarrollo de Ruby que se tratan aquí son:
+
+* [Usando Git para rastrear el desarrollo de Ruby](#following-ruby)
+* [Mejorando Ruby, Parche por Parche](#patching-ruby)
+* [Nota sobre las ramas](#branches-ruby)
+
+### Usando Git para rastrear el desarrollo de Ruby
+{: #following-ruby}
+
+El repositorio principal actual del último código fuente de Ruby es
+[git.ruby-lang.org/ruby.git][gitrlo].
+También existe un repositorio [espejo en GitHub][7]. En lo general, usa el
+repositorio espejo, por favor.
+
+Puedes obtener el último código fuente de Ruby usando Git.
+Desde tu línea de comandos:
+
+{% highlight sh %}
+$ git clone https://github.com/ruby/ruby.git
+{% endhighlight %}
+
+El directorio `ruby` ahora contendrá el último código fuente
+para la versión de desarrollo de Ruby (ruby-trunk).
+
+Vease también [Cómo unirse a nuestro desarrollo como no contribuyente de código fuente][noncommitterhowto].
+
+Si tienes permisos de contribución al código fuente y deseas empujar cambios,
+deberías usar el repositorio principal.
+
+{% highlight sh %}
+$ git clone [email protected]:ruby.git
+{% endhighlight %}
+
+### Mejorando Ruby, Parche por Parche
+{: #patching-ruby}
+
+El equipo central mantiene un [rastreador de problemas][10] para enviar parches e
+informes de errores a Matz y al grupo. Estos informes también se envían a
+la [lista de distribución de Ruby-Core][mailing-lists] para discusión,
+así que puedes estar seguro que tu petición no pasará desapercibida.
+También puedes enviar tus parches directamente a la lista de
+distribución. De cualquier manera, te invitamos a formar parte de las
+discusiones siguientes.
+
+Consulta la [Guía del redactor de Parches][writing-patches] para obtener algunos consejos,
+directamente de Matz, sobre cómo hacer que tus parches sean considerados.
+
+En resumen, los pasos para crear un parche son:
+
+1.  Consulta una copia del código fuente de Ruby de GitHub.
+    Por lo general, los parches para la corrección de errores
+    o las nuevas funciones deben enviarse al tronco de la fuente de Ruby.
+
+        $ git clone https://github.com/ruby/ruby.git
+
+    Si estás solucionando un error que es específico de una sola rama de mantenimiento,
+    revisa una copia de la rama respectiva.
+
+        $ git checkout ruby_X_X
+
+    X_X debe ser reemplazado por la versión que desees revisar.
+
+2.  Agrega tus mejoras al código.
+
+3.  Crea un parche.
+
+        $ git diff > ruby-changes.patch
+
+4.  Crea un ticket en el [rastreador de problemas][10] o envía tu parche
+    a la [lista de distribución de Ruby-Core][mailing-lists] con un registro de ChangeLog
+    describiendo tu parche.
+
+5.  Si no surgen problemas sobre el parche, los contribuyentes darán
+    la aprobación para aplicarlo.
+
+**Por favor ten en cuenta:** los parches deben enviarse como una [diferencia unificada][12].
+Para obtener más información sobre cómo se fusionan los parches, consulta [la referencia de diffutils][13].
+
+La discusión sobre el desarrollo de Ruby converge en la
+[Lista de distribución de Ruby-Core][mailing-lists]. Entonces, si tienes curiosidad
+sobre si tu parche vale la pena o si deseas iniciar una discusión
+sobre el futuro de Ruby, no dudes en subir a bordo.
+Ten presente que las discusiones fuera de tema no se toleran en esta lista,
+el nivel de ruido debe ser muy bajo, los temas deben ser puntuales, bien concebidos y
+bien escritos. Ya que nos dirigimos al creador de Ruby, tengamos un poco de reverencia.
+
+Ten en cuenta que muchos de los desarrolladores principales de Ruby viven en Japón y, aunque muchos
+hablan muy bien inglés, hay una diferencia de zona horaria significativa.
+También tienen un cuerpo completo de listas de desarrollo japonesas sucediendo
+junto a las contrapartes inglesas. Se paciente,
+si tu petición no se resuelve, se persistente, inténtalo de nuevo unos días más tarde.
+
+
+### Nota sobre las ramas
+{: #branches-ruby}
+
+El código fuente de Ruby se había gestionado en el repositorio de Subversion hasta el 22 de abril de 2019.
+Por lo tanto, algunas ramas aún pueden administrarse bajo Subversion.
+Puedes ver el repositorio de SVN.
+
+* [<URL:https://svn.ruby-lang.org/cgi-bin/viewvc.cgi?root=ruby>][svn-viewvc]
+
+Sin embargo, no tienes que preocuparte por eso (a menos que seas un mantenedor de rama).
+Puedes consultar las ramas en tu copia de trabajo de Git.
+Por ejemplo, ejecuta el siguiente comando.
+
+{% highlight sh %}
+$ git checkout ruby_X_X
+{% endhighlight %}
+
+X_X debe ser reemplazado por la versión que desees revisar.
+
+Si deseas modificar las ramas, por favor, abre una incidencia en nuestro [rastreador de problemas][10].
+Ver también la siguiente sección.
+
+[gitrlo]: https://git.ruby-lang.org/ruby.git
+[mailing-lists]: /es/community/mailing-lists/
+[writing-patches]: /es/community/ruby-core/writing-patches/
+[noncommitterhowto]: https://github.com/shyouhei/ruby/wiki/noncommitterhowto
+[svn-viewvc]: https://svn.ruby-lang.org/cgi-bin/viewvc.cgi?root=ruby
+[7]: https://github.com/ruby/ruby
+[10]: https://bugs.ruby-lang.org/
+[12]: http://www.gnu.org/software/diffutils/manual/html_node/Unified-Format.html
+[13]: http://www.gnu.org/software/diffutils/manual/html_node/Merging-with-patch.html#Merging%20with%20patch

es/community/ruby-core/writing-patches/index.md

@@ -0,0 +1,47 @@
+---
+layout: page
+title: "Guía del redactor de Parches"
+lang: es
+---
+Sigue algunos consejos, directamente de Matz, sobre cómo hacer para que tus parches sean considerados.
+{: .summary}
+
+Estas pautas fueron adoptadas de una [publicación hecha por Matz][ruby-core-post]
+en la lista de distribución de Ruby-Core:
+
+* Implementa una modificación por parche
+
+  Este es el mayor problema para la mayoría de los parches diferidos. Cuando tú
+  envias un parche que corrija varios errores (y agregue funciones) a la vez,
+  tenemos que separarlos antes de aplicarlos. Es una tarea bastante difícil para nosotros,
+  desarrolladores ocupados, por lo que este tipo de parches tiende a aplazarse.
+  Por favor, no envies parches grandes.
+
+* Agrega descripciones
+
+  A veces, un simple parche no describe suficientemente el problema que soluciona.
+  Una mejor descripción (el problema que soluciona, las condiciones previas, la plataforma, etc.)
+  ayudaría a un parche a aplicarse más rápido.
+
+* Haz diff a la última revisión
+
+  Es posible que tu problema se haya solucionado en la última revisión. O el código
+  podría ser totalmente diferente a estas alturas. Antes de enviar un parche, intenta recuperar
+  la última versión (la rama `trunk` para la última versión de desarrollo,
+  `{{ site.svn.stable.branch }}` para {{ site.svn.stable.version }})
+  desde el repositorio de Subversion, por favor.
+
+* Usa `diff -u`
+
+  Preferimos los parches de diferencias unificados de estilo `diff -u` a diferencia de `diff -c`
+  o cualquier otro estilo de parches. Son mucho más fáciles de revisar.
+  No envíes archivos modificados, no queremos hacer un diff por nosotros mismos.
+
+* Proporciona casos de prueba (opcional)
+
+  Un parche que proporciona casos de prueba (preferiblemente un parche para `test/*/test_*.rb`)
+  nos ayudaría a comprender el parche y su intención.
+
+Podríamos pasar a un flujo de trabajo push/pull estilo Git en el futuro..
+Pero hasta entonces, seguir las pautas anteriores te ayudaría a evitar
+una frustración.