Skip to content

Update guidelines re: DOI #1990

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Jan 21, 2021
Merged

Update guidelines re: DOI #1990

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
a315c06
Update guidelines
walshbr Jan 20, 2021
261bb58
update ES guidelines
rivaquiroga Jan 20, 2021
585b7a7
fix time zone
rivaquiroga Jan 20, 2021
d9589b6
Update directrizes-editor.md
DanielAlvesLABDH Jan 21, 2021
8d71ffd
Update directrizes-editor.md
DanielAlvesLABDH Jan 21, 2021
ce768a2
Update consignes-redacteurs.md
spapastamkou Jan 21, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 10 additions & 4 deletions en/editor-guidelines.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -341,7 +341,13 @@ The Managing Editor is responsible for carefully checking the lesson to make sur

Check the submission preview for any errors or failures to meet our publication guidelines. Refer any issues back to the editor.

## 2) Move the Files
## 2) Request DOI

You need to request a new DOI for the lesson following the steps described in the [Wiki](https://github.com/programminghistorian/jekyll/wiki/How-to-Request-a-new-DOI).

This part of the process should not take you more than one or two days, depending on the time difference you have with the UK (UTC). You can start next steps while you wait, but note that builds will initially fail until the DOI has been added to the lesson metadata.

## 3) Move the Files

The editor should have left you a clear list of files that need to be published on the submission ticket. If they have not done so, ask them to fix it before proceeding.

Expand All @@ -365,7 +371,7 @@ After the lesson has been moved to the `jekyll` repository, you'll also need to
4. Move the image folder containing the images for the now published lesson from `images/` to `images/published/`.
5. Use `git add`, `git commit`, and `git push` to finalize all the changes (or follow the Making Technical Contributions instructions: https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions)

## 3) Add the author bio to ph_authors.yml
## 4) Add the author bio to ph_authors.yml

If the lesson has been written by a new author, the managing editor should add information about the author to the site's [authors directory](https://github.com/programminghistorian/jekyll/blob/gh-pages/_data/ph_authors.yml). Follow the syntax for the examples already included there, using the bio that the editor provided you:

Expand All @@ -379,7 +385,7 @@ If the lesson has been written by a new author, the managing editor should add i
at the University of Saskatchewan.
```

## 4) Confirm all links and YAML headers are functioning correctly
## 5) Confirm all links and YAML headers are functioning correctly

Once you push your changes on to the `gh-pages` branch of the [programminghistorian][ph_repo] repository, the site will be automatically tested by [Travis CI] ([Continuous Integration]).
This test process checks three things: first, that all YAML and markdown code is parseable; second, that all the hyperlinks on the site point to valid, operational pages; and third, that internal links to pages on the _Programming Historian_ are all relative links that start with `/` rather than `https://programminghistorian.org/`
Expand Down Expand Up @@ -416,6 +422,6 @@ If your build has errored, you will need to consult the build logs to see what i

[create a new issue]: https://github.com/programminghistorian/jekyll/issues/new

## 5) Inform the Editor
## 6) Inform the Editor

Once the lesson has been published, inform the editor and ensure they have added the lesson to the twitter bot pipeline.
20 changes: 12 additions & 8 deletions es/guia-editor.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -363,19 +363,23 @@ Una vez que se le haya dado la palabra de que al jefe de redacción ha publicado

¡Por favor, no abandones la lección a su suerte! Ya hemos realizado el trabajo, así que asegurémosnos que ha valido la pena.

## Jefe de redacción - Lista de verificación
## Jefe/a de redacción - Lista de verificación

### 1) Haz una lectura rápida

Compruebe la vista previa de la presentación para ver si hay errores obvios como imágenes rotas o formato extraño. Informar al editor de cualquier error, que son responsables de ser arreglados.
Comprueba la vista previa de la presentación para ver si hay errores obvios como imágenes rotas o formato extraño. Informa al editor de cualquier error, quien es responsables de arreglarlos.

### 2) Mueve el archivo
### 2) Solicita el DOI

El editor de gestión es responsable de mover los archivos al sitio web principal a través de una 'pull request'. Esta es también una oportunidad para el editor de gestión para familiarizarse con la nueva lección, y para comprobar rápidamente que todo se ve bien.
Solicita un nuevo DOI para la lección siguiendo los pasos descritos en el [Wiki](https://github.com/programminghistorian/jekyll/wiki/How-to-Request-a-new-DOI). Esta parte del proceso no debería demorar más de uno o dos días, dependiendo de la diferencia horaria que tengas con el Reino Unido (UTC). Puedes avanzar con los siguientes pasos mientras esperas la respuesta, pero ten en cuenta que el build fallará mientras el DOI no sea añadido a los metadatos de la lección.

Sus opciones son:
### 3) Mueve los archivos

A) Siga nuestras ["Making Technical Contributions" guidelines](https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions) que utiliza el sitio web de github GUI.
El jefe o jefa de redacción es responsable de mover los archivos al sitio web principal a través de un 'pull request'. Esta es también una oportunidad para familiarizarte con la nueva lección, y para comprobar rápidamente que todo se ve bien.

Las opciones son:

A) Sigue nuestra guía para ["hacer contribuciones técnicas"](https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions), que utiliza el sitio web de GitHub.

B) La manera más fácil de publicar el texto es utilizar git en tu terminal de línea de comandos. Las siguientes instrucciones presuponen que ya has clonado en tu ordenador los repositorios jekyll y ph-submissions/es (si no es así, nuestra [introducción a GitHub](/lessons/getting-started-with-github-desktop) puedes ser útil). Si tienes alguna duda puedes contactar al equipo técnico.

Expand All @@ -393,7 +397,7 @@ Después de haber movido la lección al repositorio local de `jekyll` tendrás a
4. Mueve el directorio de imágenes que contiene las imágenes de la lección ya publicada de `images/` a `images/published/`.
5. Utiliza `git add`, `git commit`, y `git push` para finalizar todos los cambios (o sigue las instrucciones "Making technical contributions": https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions).

### 3) Añade la biografía del autor a ph_authors.yml
### 4) Añade la biografía del autor a ph_authors.yml
Si la lección ha sido escrita por un nuevo autor, el jefe de redacción debe añadir información sobre el autor al directorio [autores](https://github.com/programminghistorian/jekyll/blob/gh-pages/_data/ph_authors.yml) del sitio. Sigue la sintaxis de los ejemplos ya incluidos, utilizando la biografía que el editor le proporcionó:

```yaml
Expand All @@ -404,7 +408,7 @@ Si la lección ha sido escrita por un nuevo autor, el jefe de redacción debe a
Jim Clifford es profesor ayudante en el Departamento de Historia de la Universidad de Saskatchewan.
```

### 4) Confirma que todos los enlaces y encabezados YAML funcionen correctamente
### 5) Confirma que todos los enlaces y encabezados YAML funcionen correctamente
Una vez que envíes tus cambios a la rama `gh-pages` del repositorio de [Programminghistorian][ph_repo], el sitio será comprobado automáticamente por [Travis CI] ([Continuous Integration]).

Este proceso comprueba tres cosas: primero, que todo el código de YAML y markdown sea compilable; segundo, que todos los hipervínculos del sitio apunten a páginas válidas y en funcionamiento; por último, que todos los hipervínculos internos a otras páginas de _The Programming Historian en español_ son relativos y empiezan con una barra lateral `/` en lugar de `https://programminghistorian.org/es`.
Expand Down
14 changes: 9 additions & 5 deletions fr/consignes-redacteurs.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -142,7 +142,7 @@ Vous pouvez vérifier rapidement si tout se présente correctement au cours de l

Si cela ne marche pas, merci d'en informer notre équipe technique qui s'occupera du problème.

### C) Vérifier la pérennité et de l'ouverture internationale
### C) Vérifier la pérennité et l'ouverture internationale

Pour augmenter la durée de vie de nos leçons, les rédacteurs et rédactrices du _Programming Historian en français_ doivent vérifier que sont réunies certaines conditions qui garantissent la pérennité de la leçon. Certes, les mêmes critères ne peuvent pas nécessairement s'appliquer à tous les dépôts, vu que chaque cas est différent. Toutefois, en tenant compte du niveau de difficulté de chaque leçon et du public auquel il s'adresse, les rédacteurs et les rédactrices peuvent s'appuyer sur les critères suivants pour s'assurer de la longévité des leçons après la date de leur publication.

Expand Down Expand Up @@ -327,9 +327,13 @@ Le rédacteur ou la rédactrice en chef a la responsabilité de déposer les fic

## 1) Parcourir l'aperçu de la soumission

Vérifier l'aperçu de la soumission pour repérer des erreurs manifestes, comme des problèmes d'affichage des images ou de formattage. Prévenez-en, le cas échéant, le rédacteur ou la rédactrice en charge de la leçon pour les corriger.
Vérifiez l'aperçu de la soumission pour repérer des erreurs manifestes, comme des problèmes d'affichage des images ou de formattage. Prévenez-en, le cas échéant, le rédacteur ou la rédactrice en charge de la leçon pour les corriger.

## 2) Transférer les fichiers
## 2) Solliciter un identifiant DOI

Prenez soin de solliciter un nouveau DOI pour la leçon selon les instructions du Wiki. L'obtenir ne devrait pas vous prendre plus d'un jour ou deux, en fonction du décalage horaire entre votre pays de résidence et le Royaume-Uni (UTC +1). Vous pouvez commencer à réaliser les étapes suivantes en attendant, sachez toutefois que le processus de modification de la page (build) échouera tant que le DOI n'aura pas été ajouté aux metadonnées.

## 3) Transférer les fichiers

Le rédacteur ou la rédactrice aurait dû vous laisser une liste claire, dans le ticket de la soumission, avec les fichiers à être publiés. Si ce n'est pas le cas, demandez que cela s'arrange avant d'aller plus loin. The editor should have left you a clear list of files that need to be published on the submission ticket. If they have not done so, ask them to fix it before proceeding.

Expand All @@ -354,7 +358,7 @@ Après le transfert de la leçon dans le répertoire `jekyll`, il faudra aussi a
4. Copier le dossier qui contient les images de la leçon publiée depuis `images/` vers `images/published/`.
5. Exécuter les commandes `git add`, `git commit` et `git push` pour finaliser toutes les modifications.

## 3) Vérifier les liens et les en-tête en YAML
## 4) Vérifier les liens et les en-tête en YAML

Une fois que vous aurez soumis vos modifications à la branche `gh-pages` du dépôt du [programminghistorian][ph_repo], le site web sera automatiquement testé par [Travis CI] ([Continuous Integration]).
Cette procédure teste trois choses. D'abord, que tout le code en YAML et markdown peut être parsé. Ensuite, que tous les hyperliens du site web pointent vers des pages valides et opérationnelles. Enfin, que les liens internes pointant vers des pages du _Programming Historian_ sont des liens relatifs qui commencent par `/` plutôt que par `https://programminghistorian.org/`
Expand Down Expand Up @@ -391,6 +395,6 @@ Si votre compilation a échoué, il est nécessaire de consulter l'historique po

[créer un nouveau ticket]: https://github.com/programminghistorian/jekyll/issues/new

## 4) Tenir au courant le rédacteur ou la rédactrice en charge du suivi éditorial de la leçon
## 5) Tenir au courant le rédacteur ou la rédactrice en charge du suivi éditorial de la leçon

Lorsque la leçon a été publiée, merci d'en informer le rédacteur ou la rédactrice qui en a assuré le suivi éditorial.
14 changes: 10 additions & 4 deletions pt/directrizes-editor.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -343,7 +343,13 @@ O Editor-chefe é responsável por verificar cuidadosamente a lição e garantir

Verificar a pré-visualização da proposta quanto a erros ou falhas de acordo com as orientações de publicação. Qualquer problema deve ser remetido ao editor.

## 2) Mover os ficheiros
## 2) Solicitar o DOI

O editor precisa solicitar um novo DOI para a lição seguindo os passos descritos no [Wiki](https://github.com/programminghistorian/jekyll/wiki/How-to-Request-a-new-DOI).

Esta parte do processo não deve levar mais de um ou dois dias, dependendo da diferença de horário com o Reino Unido. O editor pode iniciar as próximas etapas enquanto espera, mas deve notar que as verificações da página inicialmente falharão até que o DOI seja adicionado aos metadados da lição.

## 3) Mover os ficheiros

O editor deve ter deixado uma lista clara dos ficheiros que precisam de ser publicados na thread de submissão. Se não estiver, é preciso pedir que corrijam antes de continuar.

Expand All @@ -367,7 +373,7 @@ Após a lição ter sido colocada para o repositório `jekyll`, também é neces
4. Mover a pasta que contém as imagens da lição agora publicada de `images/` para `images/published/`.
5. Usar comandos `git add`, `git commit` e `git push` para finalizar todas as alterações (ou seguir as orientações para contribuições técnicas: https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions).

## 3) Adicionar a biografia do autor a ph_authors.yml
## 4) Adicionar a biografia do autor a ph_authors.yml

Se a lição foi escrita por um autor novo, o editor-chefe deve adicionar informações sobre o autor à [lista de autores](https://github.com/programminghistorian/jekyll/blob/gh-pages/_data/ph_authors.yml). É para seguir a sintaxe dos exemplos já colocados, usando a biografia fornecida pelo editor:

Expand All @@ -381,7 +387,7 @@ Se a lição foi escrita por um autor novo, o editor-chefe deve adicionar inform
da Universidade do Algarve.
```

## 4) Confirmar se todos os links e cabeçalhos YAML funcionam corretamente
## 5) Confirmar se todos os links e cabeçalhos YAML funcionam corretamente

Depois de enviar as alterações para o ramo `gh-pages` do repositório [programminghistorian](https://github.com/programminghistorian/jekyll), o site será automaticamente testado pelo [Travis CI](https://travis-ci.org)([Continuous Integration](https://www.thoughtworks.com/continuous-integration)).
O processo de teste verifica três coisas: primeiro, se todo o código YAML e markdown está legível; segundo, que todos os hiperlinks apontam para páginas operacionais válidas; e terceiro, que os links internos para páginas no *Programming Historian em português* são todos links relativos que começam com / em vez de https://programminghistorian.org/pt.
Expand Down Expand Up @@ -415,6 +421,6 @@ Se a compilação falhou, será necessário consultar os logs para ver qual a ra

- Como parte das suas operações normais, o Travis CI ocasionalmente retorna e verifica novamente links antigos em todo o site, incluindo lições antigas. Portanto, pode aparecer um erro causado não pela lição nova, mas por outra página. Se for possível compreender como corrigir imediatamente os erros, basta fazer a correcção e aguardar por uma nova compilação. Se não for possível fazer todas as correcções necessárias para todos os links identificados com erros, depois de verificar que nenhum vem da nova lição, basta [criar uma nova questão](https://github.com/programminghistorian/jekyll/issues/new) para que alguém da equipe técnica possa analisar o problema.

## 5) Informar o Editor
## 6) Informar o Editor

Depois da lição estar publicada, deve informar o editor e verificar que a lição foi adicionada ao bot do twitter.