Update Guidelines for Submitting Lessons to ph-submissions

en/author-guidelines.md

@@ -297,14 +297,13 @@ Follow best practice in writing your code:
 
 Double-check that your lesson file has been prepared to the above specifications. Once you are satisfied, we strongly recommend that you ask at least two people to try your tutorial and provide feedback. This will help you make improvements that mean our peer reviewers can focus on helping you produce the strongest possible lesson.
 
-You are ready to submit the lesson for peer review. Submissions are made to our peer review site on [Github](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/lessons).
-
-1. **Getting Access**: create a [free Github account](https://github.com/join). Email your Github username to your editor who will give you upload access to our submission site. Let the editor know the file name of your lesson and if you have any images or data files accompanying your tutorial.
-3. **Uploading your Lesson**: once your editor confirms you have been granted access to the site, upload your lesson to the [lessons folder](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/lessons). If you need help, see [GitHub's instructions](https://help.github.com/articles/adding-a-file-to-a-repository/).
-4. **Uploading Images**: if your lesson includes images, make sure all of the files are named according to the naming conventions specified above. Your editor will have created a folder for you to upload your images in the  [images directory](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/images). This folder should have the same name as your lesson filename. Upload your images to this folder. If you don't see it, please contact your editor and wait for instructions.
-5. **Uploading Data**: if your lesson includes data files, they should similarly be uploaded to a similarly named folder in the [assets directory](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/assets).
-6. **Email your editor** to let them know that you have uploaded your files.
+You are ready to submit the lesson for peer review. Submissions are made by emailing materials to your editor so they can upload them to our peer review site on [Github](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/lessons).
 
+1. **Getting Access**: create a [free Github account](https://github.com/join). Email your Github username to your editor who will give you upload access to our submission site. Let the editor know the file name of your lesson and if you have any images or data files accompanying your tutorial. You will not do the initial upload to GitHub, but you will need access to post subsequent revisions.
+2. **Prepare your materials**: if your lesson includes images, make sure all of the files are named according to the naming conventions specified above.These images should be submitted in a single, compressed folder. If your lesson includes data files, they should be submitted in another compressed folder.
+3. **Email your editor**: let your editor know that you are ready to submit your lesson. This email should include the lesson file as well as the image and assets folders if applicable.
+4. **Join the conversation**: the editor will upload your files to our [submissions repository](https://github.com/programminghistorian/ph-submissions) and make any necessary, initial changes to them. They will also open a review ticket for your lesson.
+5. **Make revisions**: the initial lesson upload will be carried out by your assigned editor, but the editorial process will require that you make further changes. All subsequent revisions should be made by the author directly to the files in our submissions repository to ensure you are working from the latest version of the lesson file.
 
 ## The Peer Review Process
 

en/editor-guidelines.md

@@ -50,7 +50,13 @@ The main editorial contact for this lesson is [EDITOR USERNAME]. If there are an
 
 The editor is encouraged to adjust the issue text to reflect any additional goals or requirements agreed upon between the author(s) and editor.
 
-Upon successful submission of the lesson, the editor will create a review ticket for the lesson and close the proposal issue.
+When the lesson materials are ready for submission, the author will contact their assigned editor, whose job will be to upload them to the [ph-submissions repository](https://github.com/programminghistorian/ph-submissions) after first checking to ensure that there are no major metadata issues. 
+
+1. **Uploading the Lesson**: the lesson itself should be uploaded to the [lessons folder](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/lessons). If you need help, see [GitHub's instructions](https://help.github.com/articles/adding-a-file-to-a-repository/).
+2. **Uploading Images**: if the lesson includes images, make sure all of the files are named according to the naming conventions specified in the [author guidelines](/author-guidelines). The editor should create a folder for the images in the  [images directory](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/images). This folder should have the same name as the lesson filename. Upload the images to this folder.
+3. **Uploading Data**: if the lesson includes data files, they should be uploaded to a similarly named folder in the [assets directory](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/assets).
+
+After uploading, the editor should check the [commit history for the repository](https://github.com/programminghistorian/ph-submissions/commits/gh-pages) to ensure that their upload received a green check mark. If not, something went wrong and the [wiki](https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions#checking-travis-for-errors) should be consulted for troubleshooting the errors. Upon successful submission of the lesson, the editor will create a review ticket for the lesson and close the proposal issue. From here on, the editor should ensure that the author work from the latest version of the lesson in the repository and upload changes directly to GitHub themselves. 
 
 ### Open Peer Review
 The *Programming Historian* uses a model of open peer review, while we believe this helps maintain civility and the productive sharing of ideas, authors have the right (and we have a requirement to respect that right) to request a closed peer review. There are many reasons why someone might be hesitant to engage in an open review and we encourage authors to always pursue the option with which they are most comfortable.

es/guia-editor.md

@@ -36,20 +36,26 @@ Una vez se ha aceptado una propuesta de lección, el editor aclarará al autor c
 A continuación, el editor creará un *issue* en el [repositorio de GitHub](https://github.com/programminghistorian/ph-submissions/issues)    con la etiqueta “proposals” para las nuevas lecciones. La plantilla viene incluida por defecto en el *issue*, pero también se puede copiar el texto que se encuentra más abajo.
 
 	*The Programming historian* ha recibido una propuesta de lección con el título provisional ‘Título provisional de la lección’ por parte de ‘Nombre del autor o autores’. Los objetivos de la lección son:
-
+	
 	- objetivo nº1
 	- objetivo nº2
 	- objetivo nº3
-
+	
 	A fin de promover una publicación a tiempo, se ha acordado que la lección se entregará en un plazo de [90 days por defecto o más tarde si se ha establecido así con el autor]. El autor o autores contactará con antelación con el editor si no puede cumplir con la fecha de entrega y necesita una ampliación.
-
+	
 	Si la lección no es entregada en la [fecha acordada], el editor intentará contactar con el autor o autores de la lección. Si no recibe noticias, el ticket se cerrará. Éste podrá abrirse en el futuro a petición del autor o autores.
-
+	
 	El principal contacto para esta lección es [nombre del editor]. Si se produce algún problema, el autor puede contactar con nuestros ’ombudsperson' (Silvia Gutiérrez De la Torre - http://programminghistorian.org/es/equipo-de-proyecto).
 
 Este texto, sin embargo, puede editarse y adaptarse a las necesidades para reflejar más objetivos o lo que se ha negociado entre el editor y el autor.
 
-Una vez la lección haya sido entregada, el editor creará un ticket de revisión para la lección y cerrará el *issue* correspondiente a la propuesta inicial.
+Cuando los materiales de la lección estén listos para su envío, los autores se pondrán en contacto con su editor/a asignado/a, cuyo trabajo será subirlos al [repositorio de envíos de ph](https://github.com/programminghistorian/ph-submissions) después de realizar una primera verificación para garantizar que no haya problemas importantes con los metadatos.
+
+1. **Subir la lección**: el archivo de la lección debe subirse en la carpeta para lecciones o traducciones. Si necesitas ayuda, dirígete a las [instrucciones de Github](https://help.github.com/articles/adding-a-file-to-a-repository/).
+2. **Subir imágenes**: si la lección contiene imágenes, aseguráte de que todos los archivos sigan las convenciones para nombres de figuras e imágenes en la [guía para autores](/es/guia-para-autores). Quien edita la lección debe crear una carpeta para las imágenes en el [directorio *images*](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/images). Esta carpeta debe tener el mismo nombre que el archivo de la lección. Carga las imágenes en la carpeta.
+3. **Subir archivos datos**: si la lección incluye archivos de datos, estos deben ser subidos a una carpeta con el mismo nombre del archivo de la lección en el [directorio *assets.*](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/assets) 
+
+Después de subir todo, el/la editor/a debe comprobar que la carga de archivos recibe una marca verde de aprobación en [la historia del repositorio](https://github.com/programminghistorian/ph-submissions/commits/gh-pages). Si la marca no es verde, algo fue mal y entonces se debe consultar la [wiki](https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions#checking-travis-for-errors) para tratar de subsanar los errores existentes. Una vez que se haya cargado correctamente la lección, el/la editor/a creará un ticket de revisión para la lección y cerrará el *issue* de la propuesta. A partir de aquí, esta misma persona debe asegurarse de que el/la autor/a trabaje con la última versión de la lección en el repositorio y cargar los cambios directamente en GitHub.
 
 ### Revisión por pares en abierto
 

es/guia-para-autores.md

@@ -295,14 +295,12 @@ Sigue las mejores prácticas para escribir tu código:
 
 Una vez que tu archivo ha sido preparado de acuerdo con las especificaciones anteriores, ¡ya puedes enviárnoslo! Te sugerimos, de todos modos, que pidas al menos a dos personas que prueben tu lección y te den su opinión. Es muy importante que pruebes que es posible seguir el tutorial desde distintos sistemas operativos sin problema. Esto permitirá al equipo editorial centrarse en que produzcas una lección lo más sólida posible.
 
-En el GitHub de [Programming Historian](https://github.com/programminghistorian) mantemos dos repositorios (es decir, dos sitios en donde almacenar archivos y carpetas). Por un lado, el repositorio [jekyll](https://github.com/programminghistorian/jekyll), que contiene los archivos a los que se accede a través del navegador [web](/es). Por el otro, el repositorio llamado [ph-submissions](https://github.com/programminghistorian/ph-submissions), que es donde se realiza el proceso de edición de las lecciones.
+Ahora estás listo para enviar la lección a revisión. Los envíos se realizan enviando los materiales por correo electrónico a tu editor o editora para que puedan subirlos a nuestro repositorio de revisión por pares en [Github](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/lessons). Sigue estos pasos:
 
-Debes enviar tu lección a través de una correo electrónico a tu editor/a, quien se encargará de subir todos los materiales al repositorio correspondiente en [GitHub](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/es/lecciones).
-
-1. **Obtener acceso**: crea una [cuenta gratuita en GitHub](https://github.com/join). Envía tu nombre de usuario de GitHub a tu editor/a, quien te dará acceso al sitio de envíos. Si bien no harás la carga inicial en GitHub, necesitarás acceso para el proceso de revisión.
+1. **Obtener acceso**: crea una cuenta gratuita en GitHub [aquí](https://github.com/join). Solo se necesitan 30 segundos. Envía por correo electrónico tu nombre de usuario/a de Github a tu editor/a, quien le dará acceso a nuestro repositorio. Indícale también el nombre del archivo de la lección y si tiene imágenes o archivos de datos que acompañen al tutorial. Tú no realizarás la carga inicial en GitHub, pero necesitarás acceso para publicar revisiones posteriores.
 2. **Prepara los materiales**: si tu lección incluye imágenes, asegúrate que todos los archivos están nombrados según las convenciones explicadas más arriba. Las imágenes debes enviarlas en una sola carpeta comprimida. Si tu lección incluye archivos de datos, estos deben ser enviados en otra carpeta comprimida.
-3. **Envía un correo electrónico a tu editor/a**: hazle saber a tu editor/a que tienes todo listo para el envío de tu lección. Este correo electrónico debe incluir el archivo .md de la lección y las carpetas comprimidas con las imágenes y datos, si corresponde.
-4. **Únete a la conversación**: tu editor/a subirá los archivos a nuestro [repositorio de envíos](https://github.com/programminghistorian/ph-submissions) y hará algunos cambios iniciales para asegurarse de que todo funciona bien. Además, abrirá un "ticket de revisión" para tu lección en la sección de *[issues](https://github.com/programminghistorian/ph-submissions/issues)* de ese repositorio.
+3. **Envía un correo electrónico a tu editor/a**: hazle saber a tu editor/a que tienes todo listo para el envío de tu lección. Este correo electrónico debe incluir el archivo markdown (.md) de la lección y las carpetas comprimidas con las imágenes y datos, si corresponde.
+4. **Únete a la conversación**: quien edita la lección subirá los archivos a nuestro [repositorio de envíos](https://github.com/programminghistorian/ph-submissions) y hará algunos cambios iniciales para asegurarse de que todo funciona bien. Además, abrirá un "ticket de revisión" para tu lección en la sección de *[issues](https://github.com/programminghistorian/ph-submissions/issues)* de ese repositorio.
 5. **Realiza las revisiones**: si bien la carga inicial de tu lección en el repositorio `ph-submissions` será realizada por tu editor/a, el proceso editorial requerirá que hagas modificaciones. Todas las ediciones posteriores deben ser hechas directamente por ti en ese repositorio para asegurarnos de que estás trabajando en la última versión del archivo.
 
 ## El proceso de revisión de pares