Feedbacks

Feedbacks et note du rapport intermédiaire

Le rapport étant noté sur 5 critères

Qualité de la revue de projet et/ou du rapport intermédiaire (état du projet, décomposition, évaluation comparative des solutions, spécifications détaillées, planification, organisation de la documentation) Extrait de la grille d'évaluation

Passer du temps à bien comprendre en détails les retours du rapport intermédiaire, de son côté en relisant des parties problématiques et avec le prof durant le retour du rapport pour creuser tous les problèmes restants. Connaître les points attribués au 5 critères de la note du rapport intermédiaire pour voir ce qui est à retravailler. Avoir vision claire des corrections à faire sur ce qui a déjà été rendu.

Prévoir du temps pour retravailler le rapport intermédiaire.

Après correction, remontrer au prof une partie des changements pour s'assurer que ça a résolu les problèmes.

Organiser des relectures de rapports

Prendre du temps pour faire relire, corriger avec les retours et faire attention à la charge de travail des autres personnes en TB. demander à des 1ère année ou 2ème année qui n'ont pas de charge particulière sur les vacances.

TODO plus tard

Exemple de surlignage

TODO: surlignage examples TODO: okular usage tips with screenshots

Conventions sur les relectures de rapports

Note: Section en cours de beta testing

Tout comme la rédaction, les relectures prennent un temps conséquent. Afin de maximiser leur utilité, voici une tentative de définir une convention sur ce qui est attendu de l'effort des deux côtés. Cela reste des bonnes pratiques, selon la motivation on pourra faire moins. Cette convention est partagée ici pour être utile à d'autres aussi.

Le genre de retour qui serait très peu utiles qu'on cherche à éviter et pourquoi:

ouais c'est pas mal, j'ai pas tout capté mais dans l'ensemble ça va -> quel partie, pourquoi, quel contexte manque, qu'est-ce qui est flou ???
c'est top ton rapport, j'ai bien kiffé -> en quoi c'est top ? qu'est-ce qui fait que c'est clair ? si on devait encore améliorer, comment faire ? quelle partie tu as appprécié et pourquoi ?

Mon but principal est d'arriver à un texte clair, fluide et qui ne laisse pas de place au doute ou questions durant la lecture. Le public cible visé est l'ensemble des ingénieur·es en informatique, qui n'a pas besoin de connaître mon sujet ni les langages utilisés pour le développer. La lecture ne devrait pas nécessiter des allers retours entre les pages ou d'aller voir des sections plus bas pour comprendre.

La relecture peut concerner une partie ou tout le rapport, en fonction de la progression et maturité du texte. Les plages de pages à relire sont à définir avant de commencer.

Questions générales, à répondre par écrit ou sur le PDF directement

Est-ce qu'on arrive bien rentrer dans le sujet ? Est-ce qu'on se sent paumé·e à des moments ?
Est-ce qu'il manque une partie de contexte ou d'explications sur des technologies ou concepts mentionnés ?
Est-ce qu'on arrive à bien comprendre les problèmes à résoudre et pourquoi ça en vaut la peine ?
Est-ce qu'on arrive à bien distinguer l'existant du projet et ce qui va être développé dans ce TB ?
Est-ce qu'il y a des sujets dont tu as eu besoin d'aller chercher sur Internet ou voir des ressources externes au document pour comprendre ?

Détails du texte, à annoter sur le PDF.

Si tu ne connais pas d'outil d'annotation basique de PDF, celui de Firefox (disponible en ouvrant simplement le PDF en drag and drop sur un onglet) fait l'affaire, même s'il faut régulièrement sauver le fichier (juste ctrl+s + enter).

Les éventuelles fautes de frappes, de grammaire ou d'orthographes encore présentes. Une marque style stabilo ou un soulignement suffit la majorité du temps, pas besoin de proposer de correction.
Dès qu'une phrase est mal tournée, trop longue ou difficile à lire, ou incompréhensible, le noter. Demande probablement une explication, dans une zone de texte ou un note cliquable.
Dès qu'il y a une incompréhension en mode "atteint pourquoi on parle de ça ici", ou "atteint mais je croyais qu'on voulait prendre une autre piste", c'est précieux comme retour, le noter aussi.
S'il y a des problèmes plus larges de structures (ordre, approche, explication du problème)? Si oui, expliquer pourquoi c'est un problème et une proposition pour y remédier.
Est-ce la qualité et clarté des bouts de code, schémas et images présentes est au rendez-vous ? Est-ce qu'ils apportent du contexte utiles ou sont trop difficile à capter ?
Est-ce que certains concepts pourraient être clarifiés par des schémas ? Que pourraient-ils représenter et comment ?

Tout autre remarque pertinente est évidemment bienvenue!

Si le temps de relecture manque, la relecture peut se concentrer sur un sous section plus critique ou moins mature, à définir avec l'auteur·ice. Ce qui n'a pas été lue par manque de temps, devrait être annoncé à l'auteur·ice pour éviter de penser je n'ai pas eu de retours donc c'est tout clair alors que la relecture n'était que partielle.

Une fois tous les retours pris en considération et corrigés, il serait sympa de recontacter la personne qui a relue pour la remercier et indiquer si certains points n'ont pas été modifiés ou si certains points du feedback ne sont pas clairs. A ce moment, on peut demander si elle souhaite apparaitre dans les remerciements ou pas.