From 5438c6185a9d7691dc58b845df159452903e43ef Mon Sep 17 00:00:00 2001 From: walshbr Date: Fri, 10 Jul 2020 14:24:07 -0400 Subject: [PATCH 01/10] Update guidelines --- en/author-guidelines.md | 9 ++++----- en/editor-guidelines.md | 8 +++++++- 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/en/author-guidelines.md b/en/author-guidelines.md index 3587bf38e2..8a37f5c2a1 100755 --- a/en/author-guidelines.md +++ b/en/author-guidelines.md @@ -297,13 +297,12 @@ 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). +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. -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. +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. ## The Peer Review Process diff --git a/en/editor-guidelines.md b/en/editor-guidelines.md index 2042e4d369..2ca93bf4df 100755 --- a/en/editor-guidelines.md +++ b/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. ### 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. From 8a42f087b1e1f0d1b7f20035f0587d1a6de7e4ad Mon Sep 17 00:00:00 2001 From: walshbr Date: Wed, 9 Dec 2020 15:32:46 -0500 Subject: [PATCH 02/10] Update --- en/author-guidelines.md | 4 ++-- en/editor-guidelines.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/en/author-guidelines.md b/en/author-guidelines.md index 4246f35384..31b15318dd 100755 --- a/en/author-guidelines.md +++ b/en/author-guidelines.md @@ -299,11 +299,11 @@ Double-check that your lesson file has been prepared to the above specifications 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. +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 diff --git a/en/editor-guidelines.md b/en/editor-guidelines.md index 918f67ea5d..65c08eab44 100755 --- a/en/editor-guidelines.md +++ b/en/editor-guidelines.md @@ -56,7 +56,7 @@ When the lesson materials are ready for submission, the author will contact thei 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. +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. From 24e7594e920ce1427d5a4b267ca902337b1ddc46 Mon Sep 17 00:00:00 2001 From: spapastamkou Date: Sat, 12 Dec 2020 14:59:37 +0100 Subject: [PATCH 03/10] updates FR author, translator and editor guidelines --- fr/consignes-auteurs.md | 71 +++++++++++++++++++------------------ fr/consignes-redacteurs.md | 10 ++++-- fr/consignes-traducteurs.md | 68 ++++++++++++++++++++++------------- 3 files changed, 87 insertions(+), 62 deletions(-) diff --git a/fr/consignes-auteurs.md b/fr/consignes-auteurs.md index 5b0ff8c452..f72c5a1193 100644 --- a/fr/consignes-auteurs.md +++ b/fr/consignes-auteurs.md @@ -27,9 +27,9 @@ Nous acceptons des tutoriels : La portée et la longueur du tutoriel doivent être appropriés à la complexité de la tâche qui y est expliquée. La longueur des tutoriels ne doit pas excéder 8,000 mots (en incluant le code source) à moins que le rédacteur ou la rédactrice n'en ait explicitement donné la permission. Celle-ci sera uniquement accordée dans des circonstances exceptionnelles. Nous demandons que la longueur des leçons soit en général comprise entre 4,000 et 6,000 mots. Les leçons plus longues pourront être divisées en plusieurs tutoriels. -Vous pouvez avoir une meilleure idée de ce que nous publions en consultant nos [leçons publiées], en lisant nos [consignes aux évaluateurs et évaluatrices](/fr/consignes-evaluateurs.html), ainsi qu'aux [traducteurs et traductrices](/fr/consignes-traducteurs), ou encore en parcourant les [leçons en cours de développement](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/lessons). Nous vous encourageons à proposer des leçons sur des sujets déjà traités ou en en cours de développement, à condition que la nouvelle leçon apporte sa propre contribution originale au traitement d'un sujet donné. +Vous pouvez avoir une meilleure idée de ce que nous publions en consultant nos [leçons en ligne](/fr/lecons/), en lisant nos [consignes aux évaluateurs et évaluatrices](/fr/consignes-evaluateurs), ou encore en parcourant les [leçons en cours de développement](https://github.com/programminghistorian/ph-submissions/issues). Il existe en outre des sujets sur lesquels le *Programming Historian en français* est [particulièrement intéressé à recevoir des propositions](/fr/appel-contributions). Nous vous encourageons à proposer des leçons sur des sujets déjà traités ou en en cours de développement, à condition que la nouvelle leçon apporte sa propre contribution originale au traitement d'un sujet donné. -Afin d'assurer la pérennité de nos leçons, les auteur(e)s doivent s'efforcer de soumettre des leçons qui ne sont pas complètement dépendantes de logiciels spécifiques ou d'interfaces utilisateurs. Ces leçons vont à coup sûr souffrir d'instabilité et vont avoir besoin de révisions substantielles lorsque sort une nouvelle version du logiciel ou de l'interface. Enseigner des concepts, plutôt que demander de 'cliquer sur le bouton _x_', facilite la rédaction et la publication de tutoriels pérennes. +Afin d'assurer la pérennité de nos leçons, les auteur(e)s doivent s'efforcer de soumettre des leçons qui ne sont pas complètement dépendantes de logiciels spécifiques ou d'interfaces utilisateurs. Ces leçons vont à coup sûr souffrir d'instabilité et vont avoir besoin de révisions substantielles lorsque sort une nouvelle version du logiciel ou de l'interface. Enseigner des concepts, plutôt que demander de "cliquer sur le bouton _x_", facilite la rédaction et la publication de tutoriels pérennes. Une fois que votre proposition est acceptée, un rédacteur ou une rédactrice va créer un ticket "Proposition" dans notre [dépôt de soumissions](https://github.com/programminghistorian/ph-submissions/issues) avec le titre provisoire de la leçon et les objectifs pédagogiques proposés. Ce ticket sert à signaler le travail en cours alors que vous êtes en train de rédiger votre leçon. Pour éviter d'accumuler les retards, nous vous demandons de soumettre votre leçon dans les 90 jours suivant l'acceptation de votre proposition. @@ -50,7 +50,7 @@ Que vous choisissiez un éditeur de texte ou un autre - cela n'a pas vraiment d' ### Mettre en forme les notes de bas de page Nous vous demandons de bien vouloir utiliser le style [Chicago Manual of Style](https://fr.wikipedia.org/wiki/The_Chicago_Manual_of_Style) pour mettre en forme les notes de bas de page. -### Choisir un nom facile à trouver +### Nommer le fichier Nommez le fichier de votre nouvelle leçon en respectant les conseils suivants : - Utilisez des minuscules et choisissez un nom court mais parlant. Ce nom de fichier deviendra le [slug] de l'URL de la leçon quand elle sera publiée. Par exemple, le titre de la leçon intitulée "Débuter avec Markdown" a le slug suivant : `debuter-avec-markdown` et l'URL : `https://programminghistorian.org/en/lessons/debuter-avec-markdown`. Pensez à regarder des leçons existantes pour plus d'exemples concrets. @@ -92,8 +92,8 @@ Pour créer le bloc YAML pour votre leçon, vous devez **copier et coller le tex **Toutes les nouvelles leçons doivent être écrites en Markdown.** Markdown est un langage de balisage que l'on écrit très facilement avec un éditeur de texte (comme expliqué ci-dessus, n'utilisez pas un traitement de texte comme Word ou Open Office). Les [GitHub Pages] sont générées par [Jekyll](http://jekyllrb.com/), qui convertit automatiquement les fichiers Markdown dans des pages HTML que vous pouvez trouver sur le site Web. Cette page est elle-même écrite en Markdown, comme vous pouvez le voir en regardant [le texte brut sur Github]. Pour une introduction en douceur à Markdown, consultez: -- [Getting Started with Markdown]({{site.baseurl}}/en/lessons/getting-started-with-markdown), un tutoriel du *Programming Historian* écrit par Sarah Simpkin -- ou le guide [GitHub Guide to Markdown]. +- [Débuter avec Markdown]({{site.baseurl}}/fr/lecons/debuter-avec-markdown), un tutoriel du *Programming Historian* écrit par Sarah Simpkin +- ou le [guide de GitHub sur Markdown].
Avant de continuer, assurez vous que vous comprenez comment utiliser la syntaxe Markdown pour du formatage basique comme la mise en valeur des en-têtes, la mise en gras du texte, l'utilisation de l'italique, l'ajout de liens, la mise en forme des paragraphes, et la création de listes. @@ -236,52 +236,52 @@ Online*`). ----- ## Soumettre une nouvelle leçon -Une fois que votre leçon a été préparée en suivant les consignes données ci-dessus, vous êtes prêt(e) à la soumettre ! +Une fois que votre leçon a été préparée en suivant les consignes données ci-dessus, nous vous conseillons de la faire relire et éventuellement d'apporter des corrections pour l'améliorer. Ainsi, l'évaluation ouverte par les pairs que nous allons organiser par la suite pourra se concentrer sur le fond pour vous aider à produire la version la plus solide possible de votre leçon. -Nous avons une [page-projet pour le Programming Historian](https://github.com/programminghistorian) sur GitHub, où nous maintenons deux dépôts (un dépôt ou *repository* est un endroit destiné à stocker les fichiers et les dossiers reliés - on peut les voir comme les dossiers que vous avez sur votre ordinateur). L'un d'entre eux s'appelle [jekyll](https://github.com/programminghistorian/jekyll) et héberge le code source du site visible à cette adresse . L'autre dépôt s'appelle [ph-submissions]. +Lorsque vous êtes prêt(e) à la soumettre, merci d'envoyer tous les fichiers (texte, images, données...) au rédacteur ou à la rédactrice en charge du suivi éditorial de votre leçon, qui les téléversera pour vous dans notre dépôt dédié à l'évaluation par les pairs sur [Github](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/fr/lecons). Voici comment procéder de votre côté: -Nous souhaitons que les auteurs soumettent directement les leçons en les ajoutant au dépôt [ph-submissions]. Grâce aux fonctionnalités offertes par Github, vous pouvez utiliser l'action *glisser-déposer* pour télécharger des fichiers. En tant que nouvel(le) auteur(e), voilà les étapes que vous allez devoir suivre : +1. **Obtenir accès à notre dépôt d'évaluation**: pour cela il suffit de créer un [compte gratuit sur Github](https://github.com/join) et le communiquer à votre rédacteur ou rédactrice, qui va ensuite vous ajouter comme **collaborateur ou collaboratrice** dans le dépôt [ph-submissions]. Ce n'est pas à vous de faire le téléversement initial des fichiers, mais l'accès au dépôt est nécessaire pour que vous puissiez par la suite apporter des modifications et des mises à jour. +2. **Préparer ses fichiers**: vous avez probablement des images qui accompagnent votre leçon. Merci de vérifier que tous les fichiers images sont nommés de manière appropriée, en accord avec les [conventions de nommage spécifiées ci-dessus]. Ces fichiers doivent nous parvenir dans un dossier unique compressé. Si vous avez en plus des fichiers de données, merci de nous envoyer ces fichiers aussi dans un dossier compressé distinct. +3. **Envoyer un message électronique**: informez votre rédacteur ou rédactrice que vous êtes prêt(e) à soumettre votre leçon, en joignant le fichier de celle-ci et, le cas échéant, les dossiers des fichiers images et données. +4. **Participer à la discussion**: le rédacteur ou la rédactrice en charge du suivi éditorial de votre leçon déposera vos fichiers dans notre [dépôt de soumissions](https://github.com/programminghistorian/ph-submissions) en faisant quelques premières modifications si nécessaire (métadonnées, syntaxe Markdown etc). Ensuite, un ticket sera ouvert pour l'évaluation ouverte de votre leçon, pendant laquelle vous avez la possibilité d'échanger avec celles et ceux qui participent au processus. +5. **Apporter des modifications**: si le dépôt initial des fichiers est fait par votre rédacteur ou rédactrice assigné(e), le processus éditorial peut néanmoins entraîner le besoin d'apporter des modifications supplémentaires de votre côté. Toutes les révisions se font directement par les auteur(e)s sur les fichiers versés dans notre dépôt pour avoir la certitude que vous travaillez sur la version la plus récente du fichier de la leçon. -1. Créer un [compte gratuit sur Github](https://github.com/join). Cela prend environ 30 secondes. -2. Envoyer un message à votre rédacteur ou rédactrice avec votre nouveau nom d'utilisateur ou utilisatrice Github et le nom/slug du fichier de votre leçon (assurez vous d'avoir suivi les règles de nommage exposées ci-dessus). Votre rédacteur ou rédactrice va ensuite vous ajouter comme **collaborateur ou collaboratrice** dans le dépôt [ph-submissions]. Vous allez alors pouvoir directement faire des changements dans le dépôt [ph-submissions], comme ajouter, modifier, supprimer ou renommer des fichiers. Le rédacteur ou la rédactrice va également créer un dossier avec le même nom que votre leçon dans le dossier "images". (Si vous avez d'autres types de fichiers de données que vous souhaitez associer à votre tutoriel, parlez en à votre rédacteur ou rédactrice). -3. Une fois informé que vous avez été ajouté(e) en tant que collaborateur ou collaboratrice au dépôt, rendez vous dans le [dossier des leçons](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/lessons) du dépôt [ph-submissions]. Ensuite, faites un glisser-déposer avec votre fichier en Markdown depuis votre ordinateur vers la fenêtre de votre navigateur. (Si vous avez besoin d'aide, consultez les [instructions fournies par Github](https://help.github.com/articles/adding-a-file-to-a-repository/)). Maintenant cliquez sur le bouton vert "Commit Changes" ; vous n'avez pas besoin de changer le message qui s'affiche par défaut. -4. Vous avez probablement des images qui accompagnent votre leçon. Soyez sûr(e) que tous les fichiers images sont nommés de manière appropriée, en accord avec les conventions de nommage spécifiées ci-dessus. Rendez vous dans le [dossier des images](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/images) dans le dépôt [ph-submissions]. Cliquez sur le dossier avec le même nom que votre leçon (que votre rédacteur ou rédactrice a dû créer pour vous ; si vous ne le voyez pas, prenez contact avec la personne et attendez de recevoir ses instructions). Une fois que vous êtes dans le bon dossier, faites un glisser-déposer de tous vos fichiers images de votre ordinateur vers la fenêtre de votre navigateur, comme vous l'avez fait lors de l'étape 3. Vous ne pouvez pas déposer un dossier contenant vos images, mais vous pouvez déposer plusieurs fichiers en une fois. -5. Vous pouvez avoir un aperçu de votre leçon en ligne ! Attendez quelques minutes (voire moins) pour que Github convertisse votre fichier Markdown en HTML et en fasse une page web visible en ligne. Ensuite, rendez vous à l'adresse suivante : `http://programminghistorian.github.io/ph-submissions/lessons/NOM-DE-VOTRE-LEÇON` (mais remplacez NOM-DE-VOTRE-LEÇON par le nom de votre fichier). -6. Faites savoir à votre rédacteur ou votre rédactrice que vous avez téléchargé les fichiers de votre leçon dans le dépôt [ph-submissions]. Même si une notification l'en informant a dû lui être envoyée, nous préférons nous assurer que rien peut être omis. -
-Si vous avez l'habitude d'utiliser git et Github en ligne de commande, vous pouvez également soumettre votre leçon et vos images comme une *pull request* au dépôt `ph-submission` et la fusionner vous-même après y avoir été ajouté en tant que collaborateur(trice). Nous vous demandons de ne pas soumettre des leçons par [pull request] au dépôt principal Jekyll de manière à ce que nous puissions fournir des aperçus en ligne des leçons en cours de relecture. -
+## Le processus de l'évaluation ouverte par les pairs +Une fois que votre rédacteur ou rédactrice assigné(e) aura déposé et formaté vos fichiers de manière appropriée, vous recevrez un lien de prévisualisation de la leçon qui vous permettra de vérifier aussi de votre côté que tout se présente correctement; si ce n'est pas le cas, vous pouvez apporter des corrections. + +L'évaluation par les pairs a lieu dans le cadre d'un [ticket](https://github.com/programminghistorian/ph-submissions/issues) Github qui prend ainsi la forme d'un forum de discussion ouverte. Merci de garder à l'esprit que l'évaluation par les pairs se fait publiquement et elle reste disponible à la consultation publique; le ticket en est l'enregistrement. Si pour quelque raison que ce soit vous n'êtes pas à l'aise ou souhaitez une évaluation par les pairs non publique, merci de prendre contact avec votre rédacteur ou rédactrice assigné(e). + +Le processus de l'évaluation se passe habituellement en trois étapes: + +1) Le rédacteur ou la rédactrice assigné(e) à votre leçon en fait une première lecture attentive en en testant les manipulations proposées. Vous êtes à ce stade susceptible de recevoir un premier retour qui pourrait solliciter votre réponse. L'objectif de ce premier retour est de se garantir la pertinence de votre leçon pour le lectorat du *Programming Historian en français* et qu'elle est fonctionnelle avant d'être proposée à l'évaluation externe. Vous avez normalement un mois pour répondre à cette première évaluation. + +2) Ensuite, votre rédacteur ou rédactrice assigné(e) propose la leçon à l'évaluation formelle par les pairs. Cela implique l'invitation d'au moins deux évaluateurs ou évaluatrices externes, mais potentiellement aussi la participation d'une communauté plus large, car tout commentaire est bienvenu (pourvu que les règles de bonne conduite, explicités dans le ticket, soient observées). En général, nous accordons aux évaluateurs et évaluatrices un délai d'un mois pour fournir leurs commentaires, il peut néanmoins arriver que ce délai ne soit pas respecté pour des raisons indépendantes de la volonté des personnes impliquées au processus. Vous devez attendre l'ensemble des relectures et les instructions consécutives de votre rédacteur our rédactrice assigné(e) avant d'aller plus loin. Parfois il peut s'agir de simples suggestions d'apporter certaines modifications, mais il peut aussi être question de révisions majeures ou de repenser la leçon. Selon les évaluations des pairs et la nature des questions soulevées, il se peut que vous ayez à réviser le tutoriel plus qu'une fois. Toufois, votre rédacteur ou rédactrice assignée(e) veillera à ce que vous receviez une guidance claire pour que la leçon soit publiée. Par ailleurs, il est toujours possible de retirer votre leçon du processus de l'évaluation, si tel est votre choix. -## La leçon a été soumise ! Et maintenant ? -Pour savoir ce qui va arriver à votre leçon après sa soumission, sentez-vous libre de consulter nos [consignes aux évaluateurs et évaluatrices](/fr/consignes-evaluateurs), qui détaillent notre processus de révision et de publication. Vous pouvez retrouver les étapes les plus importantes ci-dessous. +3) Au bout de ce processus, si tous les critères sont remplis, votre rédacteur ou rédactrice assignée(e) donne le feu vert pour la publication. C'est ensuite au rédacteur ou à la rédactrice en chef de relire la leçon pour s'assurer de sa conformité aux consignes aux auteur(e)s et aux standards du *Programming Historian*. Parfois des révisions et des corrections supplémentaires peuvent être nécessaires à ce stade pour que la leçon puisse être publiée. Une fois que le rédacteur ou la rédactrice en chef juge la version révisée satisfaisante, la leçon peut être publiée. Votre rédacteur ou rédactrice assigné(e) vous fournira toute information nécessaire à ce stade. -L'étape la plus immédiate consiste en la création par votre rédacteur ou rédactrice d'un [ticket](https://github.com/programminghistorian/ph-submissions/issues) pour la leçon téléchargée dans le dépôt [ph-submissions], contenant un lien vers celle-ci (dont vous avez pu avoir un aperçu lors de l'étape 5). Le rédacteur ou la rédactrice et au moins deux personnes chargées de l'évaluation sur son invitation vont poster leurs commentaires pour cette "issue". +Il serait utile de consulter nos [consignes aux évaluateurs et évaluatrices](/fr/consignes-evaluateurs) qui détaillent notre processus de révision et de publication. -### Attendre les commentaires d'évaluation -Nous essayons de finaliser le processus de relecture dans un délai de quatre semaines ; mais il peut parfois arriver que nous prenions du retard, ou que les personnes impliquées dans le processus de relecture soient très occupées, et cela peut prendre plus de temps que prévu. +Si jamais vous êtes dans l'incertitude sur comment procéder, n'hésitez pas à poster votre question sur le ticket d'évaluation, un membre de notre équipe vous apportera des réponses dans les délais les plus brefs possible. Nous faisons de notre mieux pour répondre au bout de quelques jours. -Afin de promouvoir l'évaluation ouverte par les pairs et le développement d'un environnement académique ouvert, nous encourageons les discussions à rester sur Github. Toutefois, nous souhaitons également que vous vous sentiez à l'aise avec le processus de relecture ; sentez vous libre d'[envoyer directement un message à votre rédacteur ou rédactrice](/fr/equipe-projet), ou de contacter notre médiatrice, [Hélène Huet](/fr/equipe-projet). +### Nous interpeller +Notre équipe de bénévoles fait de son possible pour se garantir l'évaluation rigoureuse, collégiale et efficace des auteur(e)s par les pairs. Toutefois, il peut y avoir des failles, c'est pourquoi nous souhaitons que les auteur(e)s nous aident à maintenir un haut niveau de service. Si, pour quelque raison que ce soit, vous estimez ne pas avoir été traité(e) correctement, ou ne comprenez pas trop quel est votre rôle ou ce qu’on attend de vous, ou encore vous considérez que l'évaluation présente des retards injustifiés ou que quelqu'un a été rude avec vous, enfin, pour quelque souci que ce soit, n'hésitez pas à nous en tenir informés afin de pouvoir agir. -### Répondre aux commentaires -Les personnes chargées du suivi éditorial et de l'évaluation vont très probablement vous suggérer des modifications sur le ticket concernant votre leçon. Le rédacteur ou la rédactrice vous dira clairement quelles sont les modifications indispensables, quelles sont les modifications optionnelles et lesquelles peuvent être mises de côté. +Exprimer des réserves n'a AUCUN impact négatif sur le processus et le résultat de l'évaluation par les pairs. -Vous pouvez modifier vos fichiers sur Github, en suivant [ces instructions](https://help.github.com/articles/editing-files-in-your-repository/). +Pour ce faire, vous avez plusieurs points d'entrée et sentez-vous libre de contacter la personne avec laquelle vous êtes le plus à l'aise: -Vos révisions doivent être finalisées sous 4 semaines après avoir reçu les consignes de votre rédacteur ou rédactrice concernant les réponses à donner à la suite de l'évaluation par les pairs. Il s'agit de s'assurer ainsi que les leçons sont publiées dans un délai convenable et ne prennent pas du retard inutilement. Si vous pensez que vous allez avoir des difficultés à respecter ce délai, vous devez contacter votre rédacteur ou rédactrice pour choisir une date plus appropriée. +* votre rédacteur ou rédactrice assigné(e); +* le rédacteur ou la rédactrice en chef; +* notre médiatrice indépendante ([Dr Hélène Huet](mailto:hhuet@ufl.edu). -Si, à n'importe quel moment, vous n'êtes pas sûr(e) de votre rôle ou de ce que l'on attend de vous, sentez vous libre d'envoyer un message à votre rédacteur/rédactrice ou, encore mieux, de poster votre question sur l'issue concernant votre leçon. Un autre membre de l'équipe de rédaction peut la voir et vous répondre à la place de votre rédacteur/rédactrice. Vous devez comprendre que nous pouvons prendre quelques jours pour vous répondre, mais nous espérons que les améliorations apportées à votre texte sauront récompenser votre patience. +Nous oeuvrons pour que tout se passe au mieux pour vous, mais si jamais vous estimez vous trouver dans une situation peu confortable, nous vous remercions de nous aider à y remédier et à améliorer les choses. -### Faire savoir à votre rédacteur ou rédactrice que vous avez terminé -Une fois que vous avez terminé de répondre aux commentaires, faites le savoir à votre rédacteur ou rédactrice. Si vous ne l'avez pas déjà fait, envoyez 2 ou 3 lignes de biographie, qui apparaîtront à la fin de votre leçon, suivant ainsi le modèle des autres leçons. -Ensuite, le comité éditorial du *Programming Historian en français* va rapidement relire votre leçon et la déplacer du dépôt `ph-submissions` vers le dépôt `jekyll`, et mettre à jour notre répertoire des leçons. -Félicitations ! Vous avez publié une leçon pour le *Programming Historian en français*! - [page wiki des leçons en cours de développement]: https://github.com/programminghistorian/jekyll/wiki/Lesson-Pipeline [consignes aux évaluateurs et évaluatrices]: /fr/consignes-evaluateurs.html [leçons publiées]: /fr/lecons [TextWrangler]: http://www.barebones.com/products/textwrangler/ @@ -289,7 +289,7 @@ Félicitations ! Vous avez publié une leçon pour le *Programming Historian en [équipe-projet]: /fr/equipe-projet.html [slug]: https://en.wikipedia.org/wiki/Semantic_URL#Slug [YAML]: https://fr.wikipedia.org/wiki/YAML - [Guide GitHub pour Markdown]: https://guides.github.com/features/mastering-markdown/ + [guide de GitHub sur Markdown]: https://guides.github.com/features/mastering-markdown/ [les bases de Markdown]: https://help.github.com/articles/markdown-basics [Github Flavored Markdown]: https://help.github.com/articles/github-flavored-markdown [le texte brut sur Github]: https://raw.githubusercontent.com/programminghistorian/jekyll/gh-pages/en/author-guidelines.md @@ -303,7 +303,7 @@ Félicitations ! Vous avez publié une leçon pour le *Programming Historian en [GitHub pour Mac]: https://mac.github.com/ [GitHub pour Windows]: https://windows.github.com/ [créer un compte sur Github]: https://help.github.com/articles/signing-up-for-a-new-github-account/ - [conventions de nommage décrites ci-dessus]: #choisissez-le-nom-de-vos-fichiers + [conventions de nommage spécifiées ci-dessus]: #nommer-le-fichier [pull requests en attente dans notre dépôt]: https://github.com/programminghistorian/jekyll/pulls [guides GitHub]: https://guides.github.com/activities/forking/ [réaliser un fork]: https://help.github.com/articles/fork-a-repo/ @@ -313,4 +313,5 @@ Félicitations ! Vous avez publié une leçon pour le *Programming Historian en [ph-submissions]: https://github.com/programminghistorian/ph-submissions {% comment %}Anchor in line 306: Needs to be checked for: a) slug: does not seem to correspond to a subtitle, in the text there is only "Utilisez des noms de fichiers compréhensibles" b) where it is/will be inserted in the text{% endcomment %} + {% comment %}Hopefully resolved after some changes. Sofia, 12/12/20{% endcomment %} diff --git a/fr/consignes-redacteurs.md b/fr/consignes-redacteurs.md index 65272bbe0b..5fb404fed5 100644 --- a/fr/consignes-redacteurs.md +++ b/fr/consignes-redacteurs.md @@ -43,12 +43,18 @@ Le principal contact éditorial pour cette leçon est [NOM D'UTILISATEUR/UTILISA ``` Le rédacteur ou la rédactrice peut adapter le texte du ticket de proposition en fonction d'éventuels objectifs supplémentaires ou de prérequis agréés avec l'auteur(e) ou les auteur(e)s. -Après qu'une leçon a été déposée, le rédacteur ou la rédactrice doit créer un ticket d'évaluation en fermant celui de la proposition. +Lorsque les fichiers de la leçon (texte et, le cas échéant, images et données) sont prêts à être soumis, l'auteur(e) contacte le rédacteur ou la rédactrice assigné(e) qui les téléversera dans notre dépôt dédié à l'évaluation par les pairs sur [Github](https://github.com/programminghistorian/ph-submissions), après avoir vérifié la qualité des métadonnées. + +1. **Téléverser la leçon (ou la traduction)**: le fichier de la leçon doit être téléversé dans le [sous-répertoire des leçons](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/fr/lecons); s'il s'agit d'une traduction, le fichier est téléversé dans le [sous-répertoire des traductions](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/fr/traductions). Si vous avez besoin d'aide, merci de consulter la [documentation de Github](https://help.github.com/articles/adding-a-file-to-a-repository/). +2. **Téléverser des images**: si des images accompagnent la leçon (ou la traduction), assurez-vous que le nommage des fichiers est conforme aux règles spécifiées dans les [consignes aux auteur(e)s](/consignes-auteurs). C'est au rédacteur ou à la rédactrice - vous!- de créer un sous-répertoire spécifique aux images de la leçon dans le [répertoire des images](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/images). Ce sous-répertoire doit être nommé exactement de la même manière que le fichier de la leçon. Téléversez ensuite les fichiers images dans ce sous-répertoire. +3. **Téléverser des données**: si la leçon est accompagnée de fichiers de données, ces fichiers doivent être téléversés dans un sous-répertoire créé dans le [répertoire ```assets```](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/assets) et nommé exactement de la même manière que le fichier de la leçon. + +Après le téléversement, le rédacteur ou la rédactrice assigné(e) doit vérifier [l'historique des contributions (*commits*) au dépôt](https://github.com/programminghistorian/ph-submissions/commits/gh-pages) pour vérifier que le téléversement a bien réussi. Si ce n'est pas le cas, merci de consulter le [wiki](https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions#checking-travis-for-errors) pour détecter l'erreur et résoudre le problème. Lorsque la soumission de la leçon (ou de la treduction) aura été achevée, le rédacteur ou la rédactrice assigné(e) crée un ticket d'évaluation en fermant celui de la proposition. À partir de cette étape, votre rôle implique aussi de veiller à ce que l'auteur(e) (ou le traducteur) travaille sur cette version de la leçon (ou de la traduction) et contribue directement ses modifications au dépôt Github. ### Évaluation ouverte par les pairs Le *Programming Historian en français* pratique l'évaluation ouverte par les pairs. Si notre conviction est bien que ce système garantit la qualité des rapports et le partage productif des idées, les auteurs ont toutefois le droit, que nous devons respecter, de solliciter une procédure fermée d'évaluation par les pairs. Une personne peut être réservée vis-à-vis d'une évaluation ouverte pour plusieurs raisons et, de notre côté, nous encourageons les auteur(e)s à choisir l'option qui leur convient le mieux. -Avant de solliciter des évaluations externes, le rédacteur ou la rédactrice doit lire et tester le tutoriel, en profitant de l'expérience acquise dans le cadre du *Programming Historian en français* pour aider l'auteur(e) à apporter des améliorations, si nécessaire. __Le rédacteur ou la rédactrice passe au crible le caractère durable du dépôt pour vérifier si les versions des logiciels et des dépendances sont clairement mentionnées, mais aussi que les exigences spécifiques du logiciel, tout comme les captures d'écran se limitent à ce qui est nécessaire pour compléter la leçon. Il/elle veille, enfin, à ce que la leçon mobilise la documentation des logiciels lorsque celle-ci est disponible et pertinente.__ Les rédacteurs et rédactrices doivent aussi s'assurer que les leçons s'abstiennent autant que possible de fournir des instructions spécifiques comme "faire un clic droit sur l'icône _x_ pour accéder au menu _x_," et qu'ils offrent, en revanche, des aperçus méthodologiques plus larges. La liste de vérification éditoriale [offre plus de détails sur les pratiques de pérennisation](#c-sustainability-review) pour le PH. +Avant de solliciter des évaluations externes, le rédacteur ou la rédactrice doit lire et tester le tutoriel, en profitant de l'expérience acquise dans le cadre du *Programming Historian en français* pour aider l'auteur(e) à apporter des améliorations, si nécessaire. __Le rédacteur ou la rédactrice passe au crible le caractère durable du dépôt pour vérifier si les versions des logiciels et des dépendances sont clairement mentionnées, mais aussi que les exigences spécifiques du logiciel, tout comme les captures d'écran se limitent à ce qui est nécessaire pour compléter la leçon. Il/elle veille, enfin, à ce que la leçon mobilise la documentation des logiciels lorsque celle-ci est disponible et pertinente.__ Les rédacteurs et rédactrices doivent aussi s'assurer que les leçons s'abstiennent autant que possible de fournir des instructions spécifiques comme "faire un clic droit sur l'icône _x_ pour accéder au menu _x_," et qu'ils offrent, en revanche, des aperçus méthodologiques plus larges. La liste de vérification éditoriale [offre plus de détails sur les pratiques de pérennisation](#questions-techniques-de-lévaluation---liste-de-vérification-éditoriale) pour le PH. Souvent, les rédacteurs et les rédactrices doivent apporter leur concours pour identifier les publics ciblés par une leçon, ou encore pour décrypter un jargon technique qui nécessite d'être clarifié. Cette relecture initiale permet aux évaluateurs et évaluatrices externes de se concentrer à l'amélioration du reste de la leçon. D'habitude, cela se fait de manière transparente dans le cadre de notre système de soumissions (voir ci-dessous), mais l'évaluation peut aussi être privée sur demande des parties intéressées. diff --git a/fr/consignes-traducteurs.md b/fr/consignes-traducteurs.md index f7e3c3c096..3199dc75d7 100644 --- a/fr/consignes-traducteurs.md +++ b/fr/consignes-traducteurs.md @@ -29,41 +29,59 @@ Quand vous traduisez une leçon, veuillez tenir compte du fait que vous vous adr Veuillez aussi noter que toutes nos leçons doivent être rédigées en format Markdown et obéir à nos consignes techniques de mise en page, que vous pourrez également consulter dans nos [consignes aux auteurs]({{site.baseurl}}/fr/consignes-auteurs). ## Soumettre la leçon traduite -Lorsque le fichier contenant votre traduction a été préparé en suivant les spécifications ci-haut, il est temps de le soumettre à la révision par les pairs. +Une fois que votre traduction a été préparée en suivant les consignes données ci-dessus, il est temps d'organiser l'évaluation par les pairs. -La [page de projet du Programming Historian sur GitHub](https://github.com/programminghistorian) contient deux dépôts (un dépôt est un endroit où l'on entrepose des fichiers et des répertoires apparentés; un répertoire-racine, en quelque sorte). L'un de ces dépôts, nommé [jekyll], héberge le code de la version active du site que vous pouvez visiter au http://programminghistorian.org. L'autre dépôt se nomme [ph-submissions]. +Lorsque vous êtes prêt(e) à soumettre votre traduction, merci d'envoyer tous les fichiers (texte, images, données...) au rédacteur ou à la rédactrice en charge du suivi éditorial de celle-ci, qui les téléversera pour vous dans notre dépôt dédié à l'évaluation par les pairs sur [Github](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/fr/traductions). Voici comment procéder de votre côté: -Nous préférons que les traducteurs et les traductrices soumettent les leçons en les ajoutant directement au dépôt [ph-submissions]. GitHub vous permet de le faire en téléversant vos fichiers à l'aide d'actions glisser-déposer avec lesquelles vous êtes probablement déjà à l'aise. En tant que nouveau traducteur ou nouvelle traductrice, voici les étapes à suivre: +1. **Obtenir accès à notre dépôt d'évaluation**: pour cela il suffit de créer un [compte gratuit sur Github](https://github.com/join) et le communiquer à votre rédacteur ou rédactrice, qui va ensuite vous ajouter comme **collaborateur ou collaboratrice** dans le dépôt [ph-submissions](https://github.com/programminghistorian/ph-submissions). Ce n'est pas à vous de faire le téléversement initial des fichiers, mais l'accès au dépôt est nécessaire pour que vous puissiez par la suite apporter des modifications et des mises à jour. +2. **Préparer ses fichiers**: vous avez probablement des images qui accompagnent votre leçon (si, par exemple, vous avez produit des images d'interfaces en français etc). Merci de vérifier que tous les fichiers images sont nommés de manière appropriée, en accord avec les conventions de nommage spécifiées dans les consignes aux auteur(e)s. Ces fichiers doivent nous parvenir dans un dossier unique compressé. Si vous avez en plus des fichiers de données, merci de nous envoyer ces fichiers aussi dans un dossier compressé distinct. +3. **Envoyer un message électronique**: informez votre rédacteur ou rédactrice que vous êtes prêt(e) à soumettre votre traduction, en joignant le fichier de celle-ci et, le cas échéant, les dossiers des fichiers images et données. +4. **Participer à la discussion**: le rédacteur ou la rédactrice en charge du suivi éditorial de votre traduction déposera vos fichiers dans notre [dépôt de soumissions](https://github.com/programminghistorian/ph-submissions) en faisant quelques premières modifications si nécessaire (métadonnées, syntaxe Markdown etc). Ensuite, un ticket sera ouvert pour l'évaluation ouverte de votre traduction, pendant laquelle vous avez la possibilité d'échanger avec celles et ceux qui participent au processus. +5. **Apporter des modifications**: si le dépôt initial des fichiers est fait par votre rédacteur ou rédactrice assigné(e), le processus de la relecture peut néanmoins entraîner le besoin d'apporter des modifications supplémentaires de votre côté. Toutes les révisions se font directement par les traducteurs sur les fichiers versés dans notre dépôt pour avoir la certitude que vous travaillez sur la version la plus récente du fichier de la traduction. -1. Créez un [compte GitHub gratuit](https://github.com/join). Cela ne vous prendra pas plus de 30 secondes. -2. Envoyez à votre rédacteur ou à votre rédactrice un courriel contenant votre nom d'usager GitHub et le nom du fichier contenant votre traduction. Le rédacteur ou la rédactrice vous ajoutera ensuite à la liste des **collaborateurs** du dépôt [ph-submissions]. Une fois que vous aurez été ajouté(e) à la liste des collaborateurs, vous pourrez effectuer vous-même des changements au dépôt [ph-submissions], notamment y ajouter des fichiers, les modifer, les effacer ou les renommer. Le rédacteur ou la rédactrice créera aussi un sous-répertoire qui portera le même nom que votre leçon dans le répertoire des images. (Si votre leçon inclut des liens vers d'autres fichiers de données, demandez des instructions spécifiques à votre rédacteur ou à votre rédactrice.) -3. Une fois que vous êtes inscrit(e) à la liste des collaborateurs, naviguez jusqu'au répertoire des [traductions en français](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/fr/traductions) du dépôt [ph-submissions]. Puis, glissez et déposez le fichier Markdown contenant votre leçon traduite dans la fenêtre de votre navigateur Web. (Si vous avez besoin d'aide, vous pouvez consulter [le manuel de GitHub (en anglais)](https://help.github.com/articles/adding-a-file-to-a-repository/)). Puis, cliquez sur le bouton vert "Commit Changes"; il n'est pas nécessaire de changer le message par défaut qui vous est proposé. -4. Vous disposez peut-être d'images associées au texte de votre leçon. Assurez-vous que tous les fichiers contenant ces images sont nommés correctement, en fonction de nos normes de nomenclature. Puis, naviguez vers le [répertoire des images](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/images) sur le dépôt [ph-submissions]. Cliquez sur le répertoire qui porte le même nom que votre leçon (votre rédacteur ou votre rédactrice devrait l'avoir créé pour vous; si vous ne le voyez pas, communiquez avec votre rédacteur ou votre rédactrice et attendez ses instructions). Lorsque vous avez atteint le bon répertoire, glissez et déposez tous les fichiers contenant vos images dans la fenêtre de votre navigateur Web, comme à l'étape 3. Notez que vous pourrez déposer plusieurs fichiers d'un seul coup si vous le désirez mais qu'il ne sera pas possible de déposer un *répertoire* contenant vos fichiers d'images. -5. Consultez l'aperçu de votre leçon! Attendez quelques minutes (souvent moins) pour que GitHub ait le temps de convertir votre fichier Markdown en HTML et d'en faire une page Web accessible. Puis, naviguez vers `http://programminghistorian.github.io/ph-submissions/lessons/` + `VOTRE-LECON` (mais remplacez VOTRE-LECON par le nom de votre fichier). -6. Prévenez votre rédacteur ou votre rédactrice du téléversement des fichiers de votre leçon sur le dépôt [ph-submissions]. (Il ou elle devrait normalement recevoir une notification automatique mais nous préférons nous assurer que votre dépôt ne passera pas inaperçu.) +## Le processus de l'évaluation ouverte par les pairs +Une fois que votre rédacteur ou rédactrice assigné(e) aura déposé et formaté vos fichiers de manière appropriée, vous recevrez un lien de prévisualisation de la leçon qui vous permettra de vérifier aussi de votre côté que tout se présente correctement; si ce n'est pas le cas, vous pouvez apporter des corrections. -
- Si vous êtes déjà à l'aise avec GitHub et avec la version de git accessible par la ligne de commande de votre système d'exploitation, vous pouvez aussi soumettre votre traduction et les images qui l'accompagnent à l'aide d'une 'pull request' vers le dépôt `ph-submission`, puis fusionner celle-ci avec le dépôt principal lorsque vous ferez partie de la liste des collaborateurs. Veuillez ne pas soumettre de leçons par 'pull request' au dépôt`jekyll` pour que nous puissions offrir des aperçus visibles des leçons en cours de développement. -
+La relecture de votre traduction a lieu dans le cadre d'un [ticket](https://github.com/programminghistorian/ph-submissions/issues) Github qui prend ainsi la forme d'un forum de discussion ouverte. Merci de garder à l'esprit que l'évaluation par les pairs se fait publiquement et elle reste disponible à la consultation publique; le ticket en est l'enregistrement. Si pour quelque raison que ce soit vous n'êtes pas à l'aise ou souhaitez une évaluation par les pairs non publique, merci de prendre contact avec votre rédacteur ou rédactrice assigné(e). -### Traduction soumise! Et maintenant? -Pour savoir ce qui se passera après que vous ayez soumis votre traduction, n'hésitez pas à consulter nos [consignes aux rédacteurs et aux rédactrices](https://programminghistorian.org/fr/consignes-redacteurs) qui décrivent notre processus éditorial en détail. En voici les grandes lignes. +Concernant les traductions, l'évaluation doit être comprise comme relecture critique dont l'objectif est de se garantir la pertinence du texte pour un lectorat francophone. L'évaluation ouverte par les pairs du contenu de la leçon a, quant à elle, déjà eu lieu avant la publication dans la langue originale. Nous appliquons néanmoins les mêmes principes de base pour les relectures des traductions que pour le processus de l'évaluation ouverte par les pairs. -L'étape la plus importante à court terme est la création d'un [ticket](https://github.com/programminghistorian/ph-submissions/issues) pour la nouvelle traduction dans le dépôt [ph-submissions], où l'on retrouvera notamment un lien vers l'aperçu de votre leçon que vous avez consulté à l'étape 5. Le rédacteur ou la rédactrice et au moins deux évaluateurs ou évaluatrices (invité(e)s par le rédacteur ou la rédactrice) publieront leurs commentaires au sujet de votre traduction sur ce ticket. +Le processus de l'évaluation se passe habituellement en trois étapes: -### En attendant les retours des relectures -Nous tentons de compléter le processus de relecture en quatre semaines ou moins, mais il est possible que des délais imprévus ou un emploi du temps chargé entraînent des retards. +1) Le rédacteur ou la rédactrice assigné(e) à votre traduction en fait une première lecture attentive. Vous êtes à ce stade susceptible de recevoir un premier retour qui pourrait solliciter votre réponse. L'objectif de ce premier retour est de se garantir la pertinence de votre traduction pour le lectorat du *Programming Historian en français* et qu'elle est fonctionnelle avant d'être proposée à l'évaluation externe ou interne. Vous avez normalement un mois pour répondre à cette première évaluation. -En accord avec les principes de la recherche publique et de l'évaluation ouverte par les pairs, nous souhaitons que la discussion demeure sur GitHub. Cependant, nous voulons aussi que tous les intervenants soient à l'aise avec le processus. Si vous ressentez le besoin de discuter d'un enjeu en privé, n'hésitez pas à contacter directement [votre rédacteur ou votre rédactrice par courriel](/project-team) ou à faire appel à notre médiatrice francophone [Hélène Huet](/project-team). +2) Ensuite, votre rédacteur ou rédactrice assigné(e) propose la leçon à l'évaluation formelle par les pairs. Cela implique l'invitation d'un ou deux évaluateurs ou évaluatrices externes ou internes, mais potentiellement aussi la participation d'une communauté plus large, car tout commentaire est bienvenu (pourvu que les règles de bonne conduite, explicités dans le ticket, soient observées). En général, nous accordons aux évaluateurs et évaluatrices un délai d'un mois pour fournir leurs commentaires, il peut néanmoins arriver que ce délai ne soit pas respecté pour des raisons indépendantes de la volonté des personnes impliquées au processus. Vous devez attendre l'ensemble des relectures et les instructions consécutives de votre rédacteur our rédactrice assigné(e) avant d'aller plus loin. Le plus souvent il s'agit de simples suggestions d'apporter certaines modifications. Afin d'assurer une publication rapide de votre traduction, nous demandons que vous produisiez une version révisée quatre semaines après la réception des instructions, mais le délai peut être revu si vous avez du mal à le respecter. Selon les commentaires et la nature des questions soulevées, il se peut que vous ayez à réviser le tutoriel plus qu'une fois. Toufois, votre rédacteur ou rédactrice assignée(e) veillera à ce que vous receviez une guidance claire pour que la traduction soit publiée. Par ailleurs, il est toujours possible de retirer votre traduction du processus de l'évaluation, si tel est votre choix. -### Répondre aux relectures reçues -Le rédacteur ou la rédactrice qui assure le suivi éditorial de votre traduction et les évaluateurs et évaluatrices recommanderont fort probablement des améliorations à apporter à votre texte dans le "ticket" qui lui est associé. Le rédacteur ou la rédactrice devrait spécifier clairement quelles améliorations sont essentielles, lesquelles sont optionnelles et lesquelles peuvent être mises de côté. +3) Au bout de ce processus, si tous les critères sont remplis, votre rédacteur ou rédactrice assignée(e) donne le feu vert pour la publication. C'est ensuite au rédacteur ou à la rédactrice en chef de relire la traduction pour s'assurer de sa conformité aux consignes aux traducteurs et traductrices et aux standards du *Programming Historian*. Parfois des révisions et des corrections supplémentaires peuvent être nécessaires à ce stade pour que la traduction puisse être publiée. Une fois que le rédacteur ou la rédactrice en chef juge la version révisée satisfaisante, la traduction peut être publiée. Votre rédacteur ou rédactrice assigné(e) vous fournira toute information nécessaire à ce stade. -Vous pouvez modifier vos fichiers directement sur GitHub en suivant [ces instructions (en anglais)](https://help.github.com/articles/editing-files-in-your-repository/). +Il serait utile de consulter nos [consignes aux évaluateurs et évaluatrices](/fr/consignes-evaluateurs) qui détaillent notre processus de révision et de publication. -Afin d'assurer une publication rapide de votre traduction, nous demandons que vous produisiez une version révisée 4 semaines après la réception des instructions de votre rédacteur ou de votre rédactrice. Si vous prévoyez avoir du mal à respecter ce délai, veuillez contacter votre rédacteur ou votre rédactrice pour fixer une date plus appropriée. +Si jamais vous êtes dans l'incertitude sur comment procéder, n'hésitez pas à poster votre question sur le ticket d'évaluation, un membre de notre équipe vous apportera des réponses dans les délais les plus brefs possible. Nous faisons de notre mieux pour répondre au bout de quelques jours. -Si, à quelque moment que ce soit, vous doutez de votre rôle ou de la procédure à suivre, n'hésitez pas à contacter votre rédacteur ou votre rédactrice par courriel ou, mieux encore, à publier une question sur le ticket de relecture de votre leçon (un autre membre de notre équipe éditoriale pourrait voir la question et être en mesure de vous répondre plus rapidement que votre rédacteur ou votre rédactrice). Vous comprendrez qu'il faut parfois quelques jours pour obtenir une réponse, mais nous espérons que la qualité des ajustements apportés à la version finale de votre traduction en vaudra la peine. +### Demandez nous des comptes -### Informer le rédacteur ou la rédactrice qui assure le suivi éditorial que vous avez fini -Lorsque vous aurez terminé de répondre aux recommandations issues de l'évaluation, prévenez votre rédacteur ou votre rédactrice. Si la traduction est jugée satisfaisante, le rédacteur ou la rédactrice en chef du *Programming Historian en français* effectuera une dernière lecture, déplacera les fichiers du dépôt `ph-submissions` vers le dépôt `jekyll` et mettra à jour notre répertoire des leçons. À ce moment, votre traduction sera publiée. +Notre équipe de bénévoles fait de son possible pour se garantir l'évaluation rigoureuse, collégiale et efficace des auteur(e)s par les pairs. Toutefois, il peut y avoir des failles, c'est pourquoi nous souhaitons que les auteur(e)s nous aident à maintenir un haut niveau de service. Si, pour quelque raison que ce soit, vous estimez ne pas avoir été traité(e) correctement, ou ne comprenez pas trop quel est votre rôle ou ce qu’on attend de vous, ou encore vous considérez que l'évaluation présente des retards injustifiés ou que quelqu'un a été rude avec vous, enfin, pour quelque souci que ce soit, n'hésitez pas à nous en tenir informés afin de pouvoir agir. + +Exprimer des réserves n'a AUCUN impact négatif sur le processus et le résultat de l'évaluation par les pairs. + +Pour ce faire, vous avez plusieurs points d'entrée et sentez-vous libre de contacter la personne avec laquelle vous êtes le plus à l'aise: + +* votre rédacteur ou rédactrice assigné(e); +* le rédacteur ou la rédactrice en chef; +* notre médiatrice indépendante ([Dr Hélène Huet](mailto:hhuet@ufl.edu). + +Nous oeuvrons pour que tout se passe au mieux pour vous, mais si jamais vous estimez vous trouver dans une situation peu confortable, nous vous remercions de nous aider à y remédier et à améliorer les choses. + +### Nous interpeller + +Notre équipe de bénévoles fait de son possible pour se garantir l'évaluation rigoureuse, collégiale et efficace des traductions par les pairs. Toutefois, il peut y avoir des failles, c'est pourquoi nous souhaitons que vous nous aidiez à maintenir un haut niveau de service. Si, pour quelque raison que ce soit, vous estimez ne pas avoir été traité(e) correctement, ou ne comprenez pas trop quel est votre rôle ou ce qu’on attend de vous, ou encore vous considérez que l'évaluation présente des retards injustifiés ou que quelqu'un a été rude avec vous, enfin, pour quelque souci que ce soit, n'hésitez pas à nous en tenir informés afin de pouvoir agir. + +Exprimer des réserves n'a AUCUN impact négatif sur le processus et le résultat de l'évaluation par les pairs. + +Pour ce faire, vous avez plusieurs points d'entrée et sentez-vous libre de contacter la personne avec laquelle vous êtes le plus à l'aise: + +* votre rédacteur ou rédactrice assigné(e); +* le rédacteur ou la rédactrice en chef; +* notre médiatrice indépendante ([Dr Hélène Huet](mailto:hhuet@ufl.edu). + +Nous oeuvrons pour que tout se passe au mieux pour vous, mais si jamais vous estimez vous trouver dans une situation peu confortable, nous vous remercions de nous aider à y remédier et à améliorer les choses. From 7dcf7f1e411b3fcc9cefe3185d48361426e6a495 Mon Sep 17 00:00:00 2001 From: spapastamkou Date: Sat, 12 Dec 2020 15:17:04 +0100 Subject: [PATCH 04/10] updates internal link --- fr/consignes-redacteurs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr/consignes-redacteurs.md b/fr/consignes-redacteurs.md index 5fb404fed5..3b7f4b6d1f 100644 --- a/fr/consignes-redacteurs.md +++ b/fr/consignes-redacteurs.md @@ -46,7 +46,7 @@ Le rédacteur ou la rédactrice peut adapter le texte du ticket de proposition e Lorsque les fichiers de la leçon (texte et, le cas échéant, images et données) sont prêts à être soumis, l'auteur(e) contacte le rédacteur ou la rédactrice assigné(e) qui les téléversera dans notre dépôt dédié à l'évaluation par les pairs sur [Github](https://github.com/programminghistorian/ph-submissions), après avoir vérifié la qualité des métadonnées. 1. **Téléverser la leçon (ou la traduction)**: le fichier de la leçon doit être téléversé dans le [sous-répertoire des leçons](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/fr/lecons); s'il s'agit d'une traduction, le fichier est téléversé dans le [sous-répertoire des traductions](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/fr/traductions). Si vous avez besoin d'aide, merci de consulter la [documentation de Github](https://help.github.com/articles/adding-a-file-to-a-repository/). -2. **Téléverser des images**: si des images accompagnent la leçon (ou la traduction), assurez-vous que le nommage des fichiers est conforme aux règles spécifiées dans les [consignes aux auteur(e)s](/consignes-auteurs). C'est au rédacteur ou à la rédactrice - vous!- de créer un sous-répertoire spécifique aux images de la leçon dans le [répertoire des images](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/images). Ce sous-répertoire doit être nommé exactement de la même manière que le fichier de la leçon. Téléversez ensuite les fichiers images dans ce sous-répertoire. +2. **Téléverser des images**: si des images accompagnent la leçon (ou la traduction), assurez-vous que le nommage des fichiers est conforme aux règles spécifiées dans les [consignes aux auteur(e)s](/fr/consignes-auteurs). C'est au rédacteur ou à la rédactrice - vous!- de créer un sous-répertoire spécifique aux images de la leçon dans le [répertoire des images](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/images). Ce sous-répertoire doit être nommé exactement de la même manière que le fichier de la leçon. Téléversez ensuite les fichiers images dans ce sous-répertoire. 3. **Téléverser des données**: si la leçon est accompagnée de fichiers de données, ces fichiers doivent être téléversés dans un sous-répertoire créé dans le [répertoire ```assets```](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/assets) et nommé exactement de la même manière que le fichier de la leçon. Après le téléversement, le rédacteur ou la rédactrice assigné(e) doit vérifier [l'historique des contributions (*commits*) au dépôt](https://github.com/programminghistorian/ph-submissions/commits/gh-pages) pour vérifier que le téléversement a bien réussi. Si ce n'est pas le cas, merci de consulter le [wiki](https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions#checking-travis-for-errors) pour détecter l'erreur et résoudre le problème. Lorsque la soumission de la leçon (ou de la treduction) aura été achevée, le rédacteur ou la rédactrice assigné(e) crée un ticket d'évaluation en fermant celui de la proposition. À partir de cette étape, votre rôle implique aussi de veiller à ce que l'auteur(e) (ou le traducteur) travaille sur cette version de la leçon (ou de la traduction) et contribue directement ses modifications au dépôt Github. From a8de9612f673472f5fe5f82537e654c23435427b Mon Sep 17 00:00:00 2001 From: Daniel Alves <62759376+DanielAlvesLABDH@users.noreply.github.com> Date: Sat, 12 Dec 2020 14:52:11 +0000 Subject: [PATCH 05/10] Update directrizes-autor.md #1844 --- pt/directrizes-autor.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/pt/directrizes-autor.md b/pt/directrizes-autor.md index ec2173e24a..5893355efe 100755 --- a/pt/directrizes-autor.md +++ b/pt/directrizes-autor.md @@ -275,14 +275,13 @@ Recomendamos estas práticas ao escrever o código: Verificar se o ficheiro da lição está de acordo com as especificações acima. Quando terminado, é altamente recomendável pedir a pelo menos duas pessoas para ler a lição e experimentar o tutorial, para dar feedback e garantir que é entendido por todos. Desta maneira ajuda os revisores a concentrarem-se em produzir uma lição tão consistente quanto possível. -Se a lição está pronta a submeter, segue-se a revisão por pares. As submissões são feitas no site de revisão por pares no [Github](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/lessons). - -1. **Acesso ao GitHub**: criar uma [conta gratuita](https://github.com/join). Envie o seu nome de usuário ao editor, que lhe dará acesso ao nosso repositório. Informar o editor do nome do ficheiro da lição e se possui imagens ou ficheiros de dados que acompanham o tutorial. -3. **Enviar a lição**: depois do editor confirmar o acesso ao site, é necessário colocar a lição na [pasta das lições](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/lessons). Em caso de dúvida consultar as [instruções do GitHub](https://help.github.com/articles/adding-a-file-to-a-repository/). -4. **Enviar imagens**: se a lição incluir imagens, verifique se todos os ficheiros foram nomeados de acordo com as regras especificadas acima. O editor deve ter criado uma pasta para fazer o upload na [diretório de imagens](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/images). Esta pasta deve ter o mesmo nome do ficheiro da lição. Carregue as imagens nesta pasta. Caso não visualize a pasta, entre em contato com o editor e aguarde instruções. -5. **Enviar dados**: se a lição incluir ficheiros de dados, estes devem ser colocados da mesma forma que as imagens. Deverá existir uma pasta com o nome da lição no [diretório assets](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/assets). -6. **Enviar um email ao editor** para que ele saiba que os ficheiros foram enviados. +Se a lição está pronta a submeter, segue-se a revisão por pares. As submissões são feitas enviando materiais por e-mail para o editor, para que ele possa carregá-los no nosso site de revisão por pares no [Github](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/lessons). +1. **Obter acesso**: criar uma [conta gratuita](https://github.com/join). Enviar o nome de usuário Github para o editor, que dará acesso de upload ao nosso site de submissões. Informar o editor do nome do ficheiro da lição e se há imagens ou ficheiros de dados que acompanhem o tutorial. O autor não fará o upload inicial para o GitHub, mas precisará de acesso para postar revisões subsequentes. +2. **Preparar os materiais**: se a lição incluir imagens, certificar-se de que todos os ficheiros estão nomeados de acordo com as convenções de nomenclatura especificadas acima. Essas imagens devem ser enviadas numa única pasta compactada. Se a lição incluir ficheiros de dados, eles devem ser enviados noutra pasta compactada. +3. **Enviar um e-mail ao editor**: informar o editor de que está pronto para enviar a lição. Este e-mail deve incluir o ficheiro da lição, bem como as pastas de imagens e recursos, se aplicável. +4. **Juntar-se à conversa**: o editor irá enviar os ficheiros para o nosso [diretório de submissões](https://github.com/programminghistorian/ph-submissions) e fazer as alterações iniciais necessárias. O editor abrirá também um ticket de revisão para a lição. +5. **Fazer revisões**: o upload da lição inicial será realizado pelo editor designado, mas o processo editorial exigirá que o autor faça outras alterações. Todas as revisões subsequentes devem ser feitas pelo autor diretamente nos ficheiros do nosso repositório de submissões para garantir que se esteja a trabalhar com a versão mais recente do ficheiro da lição. ## O processo de revisão por pares From 59b9b0a01eb8b55159aec14b643c58c758715be9 Mon Sep 17 00:00:00 2001 From: Daniel Alves <62759376+DanielAlvesLABDH@users.noreply.github.com> Date: Sat, 12 Dec 2020 15:15:27 +0000 Subject: [PATCH 06/10] Update directrizes-editor.md #1844 --- pt/directrizes-editor.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/pt/directrizes-editor.md b/pt/directrizes-editor.md index 994ca0e1e9..a4df2f0a28 100755 --- a/pt/directrizes-editor.md +++ b/pt/directrizes-editor.md @@ -50,7 +50,13 @@ O contato editorial principal desta lição é [USERNAME DO EDITOR]. Se houver a O editor é incentivado a ajustar o texto para refletir quaisquer metas ou requisitos adicionais acordados com o(s) autor(es). -Após a submissão da lição com sucesso, o editor tem que criar uma issue de revisão para a lição e fechar a discussão da proposta. +Quando os materiais da lição estiverem prontos para envio, o autor entrará em contato com o editor designado, cujo trabalho será enviá-los para o [repositório de submissões](https://github.com/programminghistorian/ph-submissions) após a primeira verificação para garantir que não haja problemas importantes de metadados. + +1. **Carregar a lição**: a lição em si deve ser enviada para a [pasta de lições](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/lessons). Se precisar de ajuda, consulte as [instruções do GitHub](https://help.github.com/articles/adding-a-file-to-a-repository/). +2. **Carregar imagens**: se a lição incluir imagens, certifique-se de que todos os arquivos sejam nomeados de acordo com as convenções de nomenclatura especificadas nas [diretrizes para autores](/directrizes-autor). O editor deve criar uma pasta para as imagens no [diretório de imagens](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/images). Esta pasta deve ter o mesmo nome do ficheiro da lição. Faça upload das imagens para esta pasta. +3. **Carregar dados**: se a lição incluir ficheiros de dados, eles devem ser enviados para uma pasta com nome semelhante no [diretório de recursos](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/assets). + +Após o upload, o editor deve verificar o [histórico de commits do repositório](https://github.com/programminghistorian/ph-submissions/commits/gh-pages) para garantir que o upload recebeu uma marca de seleção verde. Se não, algo deu errado e o [wiki](https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions#checking-travis-for-errors) deve ser consultado para solucionar os erros. Após o envio bem sucedido da lição, o editor criará um ticket de revisão para a lição e fechará o issue da proposta. A partir daqui o editor deve garantir que o autor trabalha a partir da versão mais recente da lição no repositório e carrega as alterações diretamente no GitHub. ### Revisão por pares aberta O *Programming Historian em português* usa um modelo de revisão por pares aberta. Embora acreditando que isto incentiva a civilidade e a partilha produtiva de ideias, os autores têm o direito (e tem que ser respeitado) de solicitar uma revisão por pares fechada. Há muitas razões pelas quais alguém pode hesitar em participar numa revisão aberta e queremos que os autores escolham a opção com que se sentem mais confortáveis. From 99bfa9cebb88329b2d7c6a28cc530d367d30fc36 Mon Sep 17 00:00:00 2001 From: spapastamkou Date: Sun, 20 Dec 2020 09:33:53 +0100 Subject: [PATCH 07/10] integrates marie christine's review comments --- fr/consignes-auteurs.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/fr/consignes-auteurs.md b/fr/consignes-auteurs.md index f72c5a1193..4aeabe8e12 100644 --- a/fr/consignes-auteurs.md +++ b/fr/consignes-auteurs.md @@ -236,7 +236,7 @@ Online*`). ----- ## Soumettre une nouvelle leçon -Une fois que votre leçon a été préparée en suivant les consignes données ci-dessus, nous vous conseillons de la faire relire et éventuellement d'apporter des corrections pour l'améliorer. Ainsi, l'évaluation ouverte par les pairs que nous allons organiser par la suite pourra se concentrer sur le fond pour vous aider à produire la version la plus solide possible de votre leçon. +Une fois que votre leçon a été préparée en suivant les consignes données ci-dessus, nous vous conseillons de la faire relire et éventuellement d'apporter des corrections pour l'améliorer. Ainsi, l'évaluation ouverte par les pairs que nous allons organiser par la suite pourra se concentrer sur le fond, plutôt que sur la forme, afin de vous aider à produire la version la plus solide possible de votre leçon. Lorsque vous êtes prêt(e) à la soumettre, merci d'envoyer tous les fichiers (texte, images, données...) au rédacteur ou à la rédactrice en charge du suivi éditorial de votre leçon, qui les téléversera pour vous dans notre dépôt dédié à l'évaluation par les pairs sur [Github](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/fr/lecons). Voici comment procéder de votre côté: @@ -250,31 +250,31 @@ Lorsque vous êtes prêt(e) à la soumettre, merci d'envoyer tous les fichiers ( ## Le processus de l'évaluation ouverte par les pairs Une fois que votre rédacteur ou rédactrice assigné(e) aura déposé et formaté vos fichiers de manière appropriée, vous recevrez un lien de prévisualisation de la leçon qui vous permettra de vérifier aussi de votre côté que tout se présente correctement; si ce n'est pas le cas, vous pouvez apporter des corrections. -L'évaluation par les pairs a lieu dans le cadre d'un [ticket](https://github.com/programminghistorian/ph-submissions/issues) Github qui prend ainsi la forme d'un forum de discussion ouverte. Merci de garder à l'esprit que l'évaluation par les pairs se fait publiquement et elle reste disponible à la consultation publique; le ticket en est l'enregistrement. Si pour quelque raison que ce soit vous n'êtes pas à l'aise ou souhaitez une évaluation par les pairs non publique, merci de prendre contact avec votre rédacteur ou rédactrice assigné(e). +L'évaluation par les pairs a lieu dans le cadre d'un [ticket](https://github.com/programminghistorian/ph-submissions/issues) Github qui prend ainsi la forme d'un forum de discussion ouverte. Merci de garder à l'esprit que l'évaluation par les pairs se fait publiquement et qu'elle reste disponible à la consultation publique; le ticket en est l'enregistrement. Si pour quelque raison que ce soit vous n'êtes pas à l'aise ou souhaitez une évaluation par les pairs non publique, merci de prendre contact avec votre rédacteur ou rédactrice assigné(e). Le processus de l'évaluation se passe habituellement en trois étapes: 1) Le rédacteur ou la rédactrice assigné(e) à votre leçon en fait une première lecture attentive en en testant les manipulations proposées. Vous êtes à ce stade susceptible de recevoir un premier retour qui pourrait solliciter votre réponse. L'objectif de ce premier retour est de se garantir la pertinence de votre leçon pour le lectorat du *Programming Historian en français* et qu'elle est fonctionnelle avant d'être proposée à l'évaluation externe. Vous avez normalement un mois pour répondre à cette première évaluation. -2) Ensuite, votre rédacteur ou rédactrice assigné(e) propose la leçon à l'évaluation formelle par les pairs. Cela implique l'invitation d'au moins deux évaluateurs ou évaluatrices externes, mais potentiellement aussi la participation d'une communauté plus large, car tout commentaire est bienvenu (pourvu que les règles de bonne conduite, explicités dans le ticket, soient observées). En général, nous accordons aux évaluateurs et évaluatrices un délai d'un mois pour fournir leurs commentaires, il peut néanmoins arriver que ce délai ne soit pas respecté pour des raisons indépendantes de la volonté des personnes impliquées au processus. Vous devez attendre l'ensemble des relectures et les instructions consécutives de votre rédacteur our rédactrice assigné(e) avant d'aller plus loin. Parfois il peut s'agir de simples suggestions d'apporter certaines modifications, mais il peut aussi être question de révisions majeures ou de repenser la leçon. Selon les évaluations des pairs et la nature des questions soulevées, il se peut que vous ayez à réviser le tutoriel plus qu'une fois. Toufois, votre rédacteur ou rédactrice assignée(e) veillera à ce que vous receviez une guidance claire pour que la leçon soit publiée. Par ailleurs, il est toujours possible de retirer votre leçon du processus de l'évaluation, si tel est votre choix. +2) Ensuite, votre rédacteur ou rédactrice assigné(e) propose la leçon à l'évaluation formelle par les pairs. Cela implique l'invitation d'au moins deux évaluateurs ou évaluatrices externes, mais potentiellement aussi la participation d'une communauté plus large, car tout commentaire est bienvenu (pourvu que les règles de bonne conduite, explicités dans le ticket, soient observées). En général, nous accordons aux évaluateurs et évaluatrices un délai d'un mois pour fournir leurs commentaires, il peut néanmoins arriver que ce délai ne soit pas respecté pour des raisons indépendantes de la volonté des personnes impliquées au processus. Vous devez attendre l'ensemble des relectures et les instructions consécutives de votre rédacteur our rédactrice assigné(e) avant d'aller plus loin. Parfois il peut s'agir de simples suggestions d'apporter certaines modifications, mais il peut aussi être question de révisions majeures ou de repenser la leçon. Selon les évaluations des pairs et la nature des questions soulevées, il se peut que vous ayez à réviser le tutoriel plus qu'une fois. Toufois, votre rédacteur ou rédactrice assignée(e) veillera à ce que vous receviez une ligne directrice claire pour que la leçon soit publiée. Par ailleurs, il est toujours possible de retirer votre leçon du processus de l'évaluation, si tel est votre choix. 3) Au bout de ce processus, si tous les critères sont remplis, votre rédacteur ou rédactrice assignée(e) donne le feu vert pour la publication. C'est ensuite au rédacteur ou à la rédactrice en chef de relire la leçon pour s'assurer de sa conformité aux consignes aux auteur(e)s et aux standards du *Programming Historian*. Parfois des révisions et des corrections supplémentaires peuvent être nécessaires à ce stade pour que la leçon puisse être publiée. Une fois que le rédacteur ou la rédactrice en chef juge la version révisée satisfaisante, la leçon peut être publiée. Votre rédacteur ou rédactrice assigné(e) vous fournira toute information nécessaire à ce stade. -Il serait utile de consulter nos [consignes aux évaluateurs et évaluatrices](/fr/consignes-evaluateurs) qui détaillent notre processus de révision et de publication. +N'hésitez pas à consulter nos [consignes aux évaluateurs et évaluatrices](/fr/consignes-evaluateurs) afin de vous familiariser avec notre processus de révision et de publication. Si jamais vous êtes dans l'incertitude sur comment procéder, n'hésitez pas à poster votre question sur le ticket d'évaluation, un membre de notre équipe vous apportera des réponses dans les délais les plus brefs possible. Nous faisons de notre mieux pour répondre au bout de quelques jours. ### Nous interpeller -Notre équipe de bénévoles fait de son possible pour se garantir l'évaluation rigoureuse, collégiale et efficace des auteur(e)s par les pairs. Toutefois, il peut y avoir des failles, c'est pourquoi nous souhaitons que les auteur(e)s nous aident à maintenir un haut niveau de service. Si, pour quelque raison que ce soit, vous estimez ne pas avoir été traité(e) correctement, ou ne comprenez pas trop quel est votre rôle ou ce qu’on attend de vous, ou encore vous considérez que l'évaluation présente des retards injustifiés ou que quelqu'un a été rude avec vous, enfin, pour quelque souci que ce soit, n'hésitez pas à nous en tenir informés afin de pouvoir agir. +Notre équipe de bénévoles fait de son possible pour garantir l'évaluation rigoureuse, collégiale et efficace des auteur(e)s par les pairs. Toutefois, il peut y avoir des failles, c'est pourquoi nous souhaitons que les auteur(e)s nous aident à maintenir un haut niveau de service. Si, pour quelque raison que ce soit, vous estimez ne pas avoir été traité(e) correctement, ou ne comprenez pas trop quel est votre rôle ou ce qu’on attend de vous, ou encore si vous considérez que l'évaluation présente des retards injustifiés ou que quelqu'un a été rude avec vous, enfin, pour quel autre souci que ce soit, n'hésitez pas à nous en tenir informés afin que nous puissions agir. Exprimer des réserves n'a AUCUN impact négatif sur le processus et le résultat de l'évaluation par les pairs. -Pour ce faire, vous avez plusieurs points d'entrée et sentez-vous libre de contacter la personne avec laquelle vous êtes le plus à l'aise: +Pour ce faire, vous avez plusieurs points d'entrée - sentez-vous libre de contacter la personne avec laquelle vous êtes le plus à l'aise: * votre rédacteur ou rédactrice assigné(e); * le rédacteur ou la rédactrice en chef; -* notre médiatrice indépendante ([Dr Hélène Huet](mailto:hhuet@ufl.edu). +* notre médiatrice indépendante ([Hélène Huet](mailto:hhuet@ufl.edu). Nous oeuvrons pour que tout se passe au mieux pour vous, mais si jamais vous estimez vous trouver dans une situation peu confortable, nous vous remercions de nous aider à y remédier et à améliorer les choses. From 0a4291d350cafce33246faab80da91b6397febcd Mon Sep 17 00:00:00 2001 From: Jennifer Isasi Date: Tue, 12 Jan 2021 11:04:28 -0500 Subject: [PATCH 08/10] Update guia de autores with the latest change from Brandon in #1844 --- es/guia-para-autores.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/es/guia-para-autores.md b/es/guia-para-autores.md index 904b684448..1928c94155 100644 --- a/es/guia-para-autores.md +++ b/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 From 923bf6bb44056786d60fd1b628848b6d47cd9238 Mon Sep 17 00:00:00 2001 From: Jennifer Isasi Date: Tue, 12 Jan 2021 13:35:20 -0500 Subject: [PATCH 09/10] Update guia-editor.md with the latest addition per #1844 --- es/guia-editor.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/es/guia-editor.md b/es/guia-editor.md index 2a4bef1047..c233353b7f 100644 --- a/es/guia-editor.md +++ b/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](https://programminghistorian.org/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 From f6f3a46dc6b2507bf699d0bc1456dd19ae9a2fd5 Mon Sep 17 00:00:00 2001 From: Jennifer Isasi Date: Tue, 12 Jan 2021 13:38:10 -0500 Subject: [PATCH 10/10] Update guia-editor.md fix a link issue --- es/guia-editor.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/es/guia-editor.md b/es/guia-editor.md index c233353b7f..bb23b72b36 100644 --- a/es/guia-editor.md +++ b/es/guia-editor.md @@ -52,7 +52,7 @@ Este texto, sin embargo, puede editarse y adaptarse a las necesidades para refle 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](https://programminghistorian.org/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. +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.