diff --git a/en/author-guidelines.md b/en/author-guidelines.md index 24facc7819..ef57cba55a 100755 --- a/en/author-guidelines.md +++ b/en/author-guidelines.md @@ -69,6 +69,7 @@ Upon acceptance, you agree to publish your lesson under a Creative Commons "[CC- * **Multi-lingual**: when choosing methods or tools, make choices with multi-lingual readers in mind – especially for textual analysis methods, which may not support other character sets or may only provide intellectually robust results when used on English texts. Where possible, choose approaches that have multi-lingual documentation, or provide multi-lingual references for further reading. This will help our translators. * **Racial and Ethnic Language**: use racial terminology carefully and with specificity. Historic terms no longer in use should be used only in their historical context and only when necessary. Use racial terms as adjectives and not nouns: white people rather than "whites", an Asian woman rather than "an Asian". Be aware that terms may be understood differently in different countries and what you have learned to be correct or sensitive may be culturally specific to your country (eg, not all people with African ancestry are "African Americans". Some of them are African, or black British, or Caribbean, etc). Likewise, readers in the UK will understand "Asian" (India, Pakistan, Bangladesh) differently than those in North America (eg China, Japan, Vietnam, Thailand). * **Visual Representations**: choose primary sources, images, figures, and screen shots, considering how they will present themselves to a global audience. +* **Computing resources**: if your lesson requires relatively substantial computing resources, include an alert warning after the Table of Contents to inform the readers. Please be specific and translate the requirements into real terms (e.g. "You need at least 8GB of RAM to finish this lesson", "This lesson uses large files (up to 2GB)", etc. ). State if readers need admin access to install software. ### Sustainable Writing *Programming Historian* publishes lessons for the long-term. Please follow these sustainability guidelines when writing: @@ -189,6 +190,16 @@ The guideline is to use them sparingly in the running prose. Specific rules: * Endnotes should not just contain a URL. * (Correct): Grove, John. "Calhoun and Conservative Reform." *American Political Thought* 4, no. 2 (2015): 203–27. https://doi.org/10.1086/680389. * (Incorrect): https://doi.org/10.1086/680389 +* In order to cite software, which requires citation as a condition of use within a lesson, please provide as much as possible from the information below, following the general "Notes and Bibliography” system found in the Chicago Manual of Style, 17th Edition for endnotes: + * author + * product name + * version number + * year of publication + * URL or DOI + + Eg. The Pandas Development Team. *pandas-dev/pandas: Pandas*. v. 1.2.3 (2020). https://doi.org/10.5281/zenodo.3509134 + + Please check each software official webpage or documentation for authors guidelines about how to cite their work (eg. https://pandas.pydata.org/about/citing.html, https://www.tidyverse.org/blog/2019/11/tidyverse-1-3-0/#citing-the-tidyverse). ### Challenging Words Explained @@ -323,6 +334,10 @@ You may find it helpful to read our [editor guidelines](/editor-guidelines), whi If at any point you are unsure of your role or what to do next, post a question to the peer review issue. One of our editors will respond as soon as possible. We endeavour to respond to all queries within a few days. +### What happens after your lesson is published? + +Occasionally, we receive feedback from users who have encountered an error while completing one of our lessons. If this happens, our Publishing Assistant will open an Issue on GitHub, then carry out an assessment to confirm whether the error reported represents a problem caused by the user (editing the lesson's code or changing its dataset, for example) or a problem within the lesson itself. If the latter, our Publishing Assistant will re-test the relevant part(s) of the lesson and undertake research to identify a fix. As part of this Lesson Maintenance process, we may contact you alongside other members of the *Programming Historian* team to ask for advice. In the case that no fix can be found, we will propose adding a warning to the lesson explaining that some users may encounter an error. Where possible, the warning should include links to further reading, empowering users to identify a solution themselves. + ### Holding Us to Account Our team of volunteers works hard to provide a rigourous, collegial, and efficient peer review for authors. However, we recognize that there are times when we may fall short of expectations. We want authors to feel empowered to hold us to high standards. If, for whatever reason, you feel that you have been treated unfairly, that you are unhappy or confused by the process, that the review process has been unnecessarily delayed, that a reviewer has been rude, that your editor has not been responsive enough, or have any other concern, please bring it to our attention so we can address it proactively. diff --git a/en/editor-guidelines.md b/en/editor-guidelines.md index dc00d2f04f..a6c878cf04 100755 --- a/en/editor-guidelines.md +++ b/en/editor-guidelines.md @@ -50,13 +50,13 @@ The main editorial contact for this lesson is [EDITOR USERNAME]. If there are an The editor is encouraged to adjust the issue text to reflect any additional goals or requirements agreed upon between the author(s) and editor. -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. +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. +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. @@ -188,9 +188,9 @@ Full instructions on adding images is available in [Author Submission Instructio 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. - + + 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 @@ -280,6 +280,7 @@ difficulty: 2 - **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 diff --git a/en/lessons/crowdsourced-data-normalization-with-pandas.md b/en/lessons/crowdsourced-data-normalization-with-pandas.md index f09705880a..e76b53f9f6 100644 --- a/en/lessons/crowdsourced-data-normalization-with-pandas.md +++ b/en/lessons/crowdsourced-data-normalization-with-pandas.md @@ -47,13 +47,13 @@ In "Making Crowdsourcing Compatible with the Missions and Values of Cultural Her Crowdsourcing participants should be compensated in some way. In macrotasking, competition systems are common, so not everyone who participates receives an award. In ["On the Ethics of Crowdsourced Research"](https://doi.org/10.1017/S104909651500116X), Venessa Williamson declares that many people participating in crowdsourced research (particularly Amazon's [Mechanical Turk](https://www.mturk.com/)) do not do this for fun in their leisure time. Contributors to this platform invest a significant amount of time, expertise, and resources but are paid very little (in the US, crowdsourced labor is not a protected form of labor). Williamson suggests crowdsourcing participants “set a minimum wage for their own research” and encourages accountability such as requiring companies to report the wages of workers compared to the number of hours worked. In addition, Williamson recommends organizations such as an [IRB](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/institutional-review-board-irb-written-procedures) create "guidelines for the employment of crowdsourced workers." If you consider crowdsourcing for a project, it is very important to develop and implement protocols to support and protect your workers. ### Things to Consider... -Crowdsourcing is not the best method for every project. For different types of projects, crowdsourcing [does not always produce the most accurate results](https://hbr.org/2019/12/why-crowdsourcing-often-leads-to-bad-ideas) and can lead to more work with the responses before it is possible to move on to addressing a research question. In crowdsourcing, participant researchers will have different levels of knowledge and experience, which can also lead to differences in the results. If you are organizing crowdsourced research, you also need to be aware of how much time the researchers are working on the project to make sure researchers are properly compensated. To determine if crowdsourcing is the best option for you, consider these questions, as outlined in ["How to Use Crowdsourcing Effectively: Guidelines and Examples"](https://www.liberquarterly.eu/articles/10.18352/lq.9948/), by Elena Simper: +Crowdsourcing is not the best method for every project. For different types of projects, crowdsourcing [does not always produce the most accurate results](https://hbr.org/2019/12/why-crowdsourcing-often-leads-to-bad-ideas) and can lead to more work with the responses before it is possible to move on to addressing a research question. In crowdsourcing, participant researchers will have different levels of knowledge and experience, which can also lead to differences in the results. If you are organizing crowdsourced research, you also need to be aware of how much time the researchers are working on the project to make sure researchers are properly compensated. To determine if crowdsourcing is the best option for you, consider these questions, as outlined in ["How to Use Crowdsourcing Effectively: Guidelines and Examples"](https://liberquarterly.eu/article/view/10758), by Elena Simperl: 1. **What should you crowdsource?** There are many tasks such as data entry, data classification, transcription, or the development and collection of ideas that can be crowdsourced easily with individuals worldwide. Many people with different ideas and skills can identify effective ways to address a specific issue or complex problem 2. **What is the scale of the work?** Crowdsourced projects are most successful when there are smaller pieces that individuals can address on their own. Is this possible for your project? -3. **Does the work outweigh the benefits?** Outsourcing smaller projects and items using crowdsourcing can be useful and cost-effective, but you will still need to spend time compiling the collected information and, in many cases, normalizing the data. If your project is large, this could be a lot of work and will mean people are not always using their time as productively as possible toward the project/team’s goals. As Simper noted, Google [announced a call](https://googleblog.blogspot.com/2009/09/announcing-project-10100-idea-themes.html) asking for public proposals. They received over 150,000 submissions and as a result, there was a long delay responding to individuals, with only 16 projects were chosen for further consideration +3. **Does the work outweigh the benefits?** Outsourcing smaller projects and items using crowdsourcing can be useful and cost-effective, but you will still need to spend time compiling the collected information and, in many cases, normalizing the data. If your project is large, this could be a lot of work and will mean people are not always using their time as productively as possible toward the project/team’s goals. As Simperl noted, Google [announced a call](https://googleblog.blogspot.com/2009/09/announcing-project-10100-idea-themes.html) asking for public proposals. They received over 150,000 submissions and as a result, there was a long delay responding to individuals, with only 16 projects were chosen for further consideration ### Best Practices for Researchers If you decide to collect data using crowdsourcing, there are some things to keep in mind and guidelines to understand. These are important for the protection of workers and also for quality control of the project. diff --git a/en/research.md b/en/research.md index 5619522385..41b32b6cee 100755 --- a/en/research.md +++ b/en/research.md @@ -92,4 +92,4 @@ The project team and members of the wider community are involved in a number of * Eva Pfanzelter, "Syllabus: Introduction to Digital Practice in the Historical Sciences", History Curriculum, University of Innsbruck, Austria, NewsEye H2020 Project (2021). * Kelly Fitzpatrick, "Caselaw Access Project", Harvard Law School (2019). * Paul Spence, Renata Brandao, "Digital Modern Languages Writing Sprint", Language Acts and Worldmaking (2019). -* James Baker, Caitlin Moore, Ernesto Priego, Raquel Alegre, Jez Cope, Ludi Price, Owen Stephens, Daniel van Strien, Greg Wilson, '[Library Carpentry: software skills training for library professionals](https://www.liberquarterly.eu/articles/10176/)', _Liber Quarterly: The Journal of the Association of European Research Libraries_, 26(3) (2016). +* James Baker, Caitlin Moore, Ernesto Priego, Raquel Alegre, Jez Cope, Ludi Price, Owen Stephens, Daniel van Strien, Greg Wilson, '[Library Carpentry: software skills training for library professionals](https://liberquarterly.eu/article/view/10847)', _Liber Quarterly: The Journal of the Association of European Research Libraries_, 26(3) (2016). diff --git a/es/guia-editor.md b/es/guia-editor.md index 7a7464450c..a4267fb9c8 100644 --- a/es/guia-editor.md +++ b/es/guia-editor.md @@ -36,15 +36,15 @@ Una vez se ha aceptado una propuesta de lección, el editor aclarará al autor c A continuación, el editor creará un *issue* en el [repositorio de GitHub](https://github.com/programminghistorian/ph-submissions/issues) con la etiqueta “proposals” para las nuevas lecciones. La plantilla viene incluida por defecto en el *issue*, pero también se puede copiar el texto que se encuentra más abajo. *The Programming historian* ha recibido una propuesta de lección con el título provisional ‘Título provisional de la lección’ por parte de ‘Nombre del autor o autores’. Los objetivos de la lección son: - + - objetivo nº1 - objetivo nº2 - objetivo nº3 - + A fin de promover una publicación a tiempo, se ha acordado que la lección se entregará en un plazo de [90 days por defecto o más tarde si se ha establecido así con el autor]. El autor o autores contactará con antelación con el editor si no puede cumplir con la fecha de entrega y necesita una ampliación. - + Si la lección no es entregada en la [fecha acordada], el editor intentará contactar con el autor o autores de la lección. Si no recibe noticias, el ticket se cerrará. Éste podrá abrirse en el futuro a petición del autor o autores. - + El principal contacto para esta lección es [nombre del editor]. Si se produce algún problema, el autor puede contactar con nuestros ’ombudsperson' (Silvia Gutiérrez De la Torre - http://programminghistorian.org/es/equipo-de-proyecto). Este texto, sin embargo, puede editarse y adaptarse a las necesidades para reflejar más objetivos o lo que se ha negociado entre el editor y el autor. @@ -53,7 +53,7 @@ Cuando los materiales de la lección estén listos para su envío, los autores s 1. **Subir la lección**: el archivo de la lección debe subirse en la subcarpeta apropiada en el [directorio de lecciones](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/es), dependiendo de si es una lección original o una traducción, y en la carpeta del idioma que corresponda. Si necesitas ayuda, dirígete a las [instrucciones de Github](https://help.github.com/articles/adding-a-file-to-a-repository/). 2. **Subir imágenes**: si la lección contiene imágenes, aseguráte de que todos los archivos sigan las convenciones para nombres de figuras e imágenes en la [guía para autores](/es/guia-para-autores). Quien edita la lección debe crear una carpeta para las imágenes en el [directorio *images*](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/images). Esta carpeta debe tener el mismo nombre que el archivo de la lección. Carga las imágenes en la carpeta. -3. **Subir archivos datos**: si la lección incluye archivos de datos, estos deben ser subidos a una carpeta con el mismo nombre del archivo de la lección en el [directorio *assets.*](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/assets) +3. **Subir archivos datos**: si la lección incluye archivos de datos, estos deben ser subidos a una carpeta con el mismo nombre del archivo de la lección en el [directorio *assets.*](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/assets) Después de subir todo, el/la editor/a debe comprobar que la carga de archivos recibe una marca verde de aprobación en [la historia del repositorio](https://github.com/programminghistorian/ph-submissions/commits/gh-pages). Si la marca no es verde, algo fue mal y entonces se debe consultar la [wiki](https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions#checking-travis-for-errors) para tratar de subsanar los errores existentes. Una vez que se haya cargado correctamente la lección, el/la editor/a creará un ticket de revisión para la lección y cerrará el *issue* de la propuesta. A partir de aquí, esta misma persona debe asegurarse de que el/la autor/a trabaje con la última versión de la lección en el repositorio y cargar los cambios directamente en GitHub. @@ -305,6 +305,7 @@ difficulty: 2 2. Agregar el o los nuevos tópicos en el archivo /\_data/topics.yml siguiendo el formato de los otros tópicos que ahí se encuentran (por favor, ten en cuenta que los tópicos no pueden contener espacios, así que utiliza guiones si es necesario). 3. Edita el archivo /js/lessonfilter.js para que funcione adecuadamente el botón que filtra la página de la lección con ese tópico. Busca en el archivo el fragmento de diez líneas de código que empieza con `$('#filter-api')`, copia y pega ese fragmento de código y reemplaza las dos veces que aparece "api" con tu nuevo tópico. - **abstract** es una descripción de una a tres frases sobre lo que se aprende en esa lección. Trata de evitar, en lo posible, un vocabulario técnico, para que estos resúmenes ayuden a los académicos sin un conocimiento técnico a probar nuevas cosas. +- Si la lección utiliza fórmulas, es necesario agregar `mathjax: true` para que estas se visualicen correctamente. Para las traducciones, no solo hay que añadir `translator`, `translation-reviewer`, `translation-editor` y `translation_date`. También hay que añadir el campo `original`: diff --git a/es/guia-para-autores.md b/es/guia-para-autores.md index ca4842e3ac..96e17e867e 100644 --- a/es/guia-para-autores.md +++ b/es/guia-para-autores.md @@ -10,9 +10,9 @@ skip_validation: true # Guía para autores {{ site.data.snippets.write-a-lesson-image-alt[page.lang] }} -

Paso 1: Proponer una nueva lección

-

Paso 2: Escribir y dar formato a una nueva lección

-

Paso 3: Enviar una nueva lección

+

Paso 1: Proponer una nueva lección

+

Paso 2: Escribir y dar formato a una nueva lección

+

Paso 3: Enviar una nueva lección

Estas directrices han sido desarrolladas para ayudarte a entender el proceso de creación de un tutorial para *Programming Historian* en Español. Incluyen detalles prácticos sobre el proceso de redacción de un tutorial, así como indicaciones sobre el flujo de trabajo y el proceso de revisión entre pares. Si en algún momento hay algo que no te queda claro, por favor envía un correo electrónico a {% include managing-editor.html lang=page.lang %}. @@ -124,8 +124,8 @@ Con estilo: * Acá está el último ítem ### Puntuación - * **Abreviaturas, acrónimos y siglas**: escribe la palabra completa la primera vez que la utilizas, por ejemplo, «Humanidades Digitales (HD)». Las siglas son invariables cuando se enunician en plural («las ONG») y adoptan el género de la palabra que constituye el núcleo de la expresión abreviada, que normalmente ocupa el primer lugar en la denominación: el FMI, por el «Fondo» Monetario Internacional; la OEA, por la «Organización» de Estados Americanos. Las siglas se escriben sin puntos o espacios en blanco como separación: RAE, OEA, etc. (no R.A.E. u O E A). Normalmente se escriben en mayúscula todas las letras que componen una sigla (OCDE, APA, ISO) y, en ese caso, no llevan nunca tilde, incluso en casos en que la norma ortográfica indicaría su uso (como en CIA). - * **Paréntesis**: se usa para insertar en un enunciado una información complementaria o aclaratoria, ej: El dijo: «Cuando lo acaben (el túnel) revolucionará la forma de viajar» or «Ella dijo goodbye (adios)». Ubica el punto fuera del paréntesis de cierre si lo que está dentro de él no es una oración completa (como este caso). (Una oración independiente, en cambio, lleva el punto final antes del paréntesis de cierre.) + * **Abreviaturas, acrónimos y siglas**: escribe la palabra completa la primera vez que la utilizas, por ejemplo, "Humanidades Digitales (HD)". Las siglas son invariables cuando se enunician en plural ("las ONG") y adoptan el género de la palabra que constituye el núcleo de la expresión abreviada, que normalmente ocupa el primer lugar en la denominación: el FMI, por el "Fondo" Monetario Internacional; la OEA, por la "Organización" de Estados Americanos. Las siglas se escriben sin puntos o espacios en blanco como separación: RAE, OEA, etc. (no R.A.E. u O E A). Normalmente se escriben en mayúscula todas las letras que componen una sigla (OCDE, APA, ISO) y, en ese caso, no llevan nunca tilde, incluso en casos en que la norma ortográfica indicaría su uso (como en CIA). + * **Paréntesis**: se usa para insertar en un enunciado una información complementaria o aclaratoria, ej: El dijo: "Cuando lo acaben (el túnel) revolucionará la forma de viajar" o "Ella dijo goodbye (adios)". Ubica el punto fuera del paréntesis de cierre si lo que está dentro de él no es una oración completa (como este caso). (Una oración independiente, en cambio, lleva el punto final antes del paréntesis de cierre.) * **Dos puntos**: se utilizan para introducir listas, ejemplificaciones, aclaraciones, citas textuales, etc., como en estos ejemplos: * El comité recomienda: ampliar las horas de licencia hasta la medianoche; permitir a los niños en los locales con licencia; relajar los controles de planificación en los nuevos establecimientos públicos. * Después de dos puntos va minúscula: así es como lo hacemos. @@ -134,12 +134,12 @@ Con estilo: * **Puntos suspensivos**: van pegados a la palabra que los precede y separados de la que los sigue. Cuando se utilizan para condensar una cita directa, van entre paréntesis o corchetes. * **Signos de exclamación**: se utilizan al comienzo y al final de la exclamación. * **Punto**: se escribe punto después de las abreviaturas, pero no de las siglas o acrónimos. - * **Comillas angulares**: en los textos impresos, se recomienda utilizar en primera instancia las comillas angulares « », (ejemplo: «Antonio me dijo: “Vaya ‘cacharro’ que se ha comprado Julián”»). Se reservan los otros tipos para cuando se debe entrecomiilar un texto ya entrecomillado. + * **Comillas**: se utilizan en primera instancia las comillas altas o inglesas (""). En caso de que se requiera entrecomillar un texto ya entrecomillado, se utilizan las comillas simples (''). ### Mayúsculas La pauta es usarlas con moderación en la prosa corriente. Reglas específicas: -* **Títulos**: los encabezados y títulos de libros llevan mayúscula en la primera letra del título: »Preparando los datos para el análisis»; *El orgullo y la pasión*. +* **Títulos**: los encabezados y títulos de libros llevan mayúscula en la primera letra del título: "Preparando los datos para el análisis""; *El orgullo y la pasión*. * **Siempre con mayúscula inicial**: * **Nombre propios**: William J. Turkel – a menos que la persona elija deletrear su nombre de otra manera (por ejemplo "bell hooks"). * **Organizaciones, organismos, entidades, partidos políticos, etc**: Museo de Arte Moderno, Casa de Cervantes, Biblioteca Nacional, Agencia Nacional de Tierras, Naciones Unidades. Las palabras de función dentro del nombre no llevan mayúsculas en estos casos. @@ -179,11 +179,20 @@ La pauta es usarlas con moderación en la prosa corriente. Reglas específicas: * Si estás escribiendo un tutorial de "análisis", debes referirte a la literatura académica publicada. * Los superíndices de las notas finales deben ir dentro de la puntuación final: así². No afuera: así.² * Utiliza el sistema de "Notas y Bibliografía" que se encuentra en el [Manual Chicago 17a edición](https://uc3m.libguides.com/guias_tematicas/citas_bibliograficas/chicago) para las notas al final. -* Cuando se mencione por primera vez una obra publicada, incluye el nombre del autor (incluyendo el primer nombre). Por ejemplo, «Puedes encontrar más información en *The Elements of Typographic Style* de Robert Bringhurst» o «Para más información, consulta *The Elements of Typographic Style* de Robert Bringhurt». En las referencias posteriores, usa solo el título del libro. Los nombres de los autores pueden ser acortados a apellidos solo a partir de su segunda mención. +* Cuando se mencione por primera vez una obra publicada, incluye el nombre del autor (incluyendo el primer nombre). Por ejemplo, "Puedes encontrar más información en *The Elements of Typographic Style* de Robert Bringhurst" o "Para más información, consulta *The Elements of Typographic Style* de Robert Bringhurt". En las referencias posteriores, usa solo el título del libro. Los nombres de los autores pueden ser acortados a apellidos solo a partir de su segunda mención. * Las notas finales no pueden contener solo una URL. * (Correcto): Grove, John. "Calhoun and Conservative Reform." *American Political Thought* 4, no. 2 (2015): 203–27. https://doi.org/10.1086/680389. * (Incorrecto): https://doi.org/10.1086/680389. +* Es necesario citar todo el software utilizado. Entrega todo la información posible siguiendo las sugerencias de la sección "Notas y Bibliografía" del Manual Chicago 17a edición. + * autores + * nombre del producto + * número de la versión + * año de publicación + * URL o DOI + Ejemplo: The Pandas Development Team. *pandas-dev/pandas: Pandas*. v. 1.2.3 (2020). https://doi.org/10.5281/zenodo.3509134 + + Simpre revisa el sitio web o la documentación oficial del software que utilizaste, ya que en muchos casos sus autores explicitan cómo prefieren que su trabajo sea citado (por ejemplo, https://pandas.pydata.org/about/citing.html, https://www.tidyverse.org/blog/2019/11/tidyverse-1-3-0/#citing-the-tidyverse). ### Lenguaje inclusivo y no discriminatorio @@ -321,6 +330,9 @@ Puede resultarte útil leer nuestra [Guía para editores](/es/guia-editor), dond Si en algún momento no tienes seguridad sobre cuál es tu papel en ese momento o de lo que debes hacer a continuación, publica una pregunta en el ticket de revisión de tu lección. Nuestro equipo editorial responderá lo antes posible. Nos esforzamos por responder a todas las preguntas en unos pocos días. +### ¿Qué ocurre una vez que tu lección ha sido publicada? +Ocasionalmente recibimos feedback de personas que se han encontrado con algún error al tratar de completar alguna de nuestras lecciones. En estos casos, nuestra Asistente Editorial abrirá un *Issue* en GitHub y hará una evaluación para determinar si el error reportado surgió por alguna acción del usuario/a (por ejemplo, al editar el código o cambiar el set de datos utilizado) o por un problema de la lección. Si ocurriese esto último, nuestra Asistente Editorial volverá a testear las secciones de la lección que corresponda y buscará una posible solución. Como parte de este proceso de mantención de las lección, es posible que te contactemos para solicitar tu ayuda o sugerencias. En caso de que no se encuentre forma de resolver el problema, agregaremos una advertencia a la lección indicando que algunas personas han encontrado un error y, cuando sea posible, incluiremos en ese mensaje algunos enlaces que permitan a lectores y lectoras explorar una solución por su cuenta. + ### Haznos responsables Nuestro equipo voluntario trabaja duro para proporcionar a autores y autoras una revisión entre pares rigurosa, colegiada y eficiente. Sin embargo, reconocemos que hay momentos en que las expectativas pueden no cumplirse. Queremos que quienes participan en este proceso se sientan con el poder de exigirnos altos estándares. Si, por cualquier razón, sientes que has sido tratado/a injustamente, que el proceso te parece confuso, que la revisión se ha retrasado innecesariamente, que un revisor ha sido grosero, que tu editor/a no ha sido lo suficientemente receptivo/a o tienes cualquier otra inquietud, por favor, déjanos saber para que podamos abordarlo de manera proactiva. diff --git a/es/investigacion.md b/es/investigacion.md index 6f4ada18b8..f24d58239d 100644 --- a/es/investigacion.md +++ b/es/investigacion.md @@ -106,4 +106,4 @@ Países Bajos, 9-12 julio, 2019. ['pre-print pdf']: /researchpapers/openLearningCommunities2016.pdf [Editorial Sustainability and Open Peer Review at Programming Historian]: http://web.archive.org/web/20180713014622/http://dhcommons.org/journal/issue-1/editorial-sustainability-and-open-peer-review-programming-historian ['Digital Project Consultations']: https://dhatasa2015.wordpress.com/ -[Library Carpentry: software skills training for library professionals]: https://www.liberquarterly.eu/articles/10176/ +[Library Carpentry: software skills training for library professionals]: https://liberquarterly.eu/article/view/10847 diff --git a/fr/recherche.md b/fr/recherche.md index ec20a15dd6..34eb9ab02c 100644 --- a/fr/recherche.md +++ b/fr/recherche.md @@ -93,4 +93,4 @@ L'équipe du projet et les membres de la communauté plus large qui la compose s * Eva Pfanzelter, "Syllabus: Introduction to Digital Practice in the Historical Sciences", Université d'Innsbruck, Autriche Projet H2020 NewsEye (2021). * Kelly Fitzpatrick, "Caselaw Access Project", Harvard Law School (2019). * Paul Spence, Renata Brandao, "Digital Modern Languages Writing Sprint", Language Acts and Worldmaking (2019). -* James Baker, Caitlin Moore, Ernesto Priego, Raquel Alegre, Jez Cope, Ludi Price, Owen Stephens, Daniel van Strien, Greg Wilson, '[Library Carpentry: software skills training for library professionals](https://www.liberquarterly.eu/articles/10176/)', _Liber Quarterly: The Journal of the Association of European Research Libraries_, 26(3) (2016). +* James Baker, Caitlin Moore, Ernesto Priego, Raquel Alegre, Jez Cope, Ludi Price, Owen Stephens, Daniel van Strien, Greg Wilson, '[Library Carpentry: software skills training for library professionals](https://liberquarterly.eu/article/view/10847)', _Liber Quarterly: The Journal of the Association of European Research Libraries_, 26(3) (2016). diff --git a/pt/pesquisa.md b/pt/pesquisa.md index dd44a5fb46..f01dfd4493 100755 --- a/pt/pesquisa.md +++ b/pt/pesquisa.md @@ -89,4 +89,4 @@ A equipe do projeto e membros da comunidade em geral estão envolvidos em vária * Eva Pfanzelter, "Syllabus: Introduction to Digital Practice in the Historical Sciences", History Curriculum, University of Innsbruck, Austria, NewsEye H2020 Project (2021). * Kelly Fitzpatrick, "Caselaw Access Project", Harvard Law School (2019). * Paul Spence, Renata Brandao, "Digital Modern Languages Writing Sprint", Language Acts and Worldmaking (2019). -* James Baker, Caitlin Moore, Ernesto Priego, Raquel Alegre, Jez Cope, Ludi Price, Owen Stephens, Daniel van Strien, Greg Wilson, '[Library Carpentry: software skills training for library professionals](https://www.liberquarterly.eu/articles/10176/)', _Liber Quarterly: The Journal of the Association of European Research Libraries_, 26(3) (2016). +* James Baker, Caitlin Moore, Ernesto Priego, Raquel Alegre, Jez Cope, Ludi Price, Owen Stephens, Daniel van Strien, Greg Wilson, '[Library Carpentry: software skills training for library professionals](https://liberquarterly.eu/article/view/10847)', _Liber Quarterly: The Journal of the Association of European Research Libraries_, 26(3) (2016).