| title | date | layout | original |
|---|---|---|---|
Consignes aux evaluteur(trice)s |
03-14-2015 |
blank |
reviewer-guidelines |
Devenir évaluateur(trice) pour le Programming Historian en français est une excellente manière d'acquérir de nouvelles compétences techniques et de vous insérer dans la communauté des humanités numériques. Nous faisons tout notre possible pour nous assurer que les évaluateurs et les évaluatrices reçoivent crédit et reconnaissance pour leur travail. Parce qu'en tant évaluateur(trice), vous contribuez directement à améliorer de manière significative la qualité des leçons, vous pouvez être fier(ère) de votre travail qui aide ainsi des milliers de lecteurs et de lectrices.
Ces consignes sont destinées à aider les évaluateurs et les évaluatrices à comprendre quel est leur rôle dans le processus éditorial, et à répondre aux questions les plus fréquentes concernant la manière la plus efficace de produire des évaluations.
{% include toc.html %}
Nous ne sollicitons pas des évaluateur(trice)s pour juger si un tutoriel est "assez bon" pour être publié. Nous envisageons plutôt le processus d'évaluation comme faisant partie intégrante de l'effort collaboratif, productif et pérenne fourni par les chercheur(se)s, pour créer des ressources techniques utiles pour tous. Une fois qu'un tutoriel entre dans notre processus éditorial, nous travaillons étroitement avec l'auteur(e) et les évaluateur(trice)s pour maximiser son potentiel et le publier dans un délai raisonnable.
Évaluer un tutoriel ne consiste pas seulement à examiner ses mérites et ses imperfections (même s'il est aussi important de le faire), ou de juger s'il est bien approprié au Programming Historian en français ; il s'agit d'aider à améliorer ce tutoriel en apportant un regard extérieur. Nous demandons à nos évaluateur(trice)s d'émettre des critiques constructives (et bien sûr des éloges) qui vont permettre d'améliorer le tutoriel de façon à le rendre accessible à un grand nombre de lecteurs et de lectrices. Par ailleurs, nous ne faisons pas évaluer des tutoriels dont la qualité serait très éloignée de celle que nous attendons pour la version publiée.
Nous accordons une grande importance à la transparence dans le processus de production et d'évaluation des leçons. Pour gérer le processus d'évaluation, nous utilisons GitHub où nos leçons sont hébergées. Nous utilisons notamment les possibilités offertes par GitHub pour commenter et suivre les issues de manière à garder la trace des suggestions qui ont été faites, mais aussi comment celles-ci ont été gérées et discutées par les auteur(e)s et les évaluateur(trice)s. Ce système évite que des conversations importantes soient enterrées et perdues dans de multiples échanges de mails.
Par conséquent, votre travail en tant qu'évaluateur(trice) --et votre identité-- sera entièrement accessible à l'auteur(e). Les commentaires doivent permettre d'engager directement le dialogue avec l'auteur(e) et sa leçon, plutôt qu'avec le(la) rédacteur(trice) de la leçon. Si, à n'importe quel moment, vous n'êtes pas sûr(e) de votre rôle ou de ce que vous devez faire ensuite, n'hésitez pas à poster une question afin de demander des éclaircissements, et un(e) rédacteur(trice) vous répondra aussi vite que possible.
Dans l'idée de soutenir la recherche académique ouverte et l'évaluation par les pairs ouverte, nous encourageons généralement les discussions à se tenir sur GitHub, comme le prévoit notre processus éditorial. Toutefois, nous souhaitons également que chacun et chacune se sente à l'aise. Et dans certains cas, un message personnel peut être plus approprié. Si vous ressentez le besoin de discuter en privé d'un sujet qui est lié au tutoriel ou à l'évaluation, n’hésitez pas à envoyer directement un message au rédacteur ou à la rédactrice assigné(e), ou de contacter notre médiatrice Hélène Huet.
À moins de nous donner l'instruction contraire, votre nom sera mentionné comme celui de l'évaluateur(trice) sur la page de la leçon, quand celle-ci sera officiellement publiée ; votre nom apparaîtra également dans notre page listant les contributeur(trice)s.
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. Merci de nous aider à créer un espace de discussion et d'échange sûr.
Le style informel des leçons du Programming Historian en français peut donner la fausse impression qu'il est très simple de les écrire. En fait, écrire un bon tutoriel est tout aussi exigeant, voire même plus exigeant, qu'écrire n'importe quel autre type d'écrit académique. Vous trouverez ci-dessous les quelques questions les plus courantes que vous devez garder à l'esprit quand vous évaluez une leçon. Certaines d'entre elles seront plus pertinentes que d'autres, en fonction du sujet, du public visé, et du niveau de difficulté du tutoriel. Il est inutile de dire qu'il ne s'agit pas d'une liste restrictive ou, à l'inverse, complète ; nous ne demandons par à nos évaluateurs et évaluatrices de répondre à chacune de ces questions, mais nous espérons qu'elles pourront leur donner une orientation générale.
Le Programming Historian en français s'adresse à des publics variés et à un large éventail de lecteurs et de lectrices, qui ont des niveaux hétérogènes. Certaines leçons sont destinées à de parfaits débutants, d'autres à des personnes qui sont beaucoup plus à l'aise avec des concepts et des méthodes techniques, et d'autres encore sont destinées à des historien(ne)s numériques expérimenté(e)s, qui cherchent à résoudre des défis techniques difficiles. Nous accueillons donc une grande variété de lecteurs et de lectrices!
Bien que nous apprécions le fait que nos leçons se fassent l'écho de la voix, unique, de leurs auteur(e)s, nous souhaitons également que chaque leçon, prise individuellement, reste claire et cohérente dans son ton. Plus particulièrement, nous souhaitons que les explications techniques (et la difficulté) restent aussi cohérentes que possible tout au long de la leçon. En tant qu'évaluateur(trice), vous trouverez très utile de signaler les sections d'un tutoriel qui sont destinées à des utilisateur(trice)s plus avancé(e)s techniquement, et qui semblent expliquer un peu trop en détail des concepts relativement simples ; l'inverse peut aussi être vrai : nous souhaitons éviter les sections dédiées aux débutants, qui n'expliqueraient pas de manière adéquate des concepts fondamentaux, pivots du tutoriel. Vous devez donc garder certaines questions à l'esprit :
- L'auteur(e) s'adresse t-il(elle) à un modèle de lecteur cohérent tout au long de la leçon ?
- Certains concepts ou étapes sont-ils trop, ou au contraire, pas assez détaillés ?
- Le public visé semble t-il correspondre, même vaguement, avec celui d'autres leçons du Programming Historian en français ? En quoi le public visé est-il nouveau ?
- Quels logiciels / langages de programmation sont-ils requis ?
- Quels sont les prérequis attendus ?
- Quelle familiarité ou expérience sont-elles requises ?
- Quelles données sont nécessaires ? Les jeux de données sont-ils facilement disponibles ?
- Les objectifs pédagogiques ou les compétences à acquérir sont-ils clairement définis ? Sont-ils listés et visibles au début de la leçon ?
- Y a t-il des compétences secondaires à acquérir / appliquer en suivant la leçon ?
- Des captures d'écran ou d'autres diagrammes illustrent-ils les étapes / points cruciaux de la leçon ?
- Des sections et des en-têtes de sections jalonnent-elles clairement la lecture ?
- Le tutoriel explique t-il pourquoi les outils ou les techniques exposés sont utiles de manière générale ?
- Le tutoriel explique t-il comment un lecteur ou une lectrice pourrait utiliser les concepts (sinon les étapes concrètes) de la leçon pour ses propres travaux ?
- Si une leçon est longue, devrait-elle être divisée en plusieurs leçons plus petites?
- Y a t-il des pauses dans le raisonnement, logiquement réparties tout au long de la leçon ?
- Si des jeux de données doivent être utilisés, sont-ils disponibles au téléchargement à différents moments tout au long de la leçon (ou bien différentes versions de ces jeux de données si le tutoriel le requiert) ?
Pour augmenter la durée de vie de nos leçons, les évaluateur(trice)s du Programming Historian en français doivent garder en tête les questions suivantes. Chaque soumission est différente, et certains de ces points peuvent ne pas s'appliquer à toutes les soumissions. Tout en gardant à l'esprit le niveau de difficulté de chaque leçon et le public visé, les évaluateurs et évaluatrices doivent utiliser ces questions comme des lignes directrices, qui les aideront à s'assurer que les leçons sont aussi pérennes que possible dès la date de leur publication.
- Toutes les versions des logiciels, ainsi que les dépendances logicielles, sont-elles listées dans la soumission ? Ces versions sont-elles les plus récentes ? Si la leçon utilise des versions plus anciennes, l'auteur(e) explique t-il(elle) pourquoi ?
- Si vous avez de l'expérience avec la méthodologie décrite ou le(s) outil(s) présentés dans la leçon, la méthodologie est-elle généralement à jour ?
- En quoi consiste les sources des données pour la soumission ? Sont-elles inclues de telle façon que cela n'implique pas une gestion lourde de ces données par une solution de stockage tierce ?
- Quels types de liens externes sont-ils utilisés par la soumission ? Sont-ils à jour, ou y a t-il d'autres ressources, plus récentes ou plus appropriées, qui pourraient être insérées ?
- La leçon s'appuie t-elle sur une leçon existante ? Explique t-elle de quelle manière ?
- La leçon a t-elle des liens avec des leçons existantes et ces liens sont-ils pertinents ?
C'est avec GitHub que nous gérons tous les commentaires produits lors des évaluations par les pairs. Quand une nouvelle leçon est prête à être évaluée, un(e) rédacteur(trice) va vous donner un lien qui vous permettra d'accéder à la leçon et de la lire, et un lien vers un forum de discussion au sein duquel vous pourrez partager des commentaires constructifs. Cette discussion se tient sur GitHub, un environnement libre de programmation sociale, et vous aurez besoin de créer un compte GitHub gratuit pour poster votre évaluation. Nous encourageons les discussions à se tenir sur GitHub, mais vous êtes libre d'envoyer un message privé au rédacteur ou à la rédactrice, ou de contacter notre médiatrice Hélène Huet si vous souhaitez avoir un échange privé.