From acef0781f0ac2c194c1f60053ef95f1579d1b354 Mon Sep 17 00:00:00 2001
From: Anisa Hawes <87070441+anisa-hawes@users.noreply.github.com>
Date: Fri, 2 May 2025 17:02:36 +0100
Subject: [PATCH 01/13] Create publishing-workflow.md

Create publishing-workflow.md
---
 en/publishing-workflow.md | 85 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 85 insertions(+)
 create mode 100644 en/publishing-workflow.md

diff --git a/en/publishing-workflow.md b/en/publishing-workflow.md
new file mode 100644
index 000000000..507726686
--- /dev/null
+++ b/en/publishing-workflow.md
@@ -0,0 +1,85 @@
+---
+title: Publishing Workflow
+layout: blank
+---
+
+{% include toc.html %}
+
+# Publishing Workflow
+
+Our publishing workflow moves through eight phases: **Proposal**, **Submission**, **Initial Edit**, **First Revision**, **Open Peer Review**, **Second Revision**, **Sustainability + Accessibility**, and **Publication**. The development of both original and translated lessons is supported by the professional services of our publishing team, guided by our managing editors, with the expertise of a cohort of volunteer editors from our project team.
+
+## Overview of Phases, Responsibilities, and Timeframes
+
+| Phase                            | Who is responsible?                    | Expected timeframe:                  |
+| -------------------------------- | -------------------------------------- | ------------------------------------ |
+| **0 Proposal**                   | Managing editor + their editorial team | 14 days feedback <br> 60 days submission |
+| **1 Submission**                 | Publishing team                        | 7 days  |
+| **2 Initial Edit**               | Editor                                 | 30 days |
+| **3 First Revision**             | Author/translator + editor             | 30 days |
+| **4 Open Peer Review**           | Reviewers + editor                     | 30 days |
+| **5 Second Revision**            | Author/translator + editor             | 30 days |
+| **6 Sustainability + Accessibility** | Publishing team (+ copyeditor _original lessons only_)         | 21-30 days |
+| **7 Publication**                | Managing editor + publishing team      | 14 days |
+
+## Details of Phases, Responsibilities, Timeframes, and Processes & Activities
+
+### Phase 0 Proposal 
+
+| Who is responsible?                     | Expected timeframe                |   Process & activities               |
+| -------------------------------- | ------------------------------ | ------------------------------  |
+| Managing editor + their editorial team | 14 days feedback <br> 60 days submission | <ul><li>Managing editor receives proposal forms.</li><li>Proposal forms are circulated for feedback from the editorial team within 14 days.</li><br>**Note:** Proposals are considered on the basis of how well they serve the needs of the community, and whether they support our journal’s ambitions of **openness**, **global access**, **multilingualism** and **sustainability**.<br><li>Managing editor replies to authors/translators to either reject the proposal and share feedback, or invite submission.</li><li>Managing editor opens a new GitHub issue to represent the successful proposal, assigning an editor, and agreeing a submission date within 60 days.</li><br>**Note:** This issue will provide a space for communication and collaboration throughout the publishing workflow. Labels will be used to indicate the lesson’s progress. The publishing team will post a comment at the beginning of each phase to clarify _What’s happening now?_ </ul>
+
+### Phase 1 Submission
+
+| Who is responsible?                     | Expected timeframe                |   Process & activities               |
+| -------------------------------- | ------------------------------ | ------------------------------  |
+| Publishing team | 7 days | <ul><li>Publishing team receives and processes submission materials.</li><li>Markdown files are checked, and key elements of metadata are added.</li><li>Figures are resized and renamed according to our requirements and conventions</li><li>Data assets are checked and processed.</li><li>Publishing team post a comment to the GitHub issue, providing locations of all key files, as well as a link to a live ‘in browser’ preview, where contributors will be able to read the lesson as the draft progresses.</li><li>Publishing team will liaise with author/translator to resolve any queries raised during file processing, and to work through any initial adjustments required.</li></ul>
+
+
+### Phase 2 Initial Edit 
+
+| Who is responsible?                     | Expected timeframe                |   Process & activities               |
+| -------------------------------- | ------------------------------ | ------------------------------  |
+| Editor | 30 days | <ul><li>Editor reads the submission, considering how well it meets our journal’s ambitions of **openness**, **global access**, **multilingualism** and **sustainability.**</li><li>Editor considers the lesson’s level of **difficulty** against our [matrix](/ph-submissions/wiki/Phase-2-Initial-Edit#difficulty-matrix).</li><li>Editor shares initial feedback as a comment in the GitHub issue, anchoring specific comments to sections or paragraphs (referring to numbers at the right margin of the lesson preview) to support the author’s/translator’s revisions in Phase 3.</li></ul>
+
+
+| Our principles | Key considerations |
+| -------------------------------- | ------------------------------ | 
+| **Openness**                         | <ul><li>Does this lesson centre open source software, open programming languages, and open access datasets? If the method involves any proprietary software or commercial tools, we strongly recommend authors present these alongside open source alternatives, and cost-free options.</li> |  |
+| **Global access**                    | <ul><li>Does this lesson outline technical prerequisites clearly, and consider potential limitations of access to methods, software or tools? Remind authors that our readers work with different operating systems and have varying computational resources.</li> <li>Is accessibility embedded within lesson? Our readership have different abilities, and varying access needs. Directive language should avoid using sight as a metaphor for understanding; visuals, plots, and graphs must be accompanied by concise captions, and `alt-text`; tabular data and code must be provided in Markdown and raw form.</li>  |  |
+| **Multilingualism**                  | <ul><li>Has the author chosen methods, tools, and datasets that can be applied or adapted for use in languages other than English? Our strong preference is to publish lessons that will be practicable in multilingual research-contexts, and future translation.</li> <li>Has this author attempted to localise their translation by replacing datasets or case study examples with materials in the translation language to improve usability for the new audience?</li> <li>If this is a translation _to English_, encourage the author to keep non-English datasets and case study examples in place, to help our Anglophone communities learn to work with multilingual data and research materials.</li> |  |
+| **Sustainability**                   | <ul><li>Does this lesson successfully prioritise reflections, contextual discussions and overviews of practical steps over click-by-click instructions? This emphasis helps to ensure lessons remain useful beyond present-day graphical user interfaces and current software versions. Encourage authors to anticipate challenges readers may face, and guide troubleshooting.</li> <li>Does the author specify which computational environment, programming languages, packages and software versions the lesson has been developed for and tested within?</li> <li>Ask authors to include clear citations to case study sources, datasets, and software.</li> |  |
+
+### Phase 3 First Revision 
+
+| Who is responsible?                     | Expected timeframe                |   Process & activities               |
+| -------------------------------- | ------------------------------ | ------------------------------- |
+| Author/translator + editor | 30 days | <ul><li>Editor + author/translator agree a timeframe for the author/translator to make the suggested revisions (30 days is usually reasonable).</li><li>Author/translator revises the lesson.</li><li>Author/translator posts a comment in the issue to confirm when the revised draft is ready for the editor’s review.</li><br>**Note:** Revision is a collaborative process, involving dialogue. The depth of editorial work involved will vary from lesson to lesson.<br><br><li>Editor begins coordinating peer reviewers to participate in Phase 4. We encourage and celebrate diversity of gender, nationality, race, age, and academic background among our contributors.</li><li>Managing editor + publishing team advise editor who among our current Peer Reviewer volunteers are available, or support the editor to make direct approaches.</li></ul>
+
+
+### Phase 4 Open Peer Review
+
+| Who is responsible?                     | Expected timeframe                |   Process & activities               |
+| -------------------------------- | ------------------------------ | ------------------------------  |
+| Reviewers + editor | 30 days |  <ul><li>Reviewers share their feedback as a comment in the issue thread within 60 days.</li><li>Editor summarises the two reviews so that the author/translator has a clear sense of the revisions to work through in Phase 5.</li></ul>
+
+
+### Phase 5 Second Revision
+
+| Who is responsible?                     | Expected timeframe                |   Process & activities               |
+| -------------------------------- | ------------------------------ | ------------------------------  |
+| Author/translator + editor | 30 days | <ul><li>Editor + author/translator agree a timeframe for the author/translator to make the suggested revisions (30 days is usually reasonable).</li><li>Author/translator revises the lesson.</li><li>Author/translator posts a comment in the issue to confirm when the revised draft is ready for the editor’s review.</li><li>Editor re-reads the lesson to confirm that all agreed revisions are complete.</li><li>Managing editor reads the lesson to confirm if it should be moved to Phase 6.</li></ul>
+
+
+### Phase 6 Sustainability + Accessibility
+
+| Who is responsible?                     | Expected timeframe                |   Process & activities               |
+| -------------------------------- | ------------------------------ | ------------------------------  |
+| Publishing team (_+ copyeditor original lessons only_) | 21-30 days |  <ul><li>Copyediting (_original lessons only_) to check the text for clarity of expression, typing mistakes and grammatical errors.</li><li>Typesetting to ensure consistent layout.</li><li>Generating archival hyperlinks.</li><li>Checking of files and metadata.</li><li>Assigning a DOI.</li><li>Collating copyright agreements.</li></ul>
+
+### Phase 7 Publication
+
+| Who is responsible?                     | Expected timeframe                |   Process & activities               |
+| -------------------------------- | ------------------------------ | ------------------------------  |
+| Managing editor + publishing team (+ editor _post-publication_) | 14 days | <ul><li>Managing editor re-reads the lesson, to provide final feedback or suggest additional revisions.</li><li>Publishing manager stages files for publication.</li><li>Managing editor approves the lesson for publication.</li><li>Publishing team initiates announcement + schedule promotion of the new lesson.</li><li>Publishing team shares suggested citation + social media announcement links with all contributors to close the issue.</li></ul>

From 4569bc0ffbb82ea496c90ea2b00a88fe81f5d577 Mon Sep 17 00:00:00 2001
From: Anisa Hawes <87070441+anisa-hawes@users.noreply.github.com>
Date: Fri, 2 May 2025 17:03:39 +0100
Subject: [PATCH 02/13] Delete en/editor-guidelines.md

Delete file.
---
 en/editor-guidelines.md | 426 ----------------------------------------
 1 file changed, 426 deletions(-)
 delete mode 100755 en/editor-guidelines.md

diff --git a/en/editor-guidelines.md b/en/editor-guidelines.md
deleted file mode 100755
index 46051ecfd..000000000
--- a/en/editor-guidelines.md
+++ /dev/null
@@ -1,426 +0,0 @@
----
-title: Editor Guidelines
-layout: blank
-redirect_from: /editor-guidelines
----
-
-# Editor Guidelines
-
-This page contains step-by-step instructions for editors facilitating peer review for the *Programming Historian*.
-
-
-## The Role of the Editor
-Thank you for editing a lesson for the *Programming Historian*. We are extremely grateful for your efforts. This guide is meant to ensure that all authors, editors, and reviewers receive a consistent and fair experience with the *Programming Historian*. If you have any questions about anything in these guidelines, please email one of the other editors or post a question on our [Github issues](https://github.com/programminghistorian/jekyll/issues). Do the same if you think these guidelines need improvement or updating.
-
-{% include toc.html %}
-
-
-
-
-
-
-We always encourage prospective authors to pitch their ideas before they start writing. If a piece is not suitable for the *Programming Historian* our job is to tell an author before they have written a full tutorial. We hope this saves everyone time and energy. Once we have spoken to an author and encouraged their idea, our aim is always to support authors until the piece is publishable. Our goal is to help them reach that stage as efficiently as possible with clear guidance. You may find it helpful to familiarise yourself with our [instructions for authors](/author-guidelines).
-
-### Safe Spaces
-The *Programming Historian* is committed to providing a safe space for the exchange of ideas, where everyone can share without fear of harassment or abuse. The editor plays a fundamental role in ensuring that space endures. Your job includes enforcing our anti-harassment policy at all times. If you need help please ask one of the other editors or PH ombudsperson (Dr Ian Milligan - i2milligan@uwaterloo.ca). You can read more about our [commitment to safe spaces](/posts/PH-commitment-to-diversity) on the project blog.
-
-### Anti-Harassment Policy
-This is a statement of the *Programming Historian's* principles and sets expectations for the tone and style of all correspondence between reviewers, authors, editors, and contributors to our public forums.
-
-The *Programming Historian* is dedicated to providing an open scholarly environment that offers community participants the freedom to thoroughly scrutize ideas, to ask questions, make suggestions, or to requests for clarification, but also provides a harassment-free space for all contributors to the project, regardless of gender, gender identity and expression, sexual orientation, disability, physical appearance, body size, race, age or religion, or technical experience. We do not tolerate harassment or ad hominem attacks of community participants in any form. Participants violating these rules may be expelled from the community at the discretion of the editorial board. If anyone witnesses or feels they have been the victim of the above described activity, please contact our ombudsperson (Dr Ian Milligan - i2milligan@uwaterloo.ca). Thank you for helping us to create a safe space.
-
-### Track Proposed Lessons
-Once a lesson proposal has been given the "green light" by the editorial team and has been assigned an editor, the editor will work with the author to clarify the goals of the lesson and to establish an agreed upon submission deadline. The recommended time frame is 90 days from the start of the editorial conversation, though this can be adjusted if needed.
-
-The editor will then create a "Proposed Lesson" issue in the [submissions repository on Github](https://github.com/programminghistorian/ph-submissions/issues) and assign it the "proposals" label. The default proposal text is included in the issue template, or can be copied from below.
-
-```
-The Programming Historian has received the following proposal for a lesson on 'PROVISIONAL LESSON TITLE' by AUTHOR(S) NAME(S). The proposed learning outcomes of the lesson are:
-
-- key learning outcome 1
-- key learning outcome 2
-- key learning outcome 3 (add as needed)
-
-In order to promote speedy publication of this important topic, we have agreed to a submission date of no later than [90 DAYS BY DEFAULT BY LONGER IF AGREED WITH EDITOR]. The author(s) agree to contact the editor in advance if they need to revise the deadline.
-
-If the lesson is not submitted by [THE AGREED DATE], the editor will attempt to contact the author(s). If they do not receive an update, this ticket will be closed. The ticket can be reopened at a future date at the request of the author(s).
-
-The main editorial contact for this lesson is [EDITOR USERNAME]. If there are any concerns from the authors they can contact the Ombudsperson (Dr Ian Milligan - i2milligan@uwaterloo.ca).
-```
-
-The editor is encouraged to adjust the issue text to reflect any additional goals or requirements agreed upon between the author(s) and editor.
-
-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 appropriate subfolder (depending on whether it is an original lesson or a translation) of the [lessons folder](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/en) within the corresponding language folder in the root of the ph-submissions repository. If you need help, see [GitHub's instructions](https://help.github.com/articles/adding-a-file-to-a-repository/).
-2. **Uploading Images**: if the lesson includes images, make sure all of the files are named according to the naming conventions specified in the [author guidelines](/author-guidelines). The editor should create a folder for the images in the  [images directory](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/images). This folder should have the same name as the lesson filename. Upload the images to this folder.
-3. **Uploading Data**: if the lesson includes data files, they should be uploaded to a similarly named folder in the [assets directory](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/assets).
-
-After uploading, the editor should check the [commit history for the repository](https://github.com/programminghistorian/ph-submissions/commits/gh-pages) to ensure that their upload received a green check mark. If not, something went wrong and the [wiki](https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions#checking-travis-for-errors) should be consulted for troubleshooting the errors. Upon successful submission of the lesson, the editor will create a review ticket for the lesson and close the proposal issue. From here on, the editor should ensure that the author work from the latest version of the lesson in the repository and upload changes directly to GitHub themselves.
-
-### Open Peer Review
-The *Programming Historian* uses a model of open peer review, while we believe this helps maintain civility and the productive sharing of ideas, authors have the right (and we have a requirement to respect that right) to request a closed peer review. There are many reasons why someone might be hesitant to engage in an open review and we encourage authors to always pursue the option with which they are most comfortable.
-
-Before soliciting external reviews, the editor should read and try the tutorial and use their experience with the *Programming Historian* to help the author make initial improvements (if required). The editor is not expected to be a expert in content of the lesson, this is the role of the [reviewers](/reviewer-guidelines).
-
-The editor should complete an initial sustainability overview of the submission to ensure that software versions and dependencies are clearly marked, specificities of software like screenshots are limited to those required to complete the lesson, and that the lesson makes use of existing software documentation whenever available and appropriate. Editors should also ensure that lessons try, as much as possible, to avoid software specific directions, such as "Right-click on the _x_ icon to access the _x_ menu," instead favoring general methodological overviews. The Editorial Checklist [contains more details about sustainability practices](#c-sustainability-review) for PH.
-
-Often editors need help clarifying the intended audience of a lesson, or identifying jargon that needs further explanation. This initial review helps let the external reviewers focus on improving the piece. This is normally done openly on our submission system (see below), but it can be a closed review at the request of either party.
-
-Once an author has revised the tutorial to the satisfaction of the editor, it is the editor's job to invite two formal external peer reviews. In the interest of our [commitment to diversity](https://github.com/programminghistorian/jekyll/issues), we encourage editors to ask themselves if they have made a sufficient effort to draw from reviewers who are distinct from themselves either by gender, nationality, race, age, or academic background. Please try not to find two people who are very like you.
-
-To coordinate our requests for reviewers, please use the "Programming Historian - Reviewer Tracking" Google Spreadsheet. (Contact the managing editor if you need help accessing the spreadsheet.) Prior to sending a review request, check the list to make sure that the person has not been recently contacted by another editor. To avoid over-taxing reviewers, please limit requests to once a year. If a reviewer has been contacted in the past year, the "date_contacted" field will display as red.
-
-For each potential reviewer you do contact, regardless of response, please enter:
-
-+ the date contacted,
-+ the reviewer's name,
-+ your name as the editor,
-+ the lesson to be reviewed,
-+ the response,
-+ and, if the response was "yes," the date completed.
-
-Please enter the date using the `mm/dd/yyyy` format.
-
-When inviting reviewers, the editor should provide them with our [reviewer guidelines](/reviewer-guidelines) and give them a deadline for completing their review (usually one month) so that we can ensure the timely publication of the tutorial.
-
-When a lesson has been submitted, the editor will open a new 'issue' on our [Github submissions repository](https://github.com/programminghistorian/ph-submissions/issues) where the open review will take place. This message board allows everyone to keep track of the conversation. You will need to sign up for a free Github account if you do not already have one, as will both the author and reviewers.
-
-### The Initial Comment
-
-Your first comment on the message board for a given tutorial review should use our template which outlines the role of the editor and what will take place during the review, as well as everyone's options in the unlikely event that something goes wrong. Please adapt [the template](https://github.com/programminghistorian/ph-submissions/blob/gh-pages/.github/ISSUE_TEMPLATE), which should appear automatically in all new issue boxes, as needed:
-
-```
-The Programming Historian has received the following tutorial on '[LESSON TITLE]' by [AUTHOR GITHUB USERNAME]. This lesson is now under review and can be read at:
-
-http://programminghistorian.github.io/ph-submissions/en/["lessons" or "translations"]/[URL to lesson]
-
-I will act as editor for the review process. My role is to solicit two reviews from the community and to manage the discussions, which should be held here on this forum. I have already read through the lesson and provided feedback, to which the author has responded.
-
-Members of the wider community are also invited to offer constructive feedback which should post to this message thread, but they are asked to first read our Reviewer Guidelines (/reviewer-guidelines) and to adhere to our anti-harassment policy (below). We ask that all reviews stop after the second formal review has been submitted so that the author can focus on any revisions. I will make an announcement on this thread when that has occurred.
-
-I will endeavor to keep the conversation open here on Github. If anyone feels the need to discuss anything privately, you are welcome to email me. You can always turn to our ombudsperson (Dr Ian Milligan - i2milligan@uwaterloo.ca) if you feel there's a need for an ombudsperson to step in.
-
-Anti-Harassment Policy
-_
-
-This is a statement of the Programming Historian's principles and sets expectations for the tone and style of all correspondence between reviewers, authors, editors, and contributors to our public forums.
-
-The Programming Historian is dedicated to providing an open scholarly environment that offers community participants the freedom to thoroughly scrutinize ideas, to ask questions, make suggestions, or to requests for clarification, but also provides a harassment-free space for all contributors to the project, regardless of gender, gender identity and expression, sexual orientation, disability, physical appearance, body size, race, age or religion, or technical experience. We do not tolerate harassment or ad hominem attacks of community participants in any form. Participants violating these rules may be expelled from the community at the discretion of the editorial board. If anyone witnesses or feels they have been the victim of the above described activity, please contact our ombudsperson (Dr Ian Milligan - i2milligan@uwaterloo.ca). Thank you for helping us to create a safe space.
-```
-
-### Guiding the Conversation
-
-Everyone will be looking to you as the editor for guidance on the system. For most authors and reviewers this will be their first experience with our peer review process. The immediate feedback offered by the message board means that authors may see the reviewer comments before you do. That means you will have to clearly signpost how everything will work and when everyone should participate or wait for further instruction.
-
-If possible it is always best to acknowledge review milestones as soon as possible. For example, after the first review has come in, post a response to thank the reviewer and let the author know that another review is on its way. Suggest that they wait for the second review before responding. This lets everyone know what to expect.
-
-If you are really busy, if possible make a note on the forum to say you have seen the new activity, but will need some time to respond properly. Managing expectations can be key to keeping everyone happy.
-
-### Summarising the Review
-
-Once the two formal reviews are in (as well as any informal contributions from the community), you will have to summarise the suggestions and give the author a clear path for any revisions that you would like them to respond to. If any suggestions are counter to our aims at the *Programming Historian*, politely tell the author to forego those suggestions. Keep in mind what it is like to be an author and receive a review. You want clear guidance, but also the right to reject ideas that don't improve the piece. You also want assurance that you are not trying to hit a moving target. A good summary of reviews means an author can respond and expect publication if all significant obstacles are met.
-
-### Managing the Revision Process
-
-With your summary of the reviews and any final instructions for the editor, include a reminder to the author that revisions should be completed within 4 weeks. This is to ensure that lessons are published in a timely fashion and do not drag on unnecessarily. If the author anticipates trouble meeting the deadline, they should contact their editor to establish a more suitable due date.
-
-## Technical Processes of Review - Editorial Checklist
-
-Our peer review is conducted on our [Submissions repository](https://github.com/programminghistorian/ph-submissions) on Github. Full instructions for how to upload files, including file formats and formatting guidelines can be found on our [Author Submission Instructions](/author-guidelines) which will always contain the most up to date instructions. Please familiarise yourself with these steps or refer to them as needed. If you need help you are always welcome to [email another editor directly](/project-team).
-
-There are a few areas where you should intervene in the process from a technical standpoint. They include:
-
-### A) Naming the Lesson File
-
-The **Editor** should suggest a name for the new lesson file that conforms to these guidelines:
-
-- Make the filename short, but descriptive; this filename will eventually become the slug for the lesson's URL when published.
-- A good URL would fit nicely on a powerpoint slide, is easy to remember, and tells you something about the lesson. Our URLS take the following format: `https://programminghistorian.org/en/lessons/FILENAME-HERE`
-- Do not put spaces in the filename; use hyphens instead.
-- The filename extension should be `.md` so that GitHub will generate a preview of the lesson.
-
-Once you have chosen a name for the lesson file, use the same name to create a new folder in `images` which will contain all of the images for the lesson. If the lesson uses data files, do the same in the `assets` folder.
-
-### B) Initial Check of Markdown
-
-Authors are responsible for checking that their lesson has rendered properly in Markdown. If they have followed the syntax rules, it should be ok. If you can see any Markdown symbols on the page, something went wrong. Detailed instructions of Markdown syntax are available on our [Author Guidelines](/author-guidelines)
-
-You can quickly check that everything looks correct on a lesson submission by looking at the rendered version of the page. It will be found at:
-
-`http://programminghistorian.github.io/ph-submissions/en/lessons/FILENAME-HERE`  (note - no .md at the end)
-
-Note that if it is a translation you would substitute "translations" for "lessons". If that doesn't work, let the technical team know, and they will try to diagnose it.
-
-### C) Sustainability & Internationalization Review
-To increase the lifespan of our lessons, _Programming Historian_ editors should complete a sustainability review as a part of their final checklist. Every submission is different and some of these areas may not be applicable to all submissions. Keeping in mind the difficulty level of each lesson and its intended audience, editors should use these areas as guidelines to ensure that lessons are as sustainable as possible from the date of publication.
-
-- All software versions and dependencies are described in the introduction to the lesson
-- Sources of data for lessons are clearly noted and should be hosted at the _Programming Historian_ whenever possible
-- Lessons make use of existing software documentation whenever possible
-- Lessons link to Wikipedia for technical terminology
-- Screenshots of software GUIs are limited to those that are required to understand the lesson
-- External links (e.g. software or data sources) are current and live though authors should consider directing users to documentation generally rather than providing links to specific documentation pages
-- Links to articles use DOIs if available
-
-To help reach a global audience, authors have been advised to adhere to the following guidelines where possible:
-
-- When choosing your methods or tools, try to make choices with multi-lingual readers in mind. This is particularly important when working on textual analysis methods, or where users may reasonably want to have support for different character sets (eg, accented characters, non-Latin, etc).
-- When choosing primary sources, images, producing figures, or taking screen shots, consider how they will present themselves to a global audience.
-- When writing, avoid jokes, cultural references, puns, plays on words, idiomatic expressions, sarcasm, emojis, or language that is more difficult than it needs to be. Mentions of persons, organisations, or historical details should always come with contextual information. It may help to assume your reader does not live in your country or speak your language.
-- In code examples or metadata, use internationally recognised standard formats for dates and times ([ISO 8601:2004](https://www.iso.org/standard/40874.html)). In free text, be aware of cultural differences related to the representation of dates and times which might cause confusion.
-- Where possible, choose methods and tools that have multi-lingual documentation. If this is not practical, it would be great if you could add some multi-lingual references at the end of your tutorial.
-
-Editors should work closely with authors to ensure that these criteria are met. Where this is not possible, justifications for not meeting them should be clearly and transparently outlined in the relevant review ticket
-
-### D) Verify Images
-
-All images should use consistent, semantically meaningful filenames that clearly indicate what they are. If a lesson has a large number of images in rapid succession, and the order is important (for example, a series of screenshots), it may be advisable to use a sequential naming system---ideally using the same hyphenated filename slug as the lesson itself (or an abbreviated version if the lesson title is rather long), followed by numbers to indicate which figure it is (For example, `counting-frequencies-1.png`, `counting-frequencies-2.png`, and so on.)
-
-If a lesson does use a sequential image naming system, it is possible that figure numbering will change during the peer review process. We ask that before a lesson is published that all filenames are updated to the proper figure numbers. This makes it much easier for us to update lessons if needed in the future. Thank you for helping us keep the *Programming Historian* sustainable.
-
-Regardless of how the images are named (semantically or sequentially), they should be placed in a subdirectory within the `images` directory. The subdirectory should be named using the same URL slug used to name the lesson. Make sure the images are in web-friendly formats such as PNG or JPEG and sized appropriately (both in terms of pixels and bytes).
-
-Full instructions on adding images is available in [Author Submission Instructions](/author-guidelines).
-
-### E) Verify Data files
-
-Similarly to Images, all data files should be stored on the site (not linked externally - for sustainability purposes). All data should be stored in the 'assets' directory, using the same rules as above, but authors should feel free to use a description for their data file that reflects what it is:
-
- - `/assets/LESSON-SLUG/Louvre-Paintings-1.csv`
-
- Occasionally, large assets used by particular lessons might be too large to be stored in our GitHub repository. If this is the case, we recommend that authors upload their assets to [Zenodo](https://zenodo.org/) for archiving and then provide the lesson editor with the DOI generated by Zenodo for linking from within the lesson. In the event that such datasets might already exist in an institutional repository, we still recommend uploading the version of the dataset used in *The Programming Historian* to Zenodo for the purposes of consistent use across all of our lessons.
-
- When uploading to Zenodo, all files (even if there is a single file) should be compressed into a single zip file. The zip file should have the same slug used for the lesson file. This is only necessary when the total size of the assets for the lesson is larger than 25MB.
-
-### F) Verify videos/gifs
-
-Videos and gifs are strongly discouraged because they create a range of problems. For example, it is difficult and time consuming to ask for changes to a video during the peer review process, and impossible for an editor to make minor updates to it in years to come as it becomes outdated. Videos also require the administration of a separate channel at YouTube. Videos also cannot be printed, and many of our readers use PDF copies or [printed copies of the *Programming Historian*](https://zenodo.org/record/49873#.V0lazGaGa7o). As such they should ONLY be used when absolutely necessary.
-
-If a tutorial contains a video it should be hosted on our YouTube channel (which is not set up yet so email the other editors when you get a video). A backup of the file should also be stored in our Github repository, following the same principles of naming and storage as in sections for images and data described above and stored in the 'assets' directory:
-
- - `/assets/LESSON-SLUG/FILENAME-HERE-3`
-
----
-
-## Recommend Publication - Editorial Checklist
-
-Once you and the author are happy with a tutorial, the next step is to recommend publication to the managing editor. This involves checking the files and adding some additional metadata before contacting them:
-
-### 1) Create an Author Bio
-
-If the lesson has been written by a new author, the managing editor will need to add a new bio for that person. You will need to provide the managing editor with a version of the following information:
-
-```yaml
-- name: Jim Clifford
-  team: false
-  orcid: 0000-0000-1111-1111
-  bio:
-      en: |
-          Jim Clifford is an assistant professor in the Department of History
-          at the University of Saskatchewan.
-```
-
-**Whitespace is important**, so be sure that the indentation matches the other examples.
-
-The `orcid` ID is optional, but highly encouraged if [authors have registered for an ID with the service](https://orcid.org/). **Only enter an ORCiD ID that an author has explicitly provided to you. Do enter an ID without first getting that author's confirmation that you are using the correct ID.**
-
-### 2) Add a table of contents to the lesson
-
-The following code should be added into the text of the lesson, usually before the first subheader:
-
-```
-{% raw %}{% include toc.html %}{% endraw %}
-```
-
-### 3) Add YAML metadata to the lesson file
-
-```
-title: "Your Title Here"
-collection: lessons
-layout: lesson
-slug: e.g. introduction-to-sentiment-analysis
-date: YYYY-MM-DD
-translation_date: YYYY-MM-DD (translations only)
-authors:
-- Forename Surname
-- Forename Surname etc
-reviewers:
-- Forename Surname
-- Forename Surname etc
-editors:
-- Forename Surname
-translator:
-- Forename Surname (translations only)
-translation-editor:
-- Forename Surname (translations only)
-translation-reviewer:
-- Forename Surname (translations only)
-original: slug to original published lesson (translations only)
-review-ticket: e.g. https://github.com/programminghistorian/ph-submissions/issues/108
-difficulty: see guidance below
-activity: ONE OF: acquiring, transforming, analyzing, presenting, sustaining
-topics:
- - topic one (see guidance below)
- - topic two
-abstract: |
-  see guidance below
-avatar_alt: Description of lesson image
-doi: Add DOI (see https://github.com/programminghistorian/jekyll/wiki/How-to-Request-a-new-DOI)
-```
-
-- **difficulty** To help readers evaluate which lessons best fit their goals and skill level, we provide "Recommended for ___ Users" information in the lesson YAML file. There are currently three tiers, which can be set with the following numerical codes: 1 (Beginning), 2 (Intermediate), 3 (Advanced). To add the difficulty level of 'intermediate' to the lesson, include the following in the YAML file:
-```
-difficulty: 2
-```
-- **topics** can be any number of the things listed after "type:" in /\_data/topics.yml. You are also encouraged to create new topics that would help someone find the lesson. To do so, besides listing the topic(s) in the lesson's front matter, you should:
-1. Add the topic to any existing lesson(s) also described by the new topic
-2. Add the new topic(s) to /\_data/topics.yml following the format of the other topics there (note that topics can't have spaces—use hyphens if needed).
-3. Edit /js/lessonfilter.js so the filter button to filter the lesson page to that topic works. Search the file for the ten-line chunk of code beginning with `$('#filter-api')`, copy and paste that chunk of code, and replace the *two* appearances of "api" with your new topic.
-- **abstract** is a 1-3 sentence description of what you'll learn in the lesson. Try to avoid technical vocabulary when possible, as these summaries can help scholars without technical knowledge to try out something new.
-- **slug** should have the path to the lesson on the public PH site, which means the hyphenated text following programminghistorian.org/lessons/ (e.g. building-static-sites-with-jekyll-github-pages)"
-- **date** The date of the lesson should be updated to the date that the submission was moved to the main Jekyll repository.
-- If the lesson uses formulas, you need to add `mathjax: true` for them to be displayed correctly.
-
-### 4) Find an Image to represent the lesson
-
-We represent our lessons using an old image that we feel captures some element of the task described in the tutorial. You can see the full range of these on the [main Lessons directory](/lessons/). These images are selected by editors.
-
-Here are a few places to look for lesson images:
-
- - The [British Library](https://www.flickr.com/photos/britishlibrary)
- - The [Internet Archive Book Images](https://archive.org/details/bookimages)
- - The [Virtual Manuscript Library of Switzerland](https://www.flickr.com/photos/e-codices)
- - The [Library of Congress Maps](http://www.loc.gov/maps/collections)
-
-Ensure that the image matches the style of the other images (it should be a book image, not a photograph), is at least 200 pixels in both dimensions, and is not copyright restricted. Make sure the image is not offensive, and keeping with our [Commitment to Diversity](/posts/PH-commitment-to-diversity) try to find something that does not perpetuate stereotypes or send a subtle message about maleness and whiteness.
-
-Save the original image. The filename should be the same as the corresponding lesson’s URL slug with `-original` at the end, and the filetype must be `.png`. For example, the lesson “Cleaning Data with OpenRefine” has the URL slug `cleaning-data-with-openrefine`, so its original lesson image filename should be `cleaning-data-with-openrefine-original.png`.
-
-Then, create a new copy of the image. Crop it to a square without removing any important features. Change the dimensions to 200x200 pixels. Convert the image to grayscale. Perform any adjustments necessary to make it conform to the other lesson images, such as lightening or darkening it, or altering the contrast. Save this new image as the lesson’s URL slug; again, **the file format must be png**. In our previous example, the filename would be `cleaning-data-with-openrefine.png`.
-
-Upload the original image to the [gallery/originals](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/gallery/originals) folder, and upload the edited image to the [gallery](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/gallery) folder. You will need to direct the managing editor to the locations of these images on the ph_submissions repo when you hand the files off to them for publishing.
-
-### 5) Inform the Managing Editor of your Recommendation to Publish
-
-The Managing Editor will read and carefully check over the lesson, ensuring that it adheres to our sustainability, internationalization, and style guidelines. If in the Managing Editor's discretion, the lesson fails to meet any of those thresholds of quality, it may be returned to the author for revision. If it passes these final quality control checks, the Managing Editor will publish the lesson by moving the files to the main website and check everything over.
-
-To make this person's job easier, post a list in the submission ticket of all files that need to be moved to publish the lesson. This should normally include:
-
-- The lesson .md file
-- The directory for any accompanying files (images, data, etc)
-- The gallery icons
-- A bio if the author is new
-
-All except the bio should be represented as files somewhere in the ph_submissions repo. The bio can be placed in the ticket directly.
-
-### 6) Incorporate your lesson into our Twitter bot
-In addition to the Twitter promotion outlined below, we also make use of a Twitter bot to regularly re-advertise older lessons. In order to add the new lesson to our pipeline, you need to add it as a row in [this spreadsheet](https://docs.google.com/spreadsheets/d/1o-C-3WwfcEYWipIFb112tkuM-XOI8pVVpA9_sag9Ph8/edit#gid=1625380994). Everyone on the editorial team should have the ability to make changes; email the google group if you have trouble. You will need to add a new row for your lesson to the end of the table with the following fields:
-
-* message_one (column A) - a twitter message to play early in the week.
-* message_two (column B) - an "In Case You Missed It" twitter message to play later in the week.
-* link (column C) - the link to the lesson.
-
-Leave column D blank and untouched - this field is used by the Twitter bot to log its progress through the list. Also note that this step should not replace your own promotion of the lesson. The bot goes through the lessons at random, one a week, so it could be months until your lesson comes up through this means.
-
-### 7) Thank Everyone and Encourage Promotion
-Once you have been given word that the Managing Editor has successfully published the lesson, close the submission ticket, linking to the published lesson. It's important to send an email or message to everyone involved thanking them for their efforts. In particular, thank the author for contributing and encourage them to think of us again in future. It's also worth giving the author some ideas on promoting their lesson. The most-used lessons always have authors' energies behind them. For example authors should be encouraged to:
-
-- Tweet at least 3 times about their lesson (with a link).
-- Retweet our tweets about their lesson ('liking' does not help spread the word)
-- Promote their lesson in presentations or publications about their research
-- Link to it in blog posts when relevant
-- Add it to lists of resources in relevant repositories (eg, Wikipedia, community groups, etc).
-
-People don't find lessons on their own. The hard work is done, so let's make sure it was worth it!
-
-# Managing Editor Checklist
-
-The Managing Editor is responsible for carefully checking the lesson to make sure it adheres to all of our policies and requirements. If the lesson does not meet these requirements it should be referred back to the editor for further revision. This is a crucial part of the editorial workflow. Once the Managing Editor is satisfied that the lesson meets our standards, it is his/her role to move the files to the main website via a pull request.
-
-## 1) Carefully check the submission preview
-
-Check the submission preview for any errors or failures to meet our publication guidelines. Refer any issues back to the editor.
-
-## 2) Request DOI
-
-You need to request a new DOI for the lesson following the steps described in the [Wiki](https://github.com/programminghistorian/jekyll/wiki/How-to-Request-a-new-DOI).
-
-This part of the process should not take you more than one or two days, depending on the time difference you have with the UK (UTC). You can start next steps while you wait, but note that builds will initially fail until the DOI has been added to the lesson metadata.
-
-## 3) Move the Files
-
-The editor should have left you a clear list of files that need to be published on the submission ticket. If they have not done so, ask them to fix it before proceeding.
-
-There are several ways that you can perform a pull request to publish the files:
-
-* A) Follow our ["Making Technical Contributions" guidelines](https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions), which uses the Github website GUI.
-
-* B) Use `git` from the command line. The following instructions assume that you have already cloned both the `jekyll` and `ph-submissions` repositories to your local machine. (Our [lesson on using GitHub Desktop](/lessons/getting-started-with-github-desktop) may be helpful if this is new to you.) If you are not sure how to do that or have any questions, contact the technical team for assistance.
-
- 1. Go to the directory for your local `ph-submissions` repository.
- 2. `git pull` to get all of the newest changes on your machine (or `sync` if you are using GitHub Desktop)
- 3. Repeat Steps 1 and 2 for the `jekyll` repository on your local machine.
- 4. Copy the lesson files and any related image and asset files from the `ph-submissions` directory on your machine to the appropriate places in the `jekyll` directory on your local machine. (You can use a command like `cp` on the Unix command line, or use your GUI file system if you are using GitHub Desktop.)
- 5. From within the `jekyll` directory on your local machine, `git add` the new files and then `git commit` and `git push` the changes.
-
-After the lesson has been moved to the `jekyll` repository, you'll also need to archive the submitted lesson on the `ph-submissions` repository.
-
-1. Go to the directory for your local `ph-submissions` repository.
-2. Add a new line to the YAML header of the now published lesson: `redirect_from: "/lessons/LESSON-SLUG"`
-3. Move the now published lesson from `lessons/` into `lessons/published/`.
-4. Move the image folder containing the images for the now published lesson from `images/` to `images/published/`.
-5. Use `git add`, `git commit`, and `git push` to finalize all the changes (or follow the Making Technical Contributions instructions: https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions)
-
-## 4) Add the author bio to ph_authors.yml
-
-If the lesson has been written by a new author, the managing editor should add information about the author to the site's [authors directory](https://github.com/programminghistorian/jekyll/blob/gh-pages/_data/ph_authors.yml). Follow the syntax for the examples already included there, using the bio that the editor provided you:
-
-```yaml
-- name: Jim Clifford
-  team: false
-  orcid: 0000-0000-1111-1111
-  bio:
-      en: |
-          Jim Clifford is an assistant professor in the Department of History
-          at the University of Saskatchewan.
-```
-
-## 5) Confirm all links and YAML headers are functioning correctly
-
-Once you push your changes on to the `gh-pages` branch of the [programminghistorian][ph_repo] repository, the site will be automatically tested by [GitHub Actions].
-This test process checks three things: first, that all YAML and markdown code is parseable; second, that all the hyperlinks on the site point to valid, operational pages; and third, that internal links to pages on the _Programming Historian_ are all relative links that start with `/` rather than `https://programminghistorian.org/`
-
-[ph_repo]: https://github.com/programminghistorian/jekyll
-
-[GitHub Actions]: https://github.com/features/actions
-
-We run these builds primarily to check that URLs that _once_ were functional are _still_ functional, as often times external web pages are moved to new addresses, or are no longer live.
-They are also an excellent way to catch small typos that may have evaded authors, editors, and reviewers.
-The status of these tests (often called a "Build Status" on GitHub) can be seen by navigating to the [programminghistorian repository page][ph_repo], and clicking "Commits" on the upper left side of the code menu.
-
-![GitHub commit menu location](/images/website/editor-guidelines/gh_commits_location_screen.png)
-
-This will show you the list of every change made to the main repository, along with a status icon:
-
-- Green check mark: you're good to go! All the links on the page were checked and found valid. [**You may skip the rest of this section.**](#6-inform-the-editor)
-- Yellow circle: your latest commit is still building. Wait 1-2 minutes and then check back.
-- Red X: there was an error in the build.
-
-If your build has errored, you will need to consult the build logs to see what is causing it.
-
-1. Click on the red X for the most recent commit (the one nearest the top of the page), and click on the "Details" link.
-![Travis details location](/images/website/editor-guidelines/commit_list_screen.png)
-2. This will bring you to the build log page on GitHub Actions. Build logs are usually several hundred lines long, but the error information we are looking for will be at the bottom. Click on the small gray circle at the upper right of the log display to scroll to the bottom.
-![The top of the Travis CI build screen](/images/website/editor-guidelines/travis_top_screen.png)
-3. You may see two types of errors: first, if a page is missing a required YAML field (e.g. if a lesson does not have an `editors` field) then this will be marked in red. Failing links will be also be listed in red, grouped by the page they appeared in. If any links in your new lesson are causing errors, go back and double check that they do not have any typos. If they do, then make any necessary corrections and commit the changes to the repository, and wait for GitHub Actions to run its tests again.
-![Locating error details in Travis CI build results](/images/website/editor-guidelines/travis_bottom_screen.png)
-
-- There are some rare circumstances in which a link will be failed by GitHub Actions, but will work perfectly fine when you navigate to it in your own Internet browser. If this occurs, [create a new issue] so that one of the members of the technical team can review the problem and find a workaround.
-- As part of its normal operations, GitHub Actions will occasionally go back and re-check old links across this entire site, including old lessons. Therefore, you may see an error being caused not by your lesson, but by another page. If you can see how to immediately fix those errors on other pages, please do so, and then wait for the build to re-run. If you do not have the time to track down those other broken links, first ensure that there are no error links coming from your new lesson, and then [create a new issue] so that someone else on the technical team can review the problem.
-
-[create a new issue]: https://github.com/programminghistorian/jekyll/issues/new
-
-## 6) Inform the Editor
-
-Once the lesson has been published, inform the editor and ensure they have added the lesson to the twitter bot pipeline.

From ec9c3a9c68ff7f2a0cfbcd9890fb6b57abc80f73 Mon Sep 17 00:00:00 2001
From: Anisa Hawes <87070441+anisa-hawes@users.noreply.github.com>
Date: Fri, 2 May 2025 17:04:52 +0100
Subject: [PATCH 03/13] Create processus-de-publication.md

Create new Markdown file.
---
 fr/processus-de-publication.md | 86 ++++++++++++++++++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 fr/processus-de-publication.md

diff --git a/fr/processus-de-publication.md b/fr/processus-de-publication.md
new file mode 100644
index 000000000..4c42d7461
--- /dev/null
+++ b/fr/processus-de-publication.md
@@ -0,0 +1,86 @@
+---
+title: Processus de Publication
+layout: blank
+redirect_from: /consignes-redacteurs
+original: publishing-workflow
+---
+
+{% include toc.html %}
+
+# Processus de Publication
+
+Notre processus de publication se déroule en huit phases&nbsp;: **Proposal** (Proposition), **Submission** (Soumission), **Initial Edit** (Edition Initiale), **First Revision** (Première Révision), **Open Peer Review** (Evaluation Ouverte par les Pairs), **Second Revision** (Deuxième Révision), **Sustainability + Accessibility** (Durabilité + Accessibilité), et **Publication**. Il est soutenu par les services professionnels de notre équipe de publication (guidée par nos rédacteurs·rices en chef) et par l'expertise d'une cohorte de rédacteurs·rices bénévoles de notre équipe.
+
+## Aperçu des phases, des responsabilités et des délais
+
+| Phase                            | Qui est responsable&nbsp;?                    | Délai estimé&nbsp;:                  |
+| -------------------------------- | -------------------------------------- | ------------------------------------ |
+| **0 Proposal** (Proposition)                   | Rédacteur·rice en chef + son équipe d'édition | 14 jours pour le retour <br> 60 jours pour la soumission |
+| **1 Submission** (Soumission)                | Équipe de publication                        | 7 jours  |
+| **2 Initial Edit** (Edition Initiale)              | Rédacteur·rice                                 | 30 days |
+| **3 First Revision** (Première Révision)                | Auteur·e ou traducteur·rice + rédacteur·rice            | 30 jours |
+| **4 Open Peer Review** (Evaluation Ouverte par les Pairs) | Évaluateurs·rices + rédacteur·rice                     | 30 jours |
+| **5 Second Revision** (Deuxième Révision)   | Auteur·e ou traducteur·rice + rédacteur·rice             | 30 jours |
+| **6 Sustainability + Accessibility** (Durabilité + Accessibilité) | Equipe de publication  (+ correcteur·rice _seulement pour leçons originales_)         | 21-30 jours |
+| **7 Publication**                | Rédacteur·rice en chef + équipe de publication      | 14 jours |
+
+## Detail des phases, responsabilités, délais, et procédures & activités
+
+### Phase 0 Proposition 
+
+| Qui est responsable&nbsp;?                    | Délai estimé&nbsp;:                 |   Procédure & activités               |
+| -------------------------------- | ------------------------------ | ------------------------------  |
+| Rédacteur·rice en chef + leur équipe d'édition | 14 jours pour le retour <br> 60 jours pour la soumission | <ul><li>Le/la rédacteur·rice en chef reçoit les formulaires de propositions.</li><li>Les formulaires de propositions sont distrubués à l'équipe d'édition pour un retour dans les 14 jours.</li><br>**Note:** Les propositions sont examinées en fonction de leur capacité à répondre aux besoins de la communauté et à soutenir les ambitions d'**ouverture**, d'**accès mondial**, de **multilinguisme** et de **durabilité** de notre revue.<br><br><li>Le/la rédacteur·rice en chef répond aux auteurs·es ou traducteurs·rices pour rejeter la proposition et offrir un retour, ou inviter une soumission complète.<br></li><li>Le/la rédacteur·rice en chef ouvre un nouveau ticket sur GitHub pour représenter la proposition acceptée, assigner un/une rédacteur·rice et décider d'une date de soumission dans un délai de 60 jours.</li><br>**Note:** Ce ticket deviendra un espace de communication et de collaboration au fil de la publication. Des étiquettes seront utilisées pour indiquer la progression de la leçon. L'équipe de publication publiera un commentaire au début de chaque nouvelle phase pour clarifier _What's Happening Now?_ (_Que se passe-t-il maintenant ?_). </ul>
+
+### Phase 1 Submission (Soumission)
+
+| Qui est responsable&nbsp;?                    | Délai estimé&nbsp;:                 |   Procédure & activités               |
+| -------------------------------- | ------------------------------ | ------------------------------  |
+| Equipe de publication | 7 jours | <ul><li>L'équipe de publication reçoit et traite les documents soumis.</li><li>Les fichiers Markdown sont vérifiés, les éléments clés de métadonnées sont ajoutés.</li><li>Les figures sont redimensionnées et renommées selon nos exigences et conventions.</li><li>Les fichiers de données supplémentaires sont vérifiés et traités.</li><li>L'équipe de publication publie un commentaire sur le ticket GitHub pour donner le liens vers les fichiers clés, ainsi qu'un aperçu de la leçon, que chaque contributeur/contributrice pourra lire en temps réel au fur et à mesure que la leçon avance.</li><li>L'équipe de publication communiquera avec l'auteur·e ou traducteur·rice pour résoudre toute question soulevée pendant le traitement du dossier, et procéder à tout ajustement initial nécessaire.</li></ul>
+
+
+### Phase 2 Initial Edits (Édition initiale)
+
+| Qui est responsable&nbsp;?                    | Délai estimé&nbsp;:                 |   Procédure & activités               |
+| -------------------------------- | ------------------------------ | ------------------------------  |
+| Rédacteur·rice | 30 jours | <ul><li>Le/la rédacteur·rice lit la soumission, en prenant en compte sa capacité à soutenir les ambitions d'**ouverture**, d'**accès mondial**, de **multilinguisme** et de **durabilité** de notre revue.</li><li>Le/la rédacteur·rice définit le niveau de **difficulté** de la leçon en s'appuyant sur notre [matrice](/ph-submissions/wiki/Phase-2-Initial-Edit#difficulty-matrix)</li><li>Le/la rédacteur·rice partage un retour initial sur le ticket GitHub, en ancrant chaque commentaire à une section ou un paragraphe spécifique (se reférant aux numéros dans la marge droite de l'aperçu de la leçon) pour aider les révisions de l'auteur·e ou traducteur·rice en Phase 3.</li></ul>
+
+| Considérations clés:                      | |
+| -------------------------------- | ------------------------------ | 
+| **Ouverture**                         | <ul><li>Cette leçon est-elle centrée sur des logiciels libres, des langages de programmation libres et des ensembles de données libres d'accès&nbsp;? Si la méthode fait appel à des logiciels propriétaires ou à des outils commerciaux, nous recommandons vivement aux auteurs·es de les accompagner d'alternatives ouvertes et gratuites.</li> |  |
+| **Accès Mondial**                    | <ul><li>Cette leçon décrit-elle clairement les prérequis techniques et prend-elle en compte les limitations potentielles d'accès aux méthodes, logiciels ou outils&nbsp;? Rappelez aux auteurs·es que nos lecteurs·rices utilisent des systèmes d'exploitation différents et disposent de ressources informatiques variées.</li> <li>L'accessibilité est-elle intégrée dans la leçon&nbsp;? Nos lecteurs·rices ont des capacités différentes et des besoins d'accès variés. Le langage ne doit pas utiliser des métaphores basées sur la vision pour aider la compréhension&nbsp;; les éléments visuels, les diagrammes et les graphiques doivent être accompagnés de légendes concises et d'une description «&nbsp;alt text&nbsp;»&nbsp;; les données tabulaires et le code doivent être fournis en Markdown sous forme brute.</li>  |  |
+| **Multilinguisme**                  | <ul><li>L'auteur·e a-t-il/elle choisi des méthodes, des outils et des ensembles de données qui peuvent être appliqués ou adaptés à une utilisation dans des langues autres que l'anglais&nbsp;? Nous préférons de loin publier des leçons qui pourront être mises en pratique dans des contextes de recherche multilingues, ainsi que des traductions futures.</li> <li>L'auteur·e a-t-il/elle tenté de localiser sa traduction en remplaçant les ensembles de données ou les exemples d'études de cas par des documents dans la langue de la traduction, afin de faciliter leur utilisation par le nouveau lectorat&nbsp;?</li> <li>S'il s'agit d'une traduction _vers l'anglais_, encouragez l'auteur·e à conserver des ensembles de données et des exemples d'études de cas non anglophones, afin d'aider nos communautés anglophones à apprendre à travailler avec des données et du matériel de recherche multilingues.</li> |  |
+| **Durabilité**                   | <ul><li>Cette leçon donne-t-elle la priorité aux réflexions, aux discussions contextuelles et à une vision plus globale des étapes pratiques, plutôt qu'aux instructions pas-à-pas&nbsp;? Ceci permet d'assurer que les leçons restent utiles au-delà des interfaces graphiques et des versions actuelles des logiciels. Encouragez l'auteur·e à anticiper les difficultés auxquelles les lecteurs·rices peuvent être confrontés et à les aider à résoudre les problèmes.</li> <li>L'auteur·e précise-t-il/elle l'environnement informatique, les langages de programmation et les versions des logiciels pour lesquels la leçon a été développée et testée&nbsp;?</li> <li>Demandez aux auteurs·es de citer clairement les sources des études de cas, des ensembles de données et des logiciels.</li> |  |
+
+### Phase 3 First Revision (Première Révision) 
+
+| Qui est responsable&nbsp;?                    | Délai estimé&nbsp;:                 |   Procédure & activités               |
+| -------------------------------- | ------------------------------ | ------------------------------- |
+| Auteur·e ou traducteur·rice + rédacteur·rice | 30 jours | <ul><li>L'auteur·e ou traducteur·rice + rédacteur·rice décident d'un délai pour les révisions de l'auteur·e ou traducteur·rice (30 jours est un délai raisonnable).</li><li>L'auteur·e ou traducteur·rice révise sa leçon en fonction des suggestions de le/la rédacteur·rice.</li><li>L'auteur·e ou traducteur·rice publie un commentaire sur le ticket GitHub pour confirmer que les révisions sont prêtes à être relues par le/la rédacteur·rice.</li><br>**Note:** La révision est un processus collaboratif, qui implique un dialogue ouvert. L'amplitude du travail éditorial demandé varie entre chaque leçon.<br><br><li>Le/la rédacteur·rice commence à coordonner l'évaluation ouverte par les pairs, qui participeront en Phase 4. Nous engourageons et célébrons la diversité de genre, nationalité, race, age et profil académique parmi nos contributeurs/contributrices.</li><li>Le/la rédacteur·rice en chef et l'équipe de publication conseillent le/la rédacteur·rice pour savoir qui dans nos évaluateurs·rices sont disponibles, ou alors aident le/la rédacteur·rice à lancer des approches directes.</li></ul>
+
+
+### Phase 4 Open Peer Review (Évaluation ouverte par les pairs)
+
+| Qui est responsable&nbsp;?                    | Délai estimé&nbsp;:                 |   Procédure & activités               |
+| -------------------------------- | ------------------------------ | ------------------------------  |
+| Évaluateurs·rices + rédacteur·rice | 30 days |  <ul><li>Le/la rédacteur·rice présente les deux évaluateurs·rices qui vont relire la leçon/traducation et tester le code, en publiant un commentaire pour ouvrir la Phase 4.</li><li>Le/la rédacteur·rice envoie un email aux deux évaluateurs·rices pour partager les liens clés et quelques conseils.</li><li>Les évaluateurs·rices partagent leur retour dans un commentaire sur le ticket GitHub, dans un délai de 30 jours.</li><li>Le/la rédacteur·rice résume les deux retours en un commentaire, pour que l'auteur·e ait une idée claire des révisions nécessaires en Phase 5.</li></ul>
+
+
+### Phase 5 Second Revision (Deuxième Révision)
+
+| Qui est responsable&nbsp;?                    | Délai estimé&nbsp;:                 |   Procédure & activités               |
+| -------------------------------- | ------------------------------ | ------------------------------  |
+| Auteur·e ou traducteur·rice + rédacteur·rice | 30 jours | <ul><li>L'auteur·e ou traducteur·rice + rédacteur·rice décident d'un délai pour les révisions de l'auteur·e ou traducteur·rice (30 jours est un délai raisonnable).</li><li>L'auteur·e ou traducteur·rice révise sa leçon en fonction des suggestions des évaluateurs·rices.</li><li>L'auteur·e ou traducteur·rice publie un commentaire sur le ticket GitHub pour confirmer que les révisions sont prêtes à être relues par le/la rédacteur·rice.</li><li>Le/la rédacteur·rice relit la leçon pour confirmer que toutes les révisions demandées sont mises en place.</li><li>Le/la rédacteur·rice en chef relit la leçon pour confirmer qu'elle peut passer en Phase 6.</li></ul>
+
+
+### Phase 6 Sustainability + Accessibility (Durabilité + Accessibilité)
+
+| Qui est responsable&nbsp;?                    | Délai estimé&nbsp;:                 |   Procédure & activités               |
+| -------------------------------- | ------------------------------ | ------------------------------  |
+| Équipe de publication (_+ correcteur·rices pour leçons originales_) | 21-30 jours |  <ul><li>Correction (_seulement pour leçons originales_) pour vérifier la clarté d'expression, les fautes de frappe et les erreurs grammaticales.</li><li>Mise en page pour assurer une structure consistente.</li><li>Generation des liens d'archive.</li><li>Vérification des fichiers attachés et des métadonnées.</li><li>Attribution d'un DOI.</li><li>Réception des formulaires de droits d'auteur.</li></ul>
+
+### Phase 7 Publication
+
+| Qui est responsable&nbsp;?                    | Délai estimé&nbsp;:                 |   Procédure & activités               |
+| -------------------------------- | ------------------------------ | ------------------------------  |
+| Rédacteur·rice en chef + équipe de publication (+ rédacteur·rice _post publication_) | 14 jours | <ul><li>Le/la rédacteur·rice en chef relit la leçon pour offrir un dernier retour et suggérer des révisions additionelles.</li><li> Le/la responsable de publication prépare les fichiers pour être publiés.</li><li>Le/la rédacteur·rice en chef approuve la publication de la leçon.</li><li>L'équipe de publication initie l'annonce + programme la promotion de la nouvelle leçon.</li><li>L'équipe de publication partage la citation suggérée + les liens de l'annonce sur les réseaux sociaux avec tous les contributeurs·rices, pour clore le ticket.</li></ul>

From ffadf353b37c67d731b4dd95f43db43b95efa049 Mon Sep 17 00:00:00 2001
From: Anisa Hawes <87070441+anisa-hawes@users.noreply.github.com>
Date: Fri, 2 May 2025 17:05:23 +0100
Subject: [PATCH 04/13] Delete fr/consignes-redacteurs.md

Delete Markdown file.
---
 fr/consignes-redacteurs.md | 398 -------------------------------------
 1 file changed, 398 deletions(-)
 delete mode 100644 fr/consignes-redacteurs.md

diff --git a/fr/consignes-redacteurs.md b/fr/consignes-redacteurs.md
deleted file mode 100644
index 0a83259b1..000000000
--- a/fr/consignes-redacteurs.md
+++ /dev/null
@@ -1,398 +0,0 @@
----
-title: Consignes aux rédacteurs et rédactrices
-layout: blank
-original: editor-guidelines
----
-
-# Consignes aux rédacteurs et aux rédactrices
-
-Cette page fournit des instructions détaillées aux rédacteurs et rédactrices qui apportent leur concours lors de l'évaluation par les pairs dans le cadre du *Programming Historian en français*.
-
-## Le rôle du rédacteur et de la rédactrice
-Nous vous remercions d'assurer le travail éditorial pour une leçon du *Programming Historian en français*, nous vous savons gré pour vos efforts. Ce guide a comme objectif de garantir la cohérence et la qualité de la collaboration entre auteur(e)s, rédacteurs/rédactrices et évaluateurs/évaluatrices avec le *Programming Historian en français*. Pour toute question qui porte sur les consignes, merci de contacter par courriel un des membres du conseil éditorial ou de poser une question sur notre espace dédié sur [Github](https://github.com/programminghistorian/jekyll/issues). Merci de le faire aussi si vous jugez que ces consignes doivent être améliorées ou mises à jour.
-
-{% include toc.html %}
-
-Qu'il s'agisse du suivi éditorial d'une leçon originale ou d'une traduction, notre rôle n'est pas celui d'un gardien, comme dans les revues traditionnelles, mais d'apporter notre concours lors du processus d'écriture, de traduction, d'évaluation et de publication. Merci donc de prendre connaissance de nos [consignes de rédaction et de traduction](/fr/consignes-auteurs). Nous encourageons toujours les personnes susceptibles de rédiger une leçon de soumettre un plan détaillé de leurs idées avant d'entamer l'écriture. Si néanmoins un texte ne convient pas au *Programming Historian en français*, il nous incombe de le dire avant que l'auteur(e) ne s'avance trop dans la rédaction d'un tutoriel. Ainsi, nous espérons que cela évite à toutes et à tous de perdre du temps et de l'énergie. Une fois les discussions avec un(e) auteur(e) entamées et son idée encouragée, nous fournissons par la suite un soutien constant jusqu'à la publication de la leçon.
-
-### Un espace d'échange sûr
-Le *Programming Historian en français* s'engage à fournir un espace sûr pour l'échange d'idées où personne n'aura peur de se faire harceler ou attaquer. Le rédacteur ou la rédactrice a un rôle fondamental pour le maintien de telles conditions car une de vos missions est de constamment renforcer notre politique contre le harcèlement. Si vous avez besoin d'aide, merci de vous adresser au reste du comité éditorial ou notre médiatrice [Hélène Huet](/fr/equipe-projet). Vous pouvez vous renseigner davantage sur notre [engagement pour des espaces d'échange sûrs](/posts/PH-commitment-to-diversity) sur le blog du projet.
-
-### Politique contre le harcèlement
-Vous trouverez ci-dessous les principes du *Programming Historian en français* qui doivent inspirer les échanges entre évaluateurs et évaluatrices, auteur(e)s, rédacteurs et rédactrices, ainsi que toute personne contribuant à nos forums publics.
-
-Le *Programming Historian en français* tient à garantir un environnement académique ouvert à la communauté, qui offre la pleine liberté d'explorer minutieusement des idées, poser des questions, faire des suggestions ou demander des clarifications. Il fournit aussi un espace libre de toute discrimination envers les personnes contribuant au projet, indépendamment du genre, de l'orientation sexuelle, des situations d'handicap, de l'apparence physique, de la masse corporelle, de l'origine, de l'âge, de la religion ou de l'expérience technique. Nous ne tolérons aucune forme de harcèlement ou d'attaque personnelle contre les membres de la communauté. Les personnes qui violent ces règles sont susceptibles d'être expulsées de la communauté à la discrétion du conseil éditorial. Toute personne en mesure de témoigner de tels comportements ou qui en est la victime peut contacter notre médiatrice [Hélène Huet](/fr/equipe-projet). Merci de nous aider à créer un espace d'échange et de discussion sûr.
-
-### Suivi des leçons proposées
-Lorsqu'une proposition de leçon reçoit le feu vert par l'équipe éditoriale, un rédacteur ou une rédactrice lui est assigné(e) pour mener un travail en commun avec l'auteur(e) dans le but de définir des objectifs clairs pour la leçon et de fixer un délai de publication. Habituellement, nous recommandons de respecter un délai de 90 jours à partir du moment où les discussions sont entamées, mais ce délai peut être réajusté si nécessaire.
-
-Le rédacteur ou la rédactrice doit alors créer un nouveau ticket intitulé "Proposition de leçon" dans le [dépôt des soumissions sur Github](https://github.com/programminghistorian/ph-submissions/issues) en le signalant avec l'étiquette "proposal". Le texte par défaut à utiliser comme introduction se trouve dans le gabarit du ticket ou alors il peut être copié ci-dessous.
-
-```
-Le Programming Historian en français a reçu la proposition suivante d'une leçon intitulée 'TITRE PROVISOIRE DE LA LEÇON' de la part de NOM(S) D'AUTEUR(E-S). Les principaux objectifs pédagogiques envisagés sont:
-
-- principal objectif pédagogique no 1
-- principal objectif pédagogique no 2
-- principal objectif pédagogique no 3 (ajouter plus si besoin)
-
-Pour s'assurer d'une rapide publication sur ce sujet d'importance, nous nous sommes mis d'accord sur une date de dépôt qui ne dépasse pas [90 JOURS PAR DÉFAUT OU PLUS SI AGRÉÉ PAR LE(LA) REDACTEUR(TRICE)]. Les auteur(e)s sont d'accord pour contacter le(la) rédacteur(trice) en avance s'ils ont besoin de revoir le délai.
-
-Si la leçon n'est pas déposée d'ici le [DATE AGRÉÉE], le rédacteur ou la rédactrice tentera de contacter les auteur(e)s. Sans mise à jour de leur part, ce ticket sera clos, il peut toutefois être à nouveau ouvert sur demande des auteur(e)s.
-
-Le principal contact éditorial pour cette leçon est [NOM D'UTILISATEUR/UTILISATRICE DU RÉDACTEUR/DE LA RÉDACTRICE]. Pour tout souci, les auteur(e)s peuvent contacter notre médiatrice Hélène Huet.
-```
-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.
-
-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/en-cours); 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/en-cours/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](/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 traduction) 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](#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.
-
-Lorsqu'un(e) auteur(e) a revisé le tutoriel de manière satisfaisante, c'est au rédacteur ou à la rédactrice de faire formellement appel à deux personnes pour lancer l'évaluation par les pairs. Certes, le choix lui appartient entièrement, cependant, en ce sens que nous devons respecter notre [engagement en faveur de la diversité](https://github.com/programminghistorian/jekyll/issues), nous espérons qu'aucun effort n'aura été épargné pour que les personnes choisies aient des profiles diversifiés en termes de genre, de nationalité, de culture, d'âge ou d'appartenance académique. Merci donc de faire de votre mieux pour ne pas trouver deux personnes qui vous ressemblent trop.
-
-Nos demandes d'évaluations sont organisées à l'aide d'un tableur Google intitulé "Programming Historian - Reviewer Tracking" que nous vous prions de bien vouloir utiliser (vous pouvez contacter le rédacteur ou la rédactrice en chef ou Jeri Wieringa si vous avez besoin d'aide pour accéder au tableur). Avant de proposer une évaluation, merci de vérifier si la personne sollicitée n'a pas été récemment contactée par un autre membre de l'équipe de rédaction. Pour éviter de surcharger les évaluateurs et évaluatrices, merci de limiter vos demandes à une par an. Si une personne a été sollicitée dans l'année passée, le champ "date_contacted" apparaitra en rouge.
-
-Pour chaque personne pressentie en tant qu'évaluateur ou évaluatrice, indépendamment de la réponse, merci d'insérer:
-
-+ la date de prise de contact,
-+ le nom de l'évaluateur/évaluatrice,
-+ votre nom en tant que rédacteur ou rédactrice,
-+ le titre de la leçon à évaluer,
-+ la réponse,
-+ et, si la réponse est "oui", la date à laquelle l'évaluation a été achevée.
-
-Pour les dates, merci d'utiliser le format `mm/jj/aaaa`.
-
-Lorsque la proposition est faite aux candidat(e)s, le rédacteur ou la rédactrice doit mettre à leur disposition nos [consignes aux évaluateurs et évaluatrices](/fr/consignes-evaluateurs) et fixer le délai pour compléter l'évaluation (habituellement un mois) pour que le tutoriel puisse être publié à temps.
-
-Quand une leçon est soumise, le rédacteur ou la rédactrice doit ouvrir un nouveau ticket sur notre [dépôt de soumissions sur Github](https://github.com/programminghistorian/ph-submissions/issues). C'est là que va se passer l'évaluation ouverte, puisque des messages qui peuvent être postés via l'interface permettent à tout un chacun de suivre la discussion. Pour cela, il est nécessaire pour toutes les parties prenantes d'avoir un compte Github gratuit.
-
-### Le commentaire initial
-
-Votre premier commentaire sur le ticket d'évaluation d'un tutoriel doit être calqué sur le modèle de celui qui explique le rôle du rédacteur et de la rédactrice, décrit la procédure de l'évaluation ainsi que les options qui se présentent au cas improbable où des problèmes surgiraient. Merci d'adapter [le modèle](https://github.com/programminghistorian/ph-submissions/blob/gh-pages/.github/ISSUE_TEMPLATE), qui devrait apparaître automatiquement lors de l'ouverture d'un nouveau ticket, de la manière qui correspond:
-
-```
-Le Programming Historian en français a reçu la leçon (ou la traduction de la leçon) intitulée '[TITRE DE LA LEÇON]' par [NOM D'UTILISATEUR/UTILISATRICE GITHUB DE L'AUTEUR(E)] ou, s'il s'agit d'une traduction, traduite par [NOM D'UTILISATEUR/UTILISATRICE GITHUB DU TRADUCTEUR OU DE LA TRADUCTRICE]). La leçon (ou la traduction) est actuellement en cours d'évaluation et peut être consultée ici:
-
-http://programminghistorian.github.io/ph-submissions/fr/en-cours/["originales"ou "traductions"/[NOM-DE-FICHIER-ICI]
-
-J'exercerai le rôle de rédacteur/rédactrice lors de la procédure de l'évaluation. Cela implique de solliciter deux évaluations par la communauté et de gérer les discussions qui auront lieu sur ce forum. J'ai déjà fait une lecture critique de la leçon puis un retour auquel l'auteur(e) a répondu.
-
-Les membres de la communauté plus large sont aussi invités de fournir une critique constructive via ce fil de messages, après avoir pris connaissance de nos consignes aux évaluateurs et évaluatrices (/fr/consignes-evaluateurs) et accepté notre politique contre le harcèlement (cf. ci-dessous). Nous demandons que toute nouvelle évaluation cesse après que la seconde, parmi celles qui ont été formellement sollicitées, a été déposée, pour que l'auteur(e) puisse se concentrer sur les révisions à faire. Lorsque cela est le cas, je prendrai soin de l'indiquer dans le fil de discussion.
-
-Je vais essayer de garder la discussion ouverte ici sur Github. Si quelqu'un a besoin de discuter en privé, merci de m'envoyer un courriel. Il y a toujours la possibilité de vous adresser à notre dispositif de médiation, si vous le souhaitez.
-
-Politique contre le harcèlement.
-_
-
-Ceci est une déclaration des principes du Programming Historian en français et définit nos attentes concernant le ton et le style des échanges entre évaluateurs/évaluatrices, auteur(e)s, rédacteurs/rédactrices et toute autre personne contribuant à nos forums publics. Le Programming Historian en
-
-Le _Programming Historian en français_ a pour but d'offrir un environnement académique ouvert, qui permet aux membres de la communauté de se sentir libres d'examiner des idées en détail, de poser des questions, de faire des suggestions, ou de formuler des demandes de clarification. Nous insistons sur l'importance de faire en sorte que cet espace de discussion reste respectueux et exempt de tout harcèlement pour tous les contributeur(trice)s, quels que soient leur genre, leur identité et leur expression de genre, leur orientation sexuelle, leur handicap, leur apparence physique, leur masse corporelle, leurs origines, leur âge, leur religion, ou leur expérience technique. Nous ne tolérons pas, sous quelque forme que ce soit, le harcèlement ou les attaques ad hominem contre les membres de la communauté. Les participant(e)s qui violeraient ces règles pourront être exclu(e)s de la communauté à la discrétion du comité éditorial. Si quelqu'un est témoin ou pense avoir été victime des agissements décrits plus haut, veuillez prendre contact avec notre médiatrice [Hélène Huet](/fr/equipe-projet). Merci de nous aider à créer un espace de discussion et d'échange sûr.
-```
-
-### Mener la discussion
-
-Votre rôle de rédacteur ou de rédactrice signifie que les personnes impliquées dans les différentes étapes de la procédure vont s'appuyer sur vous pour s'orienter. Pour la plupart des auteur(e)s et des évaluateurs/évaluatrices, il peut s'agir d'une première expérience de notre dispositif d'évaluation par les pairs. La publication immédiate des expertises sous forme de commentaires dans le ticket correspondant signifie que les auteur(e)s peuvent en prendre connaissance avant vous. C'est pourquoi il vous incombe d'indiquer clairement les étapes de la procédure et préciser quand chaque personne doit participer ou attendre des instructions complémentaires.
-
-Il vaut toujours mieux définir des étapes clés dès que possible. Par exemple, à la suite de la réception de la première évaluation, publiez un message en remerciant l'évaluateur ou l'évaluatrice et en faisant savoir à l'auteur(e) qu'une expertise supplémentaire est attendue. À cette occasion, n'hésitez pas à lui suggérer d'attendre que la seconde expertise arrive avant de répondre. De cette manière, toutes les personnes savent à quoi s'attendre.
-
-Si vous n'êtes vraiment pas disponible, faites si possible un bref message expliquant que vous êtes au courant des activités en cours, mais que vous avez besoin de plus de temps pour répondre de manière correcte. Satisfaire les attentes des personnes impliquées est élémentaire pour que tout le monde soit heureux.
-
-### Résumer les points principaux de l'expertise
-Une fois que les deux évaluations formelles sont prêtes, de même que toute contribution en provenance de la communauté, vous devez faire un résumé des suggestions faites et indiquer clairement à l'auteur(e) les modifications qui lui sont proposées. Si certaines propositions ne correspondent pas à l'esprit du *Programming Historian en français*, il faut indiquer à l'auteur(e) de ne pas en tenir compte. Merci de vous mettre à la place d'un(e) auteur(e) qui reçoit une évaluation: la personne a besoin d'indications claires, tout en maintenant la liberté de rejeter parmi les suggestions qui lui sont faites celles qui n'améliorent pas nécessairement son écrit. La personne doit encore avoir le sentiment que les objectifs sont bien fixés. Un bon résumé des expertises offre à l'auteur(e) la possibilité de réagir tout en garantissant la publication de son travail, si les principaux obstacles sont dépassés.
-
-### Gérer la procédure de la révision
-
-Lorsque vous fournissez le résumé des expertises et les instructions finales à l'auteur(e), rappelez aussi le délai de quatre semaines accordé pour faire les révisions. Fixer un délai garantit un horizon de publication des leçons et évite une prolongation de la procédure sans raison. Si l'auteur(e) a du mal à respecter le délai, il lui incombe de contacter le rédacteur ou la rédactrice pour convenir d'une date appropriée.
-
-## Questions techniques de l'évaluation - liste de vérification éditoriale
-
-Notre procédure d'évaluation par les pairs est menée sur notre [dépôt des soumissions](https://github.com/programminghistorian/ph-submissions) sur Github. Des instructions détaillées pour télécharger les fichiers et choisir les bons formats et langages se trouvent sur les [consignes aux auteur(e)s](/fr/consignes-auteurs) qui sont régulièrement mis à jour. Merci de vous familiariser avec ces étapes et de vous y référer chaque fois que cela est nécessaire. Si vous avez besoin d'aide, il est toujours possible de [contacter directement par courriel un autre membre de l'équipe de rédaction](/fr/equipe-projet).
-
-Il y a certaines manipulations techniques à faire à ce stade qui sont les suivantes:
-
-### A) Nommer le fichier de la leçon
-
-C'est au **rédacteur** ou à la **rédactrice** de proposer un nommage de fichier pour la nouvelle leçon qui se conforme aux consignes suivantes:
-
-- Le nom du fichier doit être court, mais descriptif, car il fournira aussi l'URL de la leçon au moment de sa publication.
-- L'URL idéale est celle qui peut aisément s'insérer dans une diapositive, aussi d'un point de vue esthétique, elle est facile à retenir et peut avoir une fonction sémantique par rapport à la leçon. Nos URL prennent la forme suivante: https://programminghistorian.org/fr/lecons/NOM-DE-FICHIER-ICI
-- N'insérez pas des espaces à l'intérieur des noms de fichiers, préférez les tirets.
-- L'extension du fichier doit être `.md` pour que Github puisse générer un aperçu de la leçon.
-
-Lorsque vous aurez choisi un nom de fichier pour la leçon, merci de l'utiliser aussi pour créer un nouveau dossier dans `images`, c'est là où seront stockées toutes les images de la leçon. S'il existe aussi des fichiers de données, merci de faire la même action dans le dossier `assets`.
-
-### B) Vérifier la syntaxe Markdown
-
-Les auteur(e)s ont la responsabilité de vérifier que la syntaxe de leur leçon en Markdown est correcte. Si toutes les règles ont été respectées, aucun problème ne devrait se présenter. Au cas contraire, des symboles Markdown restent visibles sur la page, ce qui signifie qu'il y a des erreurs. Des instructions détaillées sur la syntaxe Markdown peuvent se trouver dans nos [consignes aux auteur(e)s](/fr/consignes-auteurs).
-
-Vous pouvez vérifier rapidement si tout se présente correctement au cours de la soumission en consultant la version du fichier qui s'affiche sur :
-
-`http://programminghistorian.github.io/ph-submissions/fr/en-cours/originales/NOM-DE-FICHIER-ICI`, s'il s'agit d'une leçon originale; ou sur `http://programminghistorian.github.io/ph-submissions/fr/en-cours/traductions/NOM-DE-FICHIER-ICI`, s'il s'agit d'une traduction (attention, pas d'extension .md à la fin).
-
-Si cela ne marche pas, merci d'en informer notre équipe technique qui s'occupera du problème.
-
-### C) Vérifier la pérennité et l'ouverture internationale
-
-Pour augmenter la durée de vie de nos leçons, les rédacteurs et rédactrices du _Programming Historian en français_ doivent vérifier que sont réunies certaines conditions qui garantissent la pérennité de la leçon. Certes, les mêmes critères ne peuvent pas nécessairement s'appliquer à tous les dépôts, vu que chaque cas est différent. Toutefois, en tenant compte du niveau de difficulté de chaque leçon et du public auquel il s'adresse, les rédacteurs et les rédactrices peuvent s'appuyer sur les critères suivants pour s'assurer de la longévité des leçons après la date de leur publication.
-
-- Toutes les versions des logiciels et des dépendances logicielles sont décrites dans l'introduction de la leçon.
-- Les sources des données mobilisées par les leçons sont clairement mentionnées et, si possible, hébergées sur le _Programming Historian_.
-- Les leçons mobilisent la documentation existant sur les logiciels autant que possible.
-- Les leçons pointent vers Wikipédia pour les termes techniques.
-- Les captures d'écran d'interfaces graphiques sont limitées à ce qui est nécessaire pour la compréhension de la leçon.
-- Les liens externes (par exemple vers des logiciels ou des sources de données) sont actualisés et bien à jour. De ce point de vue, les auteur(e)s doivent pointer vers une documentation générale plutôt que vers des pages spécifiques.
-- Les liens qui renvoient vers des articles utilisent des identifiants DOI, si ceux-ci sont disponibles.
-
-Pour s'adresser à un public international, il faut inviter les auteur(e)s à se conformer aux instructions suivantes dans la mesure du possible:
-
-- Lorsque vous effectuez les choix de vos méthodes ou vos outils, merci de garder à l'esprit que le lectorat est multilingue. Cela est particulièrement important pour les méthodes d'analyse textuelle ou dans les cas où les utilisateurs et utilisatrices peuvent avoir besoin d'aide pour des jeux de données avec des caractères spécifiques (caractères accentués, non-latins etc).
-- Au moment du choix des sources primaires, des images, des graphiques ou des captures d'écran, merci de penser à leur perception par un public international.
-- Lorsque vous écrivez, merci d'éviter les blagues, les références culturelles, les jeux de mots, les idiomatismes, le sarcasme, les émojis ou un langage trop sophistiqué. Si des personnes, des organisations ou des détails historiques sont mentionnés, merci de fournir du contexte, car votre lectorat peut ne pas vivre dans votre pays ou parler votre langue.
-- Dans les exemples qui fournissent du code ou des métadonnées, merci d'utiliser des formats standard internationaux pour les dates et l'heure ([ISO 8601:2004](https://www.iso.org/standard/40874.html). Dans le texte, nous vous remercions par avance de rester vigilant(e) sur les différences culturelles dans la représentation des dates et de l'heure qui pourraient générer de la confusion.
-- Lorsque cela est possible, optez pour des méthodes et des outils qui disposent d'une documentation multilingue. Si cela n'est pas possible, il serait pertinent d'ajouter certaines références multilingues à la fin de votre tutoriel.
-
-Les rédacteurs et les rédactrices doivent travailler en étroite collaboration avec les auteur(e)s pour s'assurer que ces critères sont remplis. Quand cela n'est pas possible, il faut clairement en expliquer les raisons dans le ticket de suivi éditorial correspondant.
-
-### D) Vérifier les images
-
-Toutes les images doivent porter des noms de fichiers cohérents qui décrivent ce qu'elles représentent. Si une leçon comporte un grand nombre d'images qui se succèdent, l'ordre peut être important (par exemple, une série de prises d'écran). Dans ce cas, il est conseillé d'appliquer un système de nommage de fichiers séquentiel, en utilisant dans l'idéal le nom de fichier de la leçon (ou alors une version abrégée si le titre est trop long), numéroté dans chaque cas pour indiquer l'image (par exemple, `counting-frequencies-1.png`, `counting-frequencies-2.png` et ainsi de suite).
-
-Si une leçon utilise un système de nommage d'images séquentiel, il est possible que la numérotation des images se modifie pendant la procédure d'évaluation par les pairs. Avant la publication d'une leçon, nous demandons que tous les noms de fichiers soient mis à jour avec les bons numéros de d'images. Le cas échéant, cela facilite aussi la future mise à jour des leçons. Merci de nous aider, de cette manière, à assurer la pérennité du *Programming Historian en français*.
-
-Nonobstant le type de nommage des images, sémantique ou séquentiel, celles-ci doivent être placées dans un sous-répertoire du répertoire `images`. Ce dossier doit être nommé suivant le nom du fichier et de l'URL de la leçon. Merci de vous assurer que les images ont des formats appropriés pour une publication sur le web tel que PNG ou JPEG et ont les bonnes dimensions (à la fois en pixels et en bytes).
-
-Des instructions complètes pour ajouter des images sont disponibles dans les [consignes aux auteur(e)s pour les dépôts des leçons](/fr/consignes-auteurs).
-
-### E) Vérifier les fichiers des données
-
-Comme les images, tous les fichiers des données doivent être hébergés sur le site, plutôt que d'être accessibles via des liens externes, pour en assurer la pérennité. Toutes les données doivent être stockées dans le répertoire `assets` selon les mêmes règles citées plus haut, mais les auteur(e)s peuvent se sentir libres d'utiliser un titre descriptif pour le fichier de leurs données qui reflète son contenu:
-
- - `/assets/LESSON-SLUG/Louvre-Paintings-1.csv`
-
-À l'occasion, certaines leçons peuvent requérir des fichiers de données d'une taille qui dépasse les capacités de notre dépôt GitHub. Lorsque c'est le cas, nous recommandons que les auteurs/autrices téléversent leurs données sur [Zenodo](https://zenodo.org/) pour assurer leur archivage pérenne et que le DOI généré par Zenodo soit fourni au rédacteur ou à la rédactrice pour lier le jeu de données au texte de la leçon. Nous recommandons le téléversement sur Zenodo de la version du jeu de données utilisée dans la leçon même lorsqu'une version de ce jeu de données existe déjà dans un dépôt institutionnel, afin d'uniformiser les procédures d'utilisation pour l'ensemble de nos leçons. Le rédacteur ou la rédactrice s'assurera que l'auteur ou l'autrice soit en mesure de naviguer dans l'interface de Zenodo, qui est disponible seulement en anglais, et lui offrira son soutien s'il ou elle ne connaît pas cette langue.
-
-Si l'ensemble des actifs à téléverser sur Zenodo dépasse les 25 Mo, tous les fichiers (même s'il y en a un seul) devront être compressés dans une archive .zip au préalable. Cette archive devrait porter le même nom que le fichier qui contient le texte de la leçon.
-
-### F) Vérifier les vidéos et les gifs
-
-L'utilisation de vidéos et de gifs n'est pas vraiment recommandée car elle peut générer plusieurs problèmes. Par exemple, cela prend beaucoup de temps et d'énergie de demander des modifications sur une vidéo pendant la procédure d'évaluation par les pairs. Il est par ailleurs impossible pour l'équipe de rédaction d'effectuer des mises à jour au fil des années pour que la vidéo reste actuelle. En outre, les vidéos nécessitent aussi l'administration d'une chaîne distincte sur YouTube. Enfin, elles ne sont pas imprimables, or beaucoup de nos lecteurs utilisent des copies en PDF ou [des imprimés du *Programming Historian*](https://zenodo.org/record/49873#.V0lazGaGa7o). Dans ces conditions, les vidéos devraient être utilisées SEULEMENT lorsque cela s'avère absolument nécessaire.
-
-Si un tutoriel contient une vidéo, celle-ci doit être hébergée sur notre chaîne YouTube. À ce jour, cette dernière n'est pas configurée, merci donc d'envoyer un courriel au reste de l'équipe de rédaction lorsque vous recevez une vidéo. Une copie de sauvegarde du fichier devrait aussi être placée dans notre dépôt Github, suivant les mêmes principes de nommage et de stockage qui sont valables pour les images et les données, décrites plus haut, pour faire partie du répertoire 'assets':
-- `/assets/SLUG-DE-LA-LECON/NOM-DE-FICHIER-ICI-3`
-
----
-
-## Acceptation et publication - Liste de vérification éditoriale
-
-Lorsque vous et l'auteur(e) trouvez le tutoriel satisfaisant, l'étape suivante est de transférer la leçon depuis le site des soumissions à notre dépôt principal qui héberge le site web live.
-
-### 1) Créer une biographie d'auteur(e)
-
-Si l'auteur(e) de la leçon apparaît pour la première fois, il appartient au rédacteur ou à la rédactrice d'ajouter les informations concernant la personne dans le [répertoire des auteur(e)s](https://github.com/programminghistorian/jekyll/blob/gh-pages/_data/ph_authors.yml) du site. Merci de respecter la syntaxe des exemples qui se trouvent dans le fichier:
-
-```yaml
-- name: Jim Clifford
-  team: false
-  bio:
-      fr: |
-          Jim Clifford est professeur adjoint au Département d'histoire de l'Université de la Saskatchewan.
-```
-
-**L'espace blanc est important**, merci donc de faire attention à ce que l'indentation suive le reste des exemples.
-
-Indiquer l'identifiant `orcid` n'est pas obligatoire, nous vous encourageons toutefois fortement de le faire, si les auteur(e)s en ont créé un dans le répertoire ORCID (https://orcid.org/). **Néanmoins, merci de prendre soin d'utiliser un identifiant ORCID fourni explicitement par l'auteur(e). Évitez par conséquent de le faire sans la confirmation préalable de l'auteur(e) qu'il s'agit du bon identifiant.**
-
-### 2) Ajouter une table de matières à la leçon
-
-Le code suivant doit être ajouté au texte de la leçon, habituellement avant le premier sous-titre:
-
-```
-{% raw %}{% include toc.html %}{% endraw %}
-```
-
-### 3) Ajouter les métadonnées en YAML dans le fichier de la leçon
-
-```
-title: "Votre Titre"
-collection: lecons
-layout: lesson
-slug: par ex. introduction-analyse-des-sentiments
-date: AAAA-MM-JJ
-translation_date: AAAA-MM-JJ (champ spécifique aux traductions)
-authors:
-- Prénom Nom
-- Prénom Nom, etc
-reviewers:
-- Prénom Nom
-- Prénom Nom, etc
-editors:
-- Prénom Nom
-translator:
-- Prénom Nom (champ spécifique aux traductions)
-translation-editor:
-- Prénom Nom (champ spécifique aux traductions)
-translation-reviewer:
-- Prénom Nom (champ spécifique aux traductions)
-original: slug to original published lesson (champ spécifique aux traductions)
-review-ticket: e.g. https://github.com/programminghistorian/ph-submissions/issues/108
-difficulty: voir ci-dessous
-activity: UNIQUEMENT UN PARMI: acquiring, transforming, analyzing, presenting, sustaining
-topics:
- - sujet un (voir ci-dessous)
- - sujet deux
-abstract: |
-  voir ci-dessous
-avatar_alt: Description de l'image de la leçon
-```
-
-- **difficulty** Pour aider les lecteurs et les lectrices repérer les leçons qui conviennent mieux à leur niveau de besoins et de compétences, le fichier YAML du tutoriel contient une information de type "Recommandé aux utilisateurs de niveau __ ". Il existe à l'heure actuelle trois niveaux définis qui sont codés comme suit: 1 (débutant), 2 (intermédiaire), 3 (avancé). Pour insérer cette information dans le fichier YAML, merci d'ajouter:
-
-```yaml
-difficulty: 2
-```
-- **topics** peut correspondre à tout ce qui est listé sous "type:" dans le fichier /\_data/topics.yml. Nous vous invitons aussi à créer de nouveaux sujets qui peuvent faciliter la découverte des leçons. Pour ce faire, en plus de noter le(s) sujet(s) dans l'en-tête de la leçon, il faudrait encore:
-1. Indexer aussi, en utilisant le nouveau sujet, toutes les anciennes leçons que celui-ci sert à décrire également.
-2. Ajouter le nouveau sujet - ou plus le cas échéant - dans le fichier /\_data/topics.yml en respectant le format suivi pour les autres sujets (merci de noter que les espaces blancs ne sont pas permis-utiliser des traits d'union si nécessaire).
-3. Modifier le fichier /js/lessonfilter.js pour que le classement de la page de la leçon par sujet puisse prendre effet. Rechercher dans le fichier la partie du code à dix lignes qui commence par "$('#filter-api')", remplacer les *deux* occurrences de "api" avec votre nouveau sujet.
-- **abstract** est une description de deux à trois phrases sur l'apport de la leçon. Merci d'éviter autant que possible les termes techniques car ces résumés s'adressent aux universitaires qui n'ont pas de connaissances techniques et il s'agit précisément de les convaincre de tester de nouvelles méthodes.
-- **slug** doit reproduire le chemin vers la leçon tel qu'il s'affiche sur le site web public du PH, à savoir le texte avec traits d'union qui suit l'adresse programminghistorian.org/lessons/ (par exemple, building-static-sites-with-jekyll-github-pages)
--**date** Mettez à jour la date dans le fichier YAML pour indiquer quand la leçon a été transférée dans le dépôt de jekyll et intégrée au site web principal.
-
-### 4) Trouver une image pour représenter une leçon
-Pour illustrer nos leçons, nous utilisons des images anciennes qui nous semblent représentatives du contenu des tutoriels. L'ensemble de ces images se trouve dans le répertoire des leçons. Ces images sont choisies par les rédacteurs et les rédactrices.
-
-Ci-dessous quelques sites pour chercher des images:
-
- - [Gallica](https://gallica.bnf.fr)
- - [Europeana](https://www.europeana.eu)
- - The [Virtual Manuscript Library of Switzerland](https://www.flickr.com/photos/e-codices)
- - The [British Library](https://www.flickr.com/photos/britishlibrary)
- - The [Internet Archive Book Images](https://archive.org/details/bookimages)
- - The [Library of Congress Maps](http://www.loc.gov/maps/collections)
-
-
-Merci de prendre soin de trouver une image dont le style est proche de celles déjà utilisées, donc pas de photographie, mais plutôt une image d'illustration de livre, de taille minimale de 200x200 pixels, sans restriction de droits de copyright. Merci de faire attention à ce que les images ne heurtent pas les sensibilités et, en conformité à notre [engagement en faveur de la diversité](/posts/PH-commitment-to-diversity), qu'elles ne reproduisent pas de stéréotypes sexistes ou raciaux.
-
-Par la suite, il faut sauvegarder l'image originale. Le nom du fichier doit être le même que celui de la leçon correspondante, et donc correspondre aussi au slug de son URL, suivi de `-original` à la fin. Le fichier doit être en format `.png`. Prenant pour exemple la leçon “Cleaning Data with OpenRefine”, le texte (slug) de son URL est `cleaning-data-with-openrefine`, par conséquent le nom de fichier de l'image de la leçon doit être `cleaning-data-with-openrefine-original.png`. 
-
-Il faut ensuite créer une nouvelle copie de l'image. Découpez-la en carré en préservant l'essentiel de la représentation puis modifiez la résolution en 200x200 pixels et convertissez-la en mode niveaux de gris. Si besoin, faites des réajustements pour que l'image soit conforme à celles des autres leçons au niveau de la luminosité ou des contrastes. Cette nouvelle image doit être sauvegardée dans un fichier nommé selon le texte de l'URL de la leçon sans oublier que **le format doit être en png**. Pour reprendre notre exemple précédent, le nom de ce fichier serait donc `cleaning-data-with-openrefine.png`.
-
-Le fichier de l'image originale doit être téléchargé dans le répertoire [gallery/originals](https://github.com/programminghistorian/jekyll/tree/gh-pages/gallery/originals), celui de l'image modifiée dans le répertoire [gallery](https://github.com/programminghistorian/jekyll/tree/gh-pages/gallery). Notez que, s'il s'agit d'une traduction, aucune démarche n'est nécessaire quant à l'image originale. 
-
-### 5) Prévenir le rédacteur ou la rédactrice en chef pour publier
-
-Le rédacteur ou la rédactrice en chef est en charge de la publication de la leçon en déposant les fichiers sur le site web principal et en faisant les vérifications finales. Pour lui faciliter la tâche, merci de publier une liste dans le ticket de la soumission de tous les fichiers à transférer d'un dépôt à l'autre. Habituellement il s'agit:
-
-- du fichier .md de la leçon;
-- du répertoire de fichiers supplémentaires le cas échéant (images, données etc)
-- Les icônes de galerie
-- Une bio d'auteur(e) si la personne apparaît pour la première fois
-
-Mise à part la bio, le reste des éléments devrait exister sous forme de fichiers dans le dépôt `ph-submissions`. La bio peut être insérée directement dans le ticket.
-
-### 6) Intégrer votre leçon dans notre bot Twitter
-La campagne de promotion sur Twitter, dont les étapes sont décrites ci-dessous, utilise aussi un bot pour faire une communication régulière sur les leçons plus anciennes. Pour y ajouter une nouvelle, vous remplissez une ligne dans [ce fichier](https://docs.google.com/spreadsheets/d/1o-C-3WwfcEYWipIFb112tkuM-XOI8pVVpA9_sag9Ph8/edit#gid=1625380994). Normalement, tous les membres de l'équipe éditoriale doivent pouvoir modifier le tableur. En cas de problème, merci de faire un courriel au groupe Google. Il vous faut ajouter une nouvelle ligne pour votre leçon ) la fin du fichier avec les champs suivants:
-
-* message_one (column A) - un message pour twitter qui est publié au début de la semaine.
-* message_two (column B) - un message twitter de type "Si vous avez raté cela" qui est publié plus tard la semaine.
-* link (column C) - le lien vers la leçon.
-
-Laissez la colonne D vide sans intervenir - ce champ est utilisé par le bot pour enregistrer son progrès à travers la liste. Par ailleurs, cette étape ne remplace pas votre propre promotion de la leçon. Le bot relève les leçons de manière aléatoire une fois par semaine, ce qui signifie que votre leçon pour mettre plusieurs mois avant d'avoir son tweet.
-
-### 7) Remerciements et promotion de la communication
-Il est important d'envoyer un message à toutes les personnes impliquées pour les remercier de leur contribution. En particulier, il faut remercier l'auteur(e) et lui proposer des pistes pour faire la communication autour du cours. Les leçons les plus populaires bénéficient en règle générale de l'énergie investie par leurs auteur(e)s. À titre d'exemple, il est possible d'inviter les auteur(e)s à:
-
-- Tweeter au moins trois fois sur la leçon (en fournissant le lien)
-- Retweeter nos tweets autour de leur leçon (seulement "liker" un tweet n'aide pas à disséminer le message)
-- Faire la promotion de leur leçon dans le cadre de présentations ou de publications de leur recherche
-- Pointer vers la ressource à partir d'un blog quand le cadre s'y prête
-- Ajouter la leçon aux listes de ressources des dépôts appropriés (par exemple, Wikipédia, pages de groupes etc)
-
-Les leçons sont le fruit d'un investissement considérable, faisons donc de notre mieux pour que les gens puissent les découvrir!
-
-# Liste de vérification du rédacteur ou de la rédactrice en chef
-
-Le rédacteur ou la rédactrice en chef a la responsabilité de déposer les fichiers sur le site web principal via un "pull request". Cela lui permet aussi de prendre connaissance de la nouvelle leçon et de vérifier rapidement que tout se présente bien.
-
-## 1) Parcourir l'aperçu de la soumission
-
-Vérifiez l'aperçu de la soumission pour repérer des erreurs manifestes, comme des problèmes d'affichage des images ou de formatage. Prévenez-en, le cas échéant, le rédacteur ou la rédactrice en charge de la leçon pour les corriger.
-
-## 2) Solliciter un identifiant DOI
-
-Prenez soin de solliciter un nouveau DOI pour la leçon selon les instructions du Wiki. L'obtenir ne devrait pas vous prendre plus d'un jour ou deux, en fonction du décalage horaire entre votre pays de résidence et le Royaume-Uni (UTC +1). Vous pouvez commencer à réaliser les étapes suivantes en attendant, sachez toutefois que le processus de modification de la page (build) échouera tant que le DOI n'aura pas été ajouté aux metadonnées.
-
-## 3) Transférer les fichiers
-
-Le rédacteur ou la rédactrice aurait dû vous laisser une liste claire, dans le ticket de la soumission, avec les fichiers à être publiés. Si ce n'est pas le cas, demandez que cela s'arrange avant d'aller plus loin.
-
-Il existe différentes manières de faire un "pull request" pour publier les fichiers:
-
-* A) Suivre nos [consignes pour faire des contributions techniques](https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions) via l'interface GUI de Github.
-
-* B) Utiliser `git` depuis la ligne de commande. Les instructions suivantes supposent que vous avez déjà cloné les dépôts `jekyll` and `ph-submissions` en local sur votre machine. Notre [leçon sur l'utilisation de l'application GitHub Desktop](/lessons/getting-started-with-github-desktop) peut vous être utile, si cela est tout nouveau pour vous. Si vous n'êtes pas confiant(e) sur comment procéder ou si vous avez des questions, merci de contacter l'équipe technique pour obtenir de l'aide.
-
-
-1. Aller au répertoire de votre dépôt local `ph-submissions`.
-2. Faire `git pull` pour obtenir le transfert de toutes les modifications récentes sur votre machine (ou faire `sync` si vous utilisez GitHub Desktop).
-3. Répéter les étapes 1 et 2 pour le dépôt `jekyll` sur votre machine.
-4. Copier les fichiers des leçons et ceux des images et ressources associées depuis le dépôt `ph-submissions` de votre machine aux endroits appropriés dans le répertoire de `jekyll`, toujours sur votre machine (il est possible d'utiliser la commande `cp` depuis la ligne de commande Unix ou naviguer dans l'arborescence de fichiers de votre interface graphique si vous utilisez GitHub Desktop).
-5. Depuis le répertoire `jekyll` qui se trouve en local sur votre machine, exécuter `git add` pour les nouveaux fichiers puis `git commit` et `git push` pour soumettre et envoyer les modifications.
-
-Après le transfert de la leçon dans le répertoire `jekyll`, il faudra aussi archiver la version soumise au dépôt `ph-submissions`.
-
-1. Aller au répertoire `ph-submissions` de votre dépôt local.
-2. Ajouter une nouvelle ligne à l'en-tête YAML de la leçon qui est désormais publiée: `redirect_from: "/lessons/SLUG-DE-LA-LEÇON"`
-3. Copier la leçon publiée depuis `lessons/` vers `lessons/published/`.
-4. Copier le dossier qui contient les images de la leçon publiée depuis `images/` vers `images/published/`.
-5. Exécuter les commandes `git add`, `git commit` et `git push` pour finaliser toutes les modifications.
-
-## 4) Vérifier les liens et les en-tête en YAML
-
-Une fois que vous aurez soumis vos modifications à la branche `gh-pages` du dépôt du [programminghistorian][ph_repo], le site web sera automatiquement testé par [GitHub Actions].
-Cette procédure teste trois choses. D'abord, que tout le code en YAML et markdown peut être parsé. Ensuite, que tous les hyperliens du site web pointent vers des pages valides et opérationnelles. Enfin, que les liens internes pointant vers des pages du _Programming Historian_ sont des liens relatifs qui commencent par `/` plutôt que par `https://programminghistorian.org/`
-
-[ph_repo]: https://github.com/programminghistorian/jekyll
-
-[GitHub Actions]: https://github.com/features/actions
-
-Ces opérations visent principalement à vérifier si des URL qui _par le passé_ ont été valides le restent _toujours_ car, souvent, les pages externes au site changent d'adresse ou ne sont plus alimentées.
-Elles offrent en outre un excellent moyen pour repérer des coquilles qui auraient pu échapper à l'attention des auteur(e)s, rédacteur(trice)s et évaluateur(trice)s.
-L'état de ces tests, couramment appelé _"Build Status"_ sur GitHub, peut être vérifié en naviguant sur la [page du dépôt du programminghistorian][ph_repo] et en cliquant sur "Commits" en haut à gauche du menu du code.
-
-![GitHub commit menu location](/images/website/editor-guidelines/gh_commits_location_screen.png)
-
-Ainsi, vous pouvez voir la liste de toutes les modifications effectuées sur le dépôt principal, tout comme une icône qui en montre l'état:
-
-- Coche verte: c'est bon! Tous les liens d'une page ont été vérifiés et sont valides. [**Vous pouvez ignorer la partie de la section qui suit**](#5-tenir-au-courant-le-rédacteur-ou-la-rédactrice-en-charge-du-suivi-éditorial-de-la-leçon)
-- Cercle jaune: votre dernière modification est toujours en cours d'enregistrement. Attendez quelques minutes avant de vérifier à nouveau.
-- X rouge: il y a eu une erreur dans l'enregistrement de la modification.
-
-Si votre compilation a échoué, il est nécessaire de consulter l'historique pour en repérer la cause.
-
-1. Cliquer sur l'icône X rouge qui correspond à la modification la plus récente (elle apparaît au plus haut de la page) puis cliquer sur le lien "Details".
-![Travis details location](/images/website/editor-guidelines/commit_list_screen.png)
-2. Vous serez ainsi dirigés vers la page de l'historique des compilations sur GitHub Actions. Les compilations sont habituellement longues de plusieurs centaines de lignes, mais il faut descendre pour trouver l'information sur l'erreur. Cliquez donc sur le petit cercle gris qui se trouve en haut à droite de l'affichage de l'historique pour afficher le bas de la page.
-![The top of the Travis CI build screen](/images/website/editor-guidelines/travis_top_screen.png)
-3. Il existe deux types d'erreurs: d'abord, si un des champs requis en YAML est manquant (par exemple, si une leçon n'a pas de champ `editors`), cela apparaîtra en rouge. Les liens qui ne marchent pas seront aussi affichés en rouge et regroupés selon la page à laquelle ils apparaissent. Si des liens de votre leçon renvoient des erreurs, il vaut mieux vérifier à nouveau qu'il n'y a pas de fautes dans l'adresse. Si c'est le cas, il faut faire les corrections nécessaires puis soumettre les modifications au dépôt et attendre que GitHub Actions lance de nouveaux tests.
-![Locating error details in Travis CI build results](/images/website/editor-guidelines/travis_bottom_screen.png)
-
-- Plus rarement, un lien qui échoue sur GitHub Actions peut parfaitement fonctionner lorsque vous vous y rendez à partir de votre propre navigateur. Si cela arrive, merci de [créer un nouveau ticket] pour que l'un des membres de l'équipe technique puisse travailler sur le problème pour trouver une solution.
-- Dans le cadre de ces opérations habituelles, GitHub Actions ira occasionnellement vérifier des liens de tout le site y compris ceux d'anciennes leçons. Ainsi, il est possible de voir une erreur qui est causée non pas par votre leçon, mais par une autre page. Si vous avez la possibilité de corriger ces erreurs dans l'immédiat, merci de le faire puis d'attendre qu'une nouvelle compilation se fasse. S'il vous est impossible de vérifier ces autres liens, merci de vérifier que les erreurs ne viennent pas de votre leçon et, par la suite, [créer un nouveau ticket] pour qu'un autre membre de l'équipe technique puisse s'occuper du problème.
-
-[créer un nouveau ticket]: https://github.com/programminghistorian/jekyll/issues/new
-
-## 5) Tenir au courant le rédacteur ou la rédactrice en charge du suivi éditorial de la leçon
-
-Lorsque la leçon a été publiée, merci d'en informer le rédacteur ou la rédactrice qui en a assuré le suivi éditorial.

From ebe27b11eb0ffa869cb6d375aa2e14d4b1619ba7 Mon Sep 17 00:00:00 2001
From: Anisa Hawes <87070441+anisa-hawes@users.noreply.github.com>
Date: Fri, 2 May 2025 17:08:44 +0100
Subject: [PATCH 05/13] Update guia-editor.md

Adjust `original:`
---
 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 ef97d3d36..ba0ae3da3 100644
--- a/es/guia-editor.md
+++ b/es/guia-editor.md
@@ -1,7 +1,7 @@
 ---
 title: Guía para editores
 layout: blank
-original: editor-guidelines
+original: publishing-workflow
 ---
 
 # Guía para editores

From a369365d9908ccee39809a181443b8c8f5ea9182 Mon Sep 17 00:00:00 2001
From: Anisa Hawes <87070441+anisa-hawes@users.noreply.github.com>
Date: Fri, 2 May 2025 17:09:14 +0100
Subject: [PATCH 06/13] Update directrizes-editor.md

Adjust `original:`
---
 pt/directrizes-editor.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pt/directrizes-editor.md b/pt/directrizes-editor.md
index d866c9672..32964bbe4 100755
--- a/pt/directrizes-editor.md
+++ b/pt/directrizes-editor.md
@@ -1,7 +1,7 @@
 ---
 title: Directrizes para editores
 layout: blank
-original: editor-guidelines
+original: publishing-workflow
 ---
 
 # Diretrizes para editores

From 58ea1c74195c48869a26ca9f91a29a1431e546df Mon Sep 17 00:00:00 2001
From: Anisa Hawes <87070441+anisa-hawes@users.noreply.github.com>
Date: Fri, 2 May 2025 17:10:33 +0100
Subject: [PATCH 07/13] Update publishing-workflow.md

Add `redirect_from:`
---
 en/publishing-workflow.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/en/publishing-workflow.md b/en/publishing-workflow.md
index 507726686..0f01410a9 100644
--- a/en/publishing-workflow.md
+++ b/en/publishing-workflow.md
@@ -1,6 +1,7 @@
 ---
 title: Publishing Workflow
 layout: blank
+redirect_from: /editor-guidelines
 ---
 
 {% include toc.html %}

From a063f57a253485cfa092cb8c0a5c1cfb0bee824d Mon Sep 17 00:00:00 2001
From: Anisa Hawes <87070441+anisa-hawes@users.noreply.github.com>
Date: Fri, 2 May 2025 17:23:31 +0100
Subject: [PATCH 08/13] Update snippets.yml

Adjust `menu-contribute-edit:`
---
 _data/snippets.yml | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/_data/snippets.yml b/_data/snippets.yml
index 365018bad..e8a6bdac3 100644
--- a/_data/snippets.yml
+++ b/_data/snippets.yml
@@ -179,14 +179,14 @@ menu-contribute-translate:
     link: /pt/directrizes-tradutor
 menu-contribute-edit:
   en:
-    title: Editor Guidelines
-    link: /en/editor-guidelines
+    title: Publishing Workflow
+    link: /en/publishing-workflow
   es:
     title: Guía para editores
     link: /es/guia-editor
   fr:
-    title: Consignes aux rédacteurs
-    link: /fr/consignes-redacteurs
+    title: Processus de Publication
+    link: /fr/processus-de-publication
   pt:
     title: Diretrizes para editores
     link: /pt/directrizes-editor

From dabcdc6fac0b6797b5d642756ce5df3f2f503de2 Mon Sep 17 00:00:00 2001
From: Anisa Hawes <87070441+anisa-hawes@users.noreply.github.com>
Date: Fri, 2 May 2025 17:36:39 +0100
Subject: [PATCH 09/13] Update index.md

consignes-redacteurs > processus-de-publication
---
 fr/index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fr/index.md b/fr/index.md
index fa172424a..e9112ba9c 100644
--- a/fr/index.md
+++ b/fr/index.md
@@ -30,7 +30,7 @@ title: The Programming Historian en français
 <div class="home-block home-stripe-2">
 <div class="container">
 <h2>Contribuer</h2>
-<p>Que vous souhaitiez <a href="{{ site.baseurl }}/fr/consignes-auteurs.html">écrire une leçon</a>, rejoindre notre <a href="{{ site.baseurl }}/fr/consignes-redacteurs">équipe de rédacteurs et rédactrices</a>, nous <a href="{{ site.baseurl }}/fr/reaction.html">faire un retour</a>, nous sommes constamment à l'écoute de notre lectorat! </p>
+<p>Que vous souhaitiez <a href="{{ site.baseurl }}/fr/consignes-auteurs.html">écrire une leçon</a>, rejoindre notre <a href="{{ site.baseurl }}/fr/processus-de-publication">équipe de rédacteurs et rédactrices</a>, nous <a href="{{ site.baseurl }}/fr/reaction.html">faire un retour</a>, nous sommes constamment à l'écoute de notre lectorat! </p>
 </div>
 </div>
 

From 3ad19ab77dc8455dc6f46943822bbe128eb116c9 Mon Sep 17 00:00:00 2001
From: Anisa Hawes <87070441+anisa-hawes@users.noreply.github.com>
Date: Fri, 2 May 2025 17:38:04 +0100
Subject: [PATCH 10/13] Update contribuer.md

consignes-redacteurs > processus-de-publication
---
 fr/contribuer.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fr/contribuer.md b/fr/contribuer.md
index b546a5f0f..df08e72e9 100644
--- a/fr/contribuer.md
+++ b/fr/contribuer.md
@@ -72,4 +72,4 @@ Merci de nous aider à améliorer le _Programming Historian en français_!
 
  [depot]: {{site.baseurl}}/fr/consignes-auteurs
  [evaluateurs]: {{site.baseurl}}/fr/consignes-evaluateurs
- [redacteurs]: {{site.baseurl}}/fr/consignes-redacteurs
+ [redacteurs]: {{site.baseurl}}/fr/processus-de-publication

From 66a152631791f2a3c6ae41c848ebd4f42739fc6a Mon Sep 17 00:00:00 2001
From: Anisa Hawes <87070441+anisa-hawes@users.noreply.github.com>
Date: Fri, 2 May 2025 17:42:44 +0100
Subject: [PATCH 11/13] Update apropos.md

consignes-redacteurs > processus-de-publication
---
 fr/apropos.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fr/apropos.md b/fr/apropos.md
index 4f5579c76..98973d4c1 100644
--- a/fr/apropos.md
+++ b/fr/apropos.md
@@ -10,7 +10,7 @@ original: about
 ## Évaluation par les pairs
 Tous les tutoriels du _Programming Historian en français_ sont rigoureusement évalués par des pairs, la procédure étant suivie par un rédacteur ou une rédactrice de notre équipe. L'évaluation implique des échanges approfondis avec la personne responsable de la leçon avant l'envoi aux experts externes pour s'assurer, d'une part, de la cohérence du tutoriel selon les objectifs préalablement fixés, d'autre part, que tous les concepts sont suffisamment explicites pour un lectorat non-spécialiste.
 
-Notre procédure d'évaluation par les pairs est un peu différente de celle qui peut être considérée comme traditionnelle. Nous ne sollicitons pas des expertises afin de juger si un tutoriel est "suffisamment bon" pour être publié. De notre point de vue, la procédure d'évaluation fait plutôt partie intégrale d'un effort collaboratif, productif et durable d'enseignement et d'apprentissage réciproque entre universitaires. Une fois qu'un tutoriel entre dans notre [flux éditorial]({{site.baseurl}}/fr/consignes-auteurs), nous ne nous épargnons aucun effort pour le rendre le plus utile possible et le publier dans des délais raisonnables. Merci de consulter nos [consignes aux rédacteurs]({{site.baseurl}}/fr/consignes-redacteurs) pour plus d'informations.
+Notre procédure d'évaluation par les pairs est un peu différente de celle qui peut être considérée comme traditionnelle. Nous ne sollicitons pas des expertises afin de juger si un tutoriel est "suffisamment bon" pour être publié. De notre point de vue, la procédure d'évaluation fait plutôt partie intégrale d'un effort collaboratif, productif et durable d'enseignement et d'apprentissage réciproque entre universitaires. Une fois qu'un tutoriel entre dans notre [flux éditorial]({{site.baseurl}}/fr/processus-de-publication), nous ne nous épargnons aucun effort pour le rendre le plus utile possible et le publier dans des délais raisonnables. Merci de consulter nos [processus de publication]({{site.baseurl}}/fr/processus-de-publication) pour plus d'informations.
 
 
 ## Open Source (code source ouvert)

From d1810b53575ba330f4d148608b6ce831af814487 Mon Sep 17 00:00:00 2001
From: Anisa Hawes <87070441+anisa-hawes@users.noreply.github.com>
Date: Fri, 2 May 2025 17:46:30 +0100
Subject: [PATCH 12/13] Update contribute.md

editor-guidelines > publishing-workflow
---
 en/contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/contribute.md b/en/contribute.md
index 1e3cc5431..905d54c4b 100755
--- a/en/contribute.md
+++ b/en/contribute.md
@@ -31,7 +31,7 @@ If you would like to contribute as a peer reviewer, please take a few minutes to
 <img src="{{site.baseurl}}/gallery/editor-guidelines.png" class="garnish rounded float-right" alt="{{ site.data.snippets.editor-guidelines-image-alt[page.lang] }}"/>
 
 
-Our editorial board members help facilitate peer review and work with authors closely to make improvements to their lessons. Our [guidelines for editors](editor-guidelines) is meant to ensure that everyone, from authors to reviewers to members of the wider community, receive a fair and consistent experience during peer review.
+Our editorial board members help facilitate peer review and work with authors closely to make improvements to their lessons. Our [publishing workflow](publishing-workflow) is meant to ensure that everyone, from authors to reviewers to members of the wider community, receive a fair and consistent experience during peer review.
 
 From time to time we may advertise that we are seeking more editors.
 

From 50d88d482de5384c610c77728947c6153270a03c Mon Sep 17 00:00:00 2001
From: charlottejmc <143802849+charlottejmc@users.noreply.github.com>
Date: Thu, 15 May 2025 09:38:40 +0200
Subject: [PATCH 13/13] Update publishing-workflow.md

Update order of steps in Phase 7
Try different bullet point formatting
---
 en/publishing-workflow.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/publishing-workflow.md b/en/publishing-workflow.md
index 0f01410a9..f3ffc99fe 100644
--- a/en/publishing-workflow.md
+++ b/en/publishing-workflow.md
@@ -83,4 +83,4 @@ Our publishing workflow moves through eight phases: **Proposal**, **Submission**
 
 | Who is responsible?                     | Expected timeframe                |   Process & activities               |
 | -------------------------------- | ------------------------------ | ------------------------------  |
-| Managing editor + publishing team (+ editor _post-publication_) | 14 days | <ul><li>Managing editor re-reads the lesson, to provide final feedback or suggest additional revisions.</li><li>Publishing manager stages files for publication.</li><li>Managing editor approves the lesson for publication.</li><li>Publishing team initiates announcement + schedule promotion of the new lesson.</li><li>Publishing team shares suggested citation + social media announcement links with all contributors to close the issue.</li></ul>
+| Managing editor + publishing team (+ editor _post-publication_) | 14 days | - Publishing Manager stages files for publication.<br>- Managing Editor re-reads the lesson, to provide final feedback or suggest additional revisions.<br>- Managing editor approves the lesson for publication.<br>- Publishing team initiates announcement + schedule promotion of the new lesson.<br>- Publishing team shares suggested citation + social media announcement links with all contributors to close the issue.