-
Notifications
You must be signed in to change notification settings - Fork 229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shorten Editorial Guidelines - Issue 992 #999
Conversation
New text for translating: ## Acceptance and Publication - Editorial Checklist Once you and the author are happy with a tutorial, the next step is to begin the publication process. ... ### 3) Add YAML metadata to the lesson file title: ["YOUR TITLE HERE"] collection: lessons layout: lesson slug: [e.g. sentiment analysis] date: [YYYY-MM-DD] translation_date: [YYYY-MM-DD (translations only)] authors: - [FORENAME SURNAME 1] - [FORENAME SURNAME 2, etc] reviewers: - [FORENAME SURNAME 1] - [FORENAME SURNAME 2, etc] editors: - [FORENAME SURNAME] translator: - [FORENAME SURNAME (translations only)] translation-editor: - [FORNAME SURNAME (translations only)] translation-reviewer: - [FORNAME SURNAME (translations only)] original: [slug to original published lesson (translations only)] review-ticket: [e.g. programminghistorian/ph-submissions#108] difficulty: [see guidance below] activity: [ONE OF: acquiring, transforming, analyzing, presenting, sustaining] topics: [see guidance below] abstract: [see guidance below] - **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 to the lesson, include the following in the YAML file: - **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. ... ### 6) Inform the Managing Editor to Publish 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 ... # Managing Editor Checklist The Managing Editor is responsible for moving the files to the main website via a pull request. This is also a chance for the managing editor to familiarize him/herself with the new lesson, and to quickly check that everything looks ok. ## 1) Look over the submission preview Check the submission preview for any obvious errors such as broken images or strange formatting. Inform the editor of any mistakes, which they are responsible for getting fixed. ... ## 4) Inform the Editor Once the lesson has been published, inform the editor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a few backticks and url formatting, but I think the rest looks good to me.
Requires a close read by a Spanish speaker.
Sorry @mdlincoln I couldn't figure out what you did to the formatting, so I couldn't replicate it on the Spanish Editor's guidelines which I've just updated in the same way. This now needs a really careful check by a Spanish speaker to make sure I haven't screwed up the Spanish guidelines. It should be the same, except:
Can one of @mariajoafana @vgayolrs @jenniferisasi @jamotilla check that it does do that? Then we can merge once @mdlincoln is happy with the formatting. |
@mdlincoln how do we do a preview link so it's easier for someone to check over? |
I note this for the FR editorial guidelines to be modified accordingly |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Line 242 (Paragraph starting with "Es muy importante acreditar ... in English "It is importante that we acknowledge...") was eliminated from English version but not form Spanish version.
Line 246 can be erased.
Line 292: erase "tal y como se muestra aquí"
Thanks @mariajoafana I have made those changes. If you're happy can you approve the pull request? |
I'm going to approve this |
Closes #992
As per our discussion, this reduces the length of the editorial guidelines by condensing the instructions on checking the YAML header, and moves some responsibilities for pull requests to the "Managing Editor".
I have only done this for the ENGLISH page. Can someone please look over it in ENGLISH and if we're happy I will do my best to fix the Spanish page too, to save everyone work. Please do not merge this until we also have the Spanish page ready.