Ce document, édité le 2017-05-03, est le guide des membres du LRDE. Il est disponible sous plusieurs formes:

• Le guide en HTML.
• Le guide en PDF.
• Le guide en texte.
• Le guide en format Info.

Ce document compte de nombreux auteurs, et tout particulièrement:

• Daniela Becker
• Akim Demaille
• Alexandre Duret-Lutz
• Geoffroy Fouquier
• Jean-Philippe Garcia-Ballester
• Roland Levillain
• Raphaël Poss
• Didier Verna

Les sources de ce guide sont stockées dans le dépôt Git ‘lrde-admin-lrde’, à l’adresse git@git.lrde.epita.fr:lrde-admin-lrde, au sein du répertoire ‘guide’.

Table des matières

• Chapitre 1  Introduction
• Chapitre 2  Fonctionnement du LRDE
  • 2.1  Confiance
  • 2.2  Réunions
  • 2.3  L’état d’esprit
    • 2.3.1  Relation avec les permanents
    • 2.3.2  Le «système» CSI
  • 2.4  Administration Système
    • 2.4.1  Gestion du parc du LRDE
      • 2.4.1.1  Le parc informatique de l’EPITA
      • 2.4.1.2  Permettre un accès privilégié à son ordinateur
      • 2.4.1.3  Administration des machines personnelles
      • 2.4.1.4  Utilisation des ressources communes
    • 2.4.2  Configuration logicielle
      • 2.4.2.1  Base logicielle
  • 2.5  Bibliothèque
    • 2.5.1  Classification EPITA des publications
    • 2.5.2  Classification LRDE des publications
  • 2.6  Les Bureaux du LRDE
    • 2.6.1  Paritalie
    • 2.6.2  L’allure
    • 2.6.3  Vigilance
    • 2.6.4  Accès au LRDE
  • 2.7  Année typique
  • 2.8  Dépôts Git
  • 2.9  Newsgroups LRDE
  • 2.10  ‘/lrde/doc’
    • 2.10.1  ‘contents.bib’
    • 2.10.2  ‘lrde/papers’
    • 2.10.3  ‘csi’
• Chapitre 3  Communication
  • 3.1  Décharges
  • 3.2  Actualités
    • 3.2.1  Que sont les actualités
    • 3.2.2  Les messages d’annonce
      • 3.2.2.1  Parution de l’air de rien
      • 3.2.2.2  Publication
  • 3.3  Journées Portes Ouvertes (JPO)
    • 3.3.1  De l’importance des JPOs
    • 3.3.2  Participation à une JPO
  • 3.4  Publications
    • 3.4.1  Rédaction
    • 3.4.2  Rejet
    • 3.4.3  Acceptation
    • 3.4.4  Parution
  • 3.5  L’air de rien
    • 3.5.1  Rédaction
  • 3.6  URLs
  • 3.7  Séminaires CSI
    • 3.7.1  Organisateur du séminaire CSI
    • 3.7.2  Sujet d’un exposé au séminaire CSI
    • 3.7.3  Préparation d’un exposé au séminaire CSI
  • 3.8  Journées thématiques
  • 3.9  Faire de bonnes publications
    • 3.9.1  Avant propos
    • 3.9.2  L’écriture de papiers et de rapports
      • 3.9.2.1  Plan d’un rapport
      • 3.9.2.2  Organisation
      • 3.9.2.3  Bibliographie
      • 3.9.2.4  Références
      • 3.9.2.5  Figures, notes de bas de pages, etc.
      • 3.9.2.6  Mathématiques
      • 3.9.2.7  Style
      • 3.9.2.8  Langage
    • 3.9.3  Erreurs d’anglais communes
      • 3.9.3.1  Verbes irréguliers
      • 3.9.3.2  Formes spéciales
      • 3.9.3.3  Ponctuation
      • 3.9.3.4  Pluriels
      • 3.9.3.5  Noms propres
      • 3.9.3.6  Noms communs
      • 3.9.3.7  Faux amis
• Chapitre 4  La scolarité CSI
  • 4.1  Le recrutement
  • 4.2  La majeure CSI
    • 4.2.1  Communication
    • 4.2.2  Administration
      • 4.2.2.1  Dispenses, équivalences
      • 4.2.2.2  Projets scolaires
      • 4.2.2.3  Cours d’anglais
      • 4.2.2.4  Cycle de conférences
    • 4.2.3  Vacances
  • 4.3  Activités extra-LRDE
  • 4.4  Notes CSI
    • 4.4.1  Les Séminaires CSI
    • 4.4.2  Les rapports
      • 4.4.2.1  Comment créer un nouveau rapport
      • 4.4.2.2  Rédaction des rapports
      • 4.4.2.3  Correction des rapports
      • 4.4.2.4  Étapes de rendu d’un rapport
    • 4.4.3  Développement
  • 4.5  Après
    • 4.5.1  Lettres de recommandation
• Chapitre 5  Maintenance des Projets
  • 5.1  Maintenance des avis du droit de copie
  • 5.2  Le fichier ‘ChangeLog’
    • 5.2.1  Quoi et comment
    • 5.2.2  ChangeLog: Le bien
    • 5.2.3  ChangeLog: Le mal
    • 5.2.4  Emacs et ChangeLog
  • 5.3  Enregistrement d’une révision
    • 5.3.1  Pourquoi utiliser un système de contrôle de versions
    • 5.3.2  Définir un enregistrement de révision
    • 5.3.3  La procédure d’enregistrement
  • 5.4  Inspection de Correctifs
  • 5.5  Release de logiciel
    • 5.5.1  Préparer le release
    • 5.5.2  Page de release

Chapitre 1  Introduction

Ce document fournit des lignes de conduite pour les membres du LRDE.

Pourquoi en L^AT_EX et pas sur le Wiki ?

La majorité du contenu était disponible sur le Wiki, mais son manque de structure et l’impossibilité d’imprimer des livrets réduisait sa visibilité: un «vrai» document était une meilleure solution.

Pourquoi L^AT_EX ?

L^AT_EX est un bon outil pour générer du texte brut, de l’HTML, et des documents imprimables. Par ailleurs, les sources de ce document peuvent donner de l’inspiration sur comment rédiger un rapport.

Chapitre 2  Fonctionnement du LRDE

La vie de tous les jours au LRDE.

2.1  Confiance

Le fonctionnement du LRDE repose de façon essentielle sur la confiance et le respect entre tous ses membres, permanents et étudiants.

La sanction du LRDE a une forme unique: l’exclusion,

• pour toute activité illégale au regard de la loi,
• pour le viol d’interdictions du règlement de l’EPITA,
• si l’ensemble des permanents juge un comportement inacceptable.

Le bon sens devrait suffire, mais explicitons certaines instances (listes non limitatives):

• vol
• piratage informatique
• usurpation d’identité
• manque de respect patenté à autrui

2.2  Réunions

Les différentes réunions labo (spécifiques à chaque projet, globales, restreintes aux permanents) ont lieu le mercredi. Il est plus facile de se réserver une journée fixe et périodique pour s’assurer de la présence de tout le monde. Disposer d’une journée fixe ne suffit cependant pas dans certains cas: des impondérables peuvent de temps en temps nous contraindre à modifier tardivement si ce n’est le jour, du moins les horaires de chaque réunion. Pour cette raison, la présence au laboratoire est obligatoire tous les mercredis dès 10h, et ce même si la première réunion n’est prévue qu’à midi. Étant donnée cette contrainte faible, les retards du matin sont peu appréciés, et les retards aux réunions, comme à tout autre rendez-vous, sont intolérables.

La réunion «globale» du labo a lieu un mercredi sur deux, à 12h, peu avant le repas de façon à pousser à la brièveté. Cette réunion commence typiquement par un certain nombre de globalités sur la vie du labo, de l’école, les échéances, les bonnes nouvelles etc. Puis, pour chaque projet/groupe de travail, un délégué prend la parole. Pour préciser le rôle de ce «médiateur»:

• Le but est que ce médiateur fournisse un état d’avancement synthétique du projet, pour tout le monde, et en particulier ceux qui ne sont pas dans ledit projet. Nous insistons sur le caractère «synthétique». C’est précisément pour éviter toute redondance. À titre de contre-exemple, dire «Truc a fait ceci, et machin a fait cela» n’est pas un compte-rendu synthétique. De l’extérieur, on se fiche de savoir qui a fait quoi. Ce qui nous intéresse, c’est de savoir ce qui a avancé dans le projet, où se posent des problèmes etc.
• En corollaire, il faut aussi comprendre que vous forcer à choisir un délégué de réunion pour chaque projet est bon pour vous parce que ça vous oblige à communiquer en interne afin de préparer correctement la synthèse. On a par exemple suggéré que l’inconvénient d’une présentation synthétique est que les problèmes précis que peuvent se poser telle ou telle personne ne sont plus évoqués. Mais si cela se produit, c’est que le groupe communique mal. Le problème particulier d’un individu au sein d’un projet ne doit jamais rester au niveau individuel, mais doit être partagé par tout le groupe (voire même par les autres groupes). C’est comme ça que le projet avance, et si vous êtes capables de communiquer suffisamment au sein de chaque projet, alors la synthèse ne devrait pas poser de problème.

Cela n’exclut en aucun cas la possibilité d’une prise de parole individuelle. L’animateur de la réunion s’efforcera après chaque compte-rendu par projet de laisser du temps pour les prises de paroles individuelles.

Avant 2005, chacun avait son tour de parole. Ceci a été changé pour deux raisons:

1. avec l’effectif croissant du LRDE, les réunions devenaient interminables,
2. trop souvent les gens disaient la même chose, ou disaient simplement qu’ils n’avaient rien à dire (ex: «je fais mon rapport» ; «pareil que mon voisin» etc).

2.3  L’état d’esprit

Le LRDE et la scolarité CSI tels qu’ils sont aujourd’hui sont le résultat d’années d’évolution d’un système unique en son genre. Chaque année des dysfonctionnements sont dénoncés et corrigés, plus ou moins bien. Certains sujets sont récurrents, certains points sont surprenants. Cette section tente d’expliquer et/ou de motiver nos règles de fonctionnement.

Par exemple la réunion LRDE était autrefois hebdomadaire, sans contrôle du temps ni format contraint ; les longues digressions étaient fréquentes, et la réunion durait régulièrement plus de deux heures avec des échanges qui parfois n’intéressaient qu’une fraction des présents. Pour contrer ces travers, elle est aujourd’hui bimensuelle, avec format contraint ; en contrepartie, les échanges et la «cross-polénisation» sont bien moins effectifs, elle ne joue pratiquement plus qu’un rôle informatif. Aucun permanent n’a de solution miracle pour résoudre les problèmes.

Si tous les permanents sont prêts à faire des efforts, aucun ne peut raisonnablement s’engager sur le fait que «tout se passera bien». On, les étudiants et les permanents, doit faire du «best effort». Ce qui va de pair avec la volonté d’améliorer le fonctionnement du laboratoire. À l’inverse, critiquer dans son coin ne permet aucune amélioration, et n’a qu’à un seul résultat: instaurer un climat nauséabond. Toute critique franche et ouverte est la bienvenue.

2.3.1  Relation avec les permanents

Autrefois la relation avec les étudiants était très fusionnelle, très familiale. C’était un autre temps, où tout commençait, tout était à faire. Aujourd’hui le laboratoire est plus gros (c’est une bonne chose), plus vieux, et la majeure CSI également (et c’est cohérent avec la croissance du LRDE, et les demandes de l’EPITA).

Aujourd’hui les permanents sont toujours proches des étudiants, et dans certains cas la relation est presque amicale, mais nous ne sommes pas égaux et vous travaillez pour nous, en échange de votre formation, de notre appui à vos différentes candidatures, etc.

Nous faisons tout notre possible pour encadrer les étudiants du mieux possible sur les sujets qui leur sont donnés, mais…

• Nous ne sommes pas toujours maîtres de nos calendriers, et l’actualité peut parfois nous empêcher d’être aussi proches que nous le voudrions.
• Les étudiants doivent gagner en indépendance, c’est un des points les plus fondamentaux à apprendre dans le milieu de la recherche. Ça ne veut surtout pas dire travailler seul, bien au contraire, mais travailler avec d’autres, trouver du travail lorsque le superviseur n’est pas disponible (par exemple creuser la bibliographie).
• Apprenez néanmoins à vous imposer ! Forcez la porte de votre permanent si vous le jugez nécessaire. Parfois la seule façon de trouver de la place, c’est de la faire.

Par dessus tout, ne laissez rien moisir (c’est d’ailleurs valable pour tous les types de relation). Si quelque chose vous échappe, si une note vous choque, si un travail vous paraît injuste, si le comportement d’un camarade vous importune, si votre scolarité est en difficulté, si votre permanent vous agace, etc. faites le savoir. De nombreux canaux sont à votre disposition: votre encadrant, le responsable CSI, le responsable LRDE, Daniela, votre délégué, vos camarades, etc.

Faites nous savoir les problèmes que vous rencontrez. Parfois nous pouvons les résoudre, d’autre fois nous pouvons vous montrer que ce sont de faux problèmes, d’autre fois enfin nous serons obligés de reconnaître avec vous que ce sont des problèmes, mais qu’on ne sait pas les traiter. «Best effort».

Quel que soit le problème, c’est par la discussion que les meilleures solutions seront trouvées, et les permanents ont à cœur que les CSI soient bien dans leur peau.

2.3.2  Le «système» CSI

Aujourd’hui CSI compte environ 5 étudiants par promotion, et deux promotions simultanées. Nous ne pouvons plus faire du cas par cas, nous ne pouvons pas faire de cours particulier de rédaction de rapport, d’erreur d’anglais, de typographie etc. Le guide est une première réponse: il permet aux permanents d’écrire les consignes, que vous n’avez plus qu’à suivre; il liste des erreurs fréquentes, que vous n’avez plus qu’à éviter. Mais alors, bien sûr, lorsque les procédures ne sont pas suivies, tout le monde perd du temps.

La qualité des commentaires que nous pouvons vous donner baisse lorsque nous rapportons des erreurs communes (voir par exemple les sections 3.9.3 et 4.4.2). Le temps passé sur des sujets importants est amoindri quand il faut vérifier pour vous que, par exemple, votre rapport est (correctement) mis en ligne et (correctement) référencé dans ‘csi.bib’ (disponible dans le dépôt Git ‘lrde-publis-share’ à l’adresse git@gitlab.lrde.epita.fr:lrde/share, dans ‘bib/csi.bib’).

Comme de plus certains prennent des libertés avec les dates, le système s’est durci, et régulièrement des points de malus sont mis lorsque les règles ne sont pas suivies. Nous aimerions un laboratoire sans ce système, mais il n’a jamais fonctionné: c’est bel et bien le fonctionnement précédent du LRDE, mais il ne fonctionne pas. Malheureusement, c’est le système «scolaire» qui est le plus efficace.

Ainsi, afin de rendre plus claires les attentes des permanents, ce qui autrefois était une unique note laboratoire est devenu un ensemble d’exercices et de critères (rapport, recherche, etc.) notés différemment. Certaines notations sont collégiales (séminaire), d’autres sont faites par quelques permanents (rapport), voire un seul (typiquement recherche). Bien sûr se sont posés des problèmes d’harmonie des notes: untel notait largement, et autretel sèchement.

Une première réponse fut la constitution de la grille de notation, avec comme effet immédiat et bienvenu une moins grande dispersion des notes. Certains regrettent que les notes ne couvrent pas un plus grand spectre, mais c’est indiscutablement un progrès par rapport à la situation précédente. Par ailleurs, le travail fourni est effectivement plus homogène et il est de plus en plus rarement mauvais.

Une seconde réponse fut la création de jurys de notation, de façon à ce que les notes soient harmonisées à l’échelle du laboratoire. Ainsi, les notes de recherche et développement sont typiquement discutées, débattues et justifiées par les permanents entre eux. Ils prêtent une attention spéciale à l’ordre qui en résulte, de façon à éviter qu’un travail jugé meilleur qu’un autre ait une moins bonne note.

Bien entendu ce système fonctionne mal lorsque certains permanents ne sont pas présents. Par ailleurs, certains permanents perçoivent mieux la situation que d’autres, et il n’est du ressort du jury que de préempter une décision ferme de l’un de ses membres. Ainsi, il est parfaitement possible que certaines notes ne fassent pas l’unanimité.

Souvent ces mêmes notes peuvent choquer les étudiants qui y voient une injustice. Dans ces conditions, il faut d’abord en parler avec nous, peut-être pour nous ouvrir les yeux sur quelque chose que nous n’avons pas perçu (ou le contraire). Il est possible alors que rien ne change, pour tout un ensemble de raisons plus ou moins bonnes.

Quoiqu’il arrive, nous voudrions vous rappeler deux choses. D’abord que les permanents ne sont pas en faveur d’un système scolaire, il n’est là que d’une part pour faire plaisir à l’école, et d’autre part pour maîtriser certains travers de CSI. Ce qui compte, c’est votre travail, ce que nous pensons, ce que nous en disons, ce que nous pouvons en faire, et…ce que vous-même en pensez ! C’est précisément pour cette raison que toutes les notes LRDE sont assorties de commentaires, que nous voulons plus importants que les notes elles-mêmes. La seconde observation c’est que…regardez dans votre assiette, pas dans celles des autres ! Il n’y a pas de concours CSI, il n’y a pas de classement qui se vaille au LRDE (à commencer par l’absurdité de vouloir comparer un travail mathématique de l’un avec le travail plus algorithmique d’un autre). La seule chose qui compte, c’est la valeur des contributions croisées: ce que le labo vous aura apporté, et ce que vous aurez apporté au labo.

Bien entendu les problèmes scolaires sont d’un autre ordre ! Et il est important que nous soyons au courant des soucis que vous rencontrez le plus rapidement possible pour pouvoir les traiter — si c’est nécessaire et sain.

2.4  Administration Système

Pour tout problème concernant l’administration système, vous pouvez contacter directement l’administrateur ou lui envoyer un message électronique : sysadm at lrde.epita.fr

Le guide d’utilisation des différents services déployés au sein du LRDE est principalement documenté sur l’intranet page Ressources.

2.4.1  Gestion du parc du LRDE

Voici une liste de règles et de recommandations concernant le parc informatique du LRDE.

2.4.1.1  Le parc informatique de l’EPITA

Le parc informatique du LRDE est totalement intégré dans le parc informatique de l’EPITA. Le règlement de ce dernier s’applique donc dans son intégralité. Ce règlement a été ratifié par tous les étudiants de l’EPITA lors de la création de son compte par l’administration système de l’école (bocal).

2.4.1.2  Permettre un accès privilégié à son ordinateur

En raison de l’inclusion évoquée ci-dessus, pour des raisons légales, nous devons être en mesure d’établir une responsabilité en cas de problème impliquant n’importe quel ordinateur du parc du LRDE à la demande de l’administration supérieure de l’EPITA.

L’accès à ces informations étant conditionné à un accès privilégié sur chaque ordinateur, vous devez fournir cet accès à l’administrateur système en charge du LRDE.

Techniquement, la solution privilégiée est l’ajout de la clé ssh d’un compte particulier (compte non-réseau de l’admin), dans la configuration ssh de l’utilisateur root de l’ordinateur. Cette clé est située dans le compte lrde, dans le répertoire ‘etc/’. Voici une méthode de configuration:

Sur votre machine et en root:

Par défaut, toutes les machines nouvellement installées possèdent déjà cette clé.

2.4.1.3  Administration des machines personnelles

Les personnes amenées à utiliser leurs propres ordinateurs sont autorisées à le gérer librement. Vous êtes notamment libre de choisir le système d’exploitation utilisé et d’installer les services dont vous jugez avoir besoin. Mais le système choisi est le système GNU/Linux Debian et l’administration est d’autant facilité par l’uniformisation du réseau. Si vous choisissez de dupliquer des services, comme d’utiliser un serveur SMTP local pour envoyer des courriers, vous en êtes responsable. Toutefois, des restrictions s’appliquent dans le cadre de l’utilisation de la machine «en réseau».

2.4.1.4  Utilisation des ressources communes

Le LRDE met à disposition de ses étudiants un compte informatique et des ressources matérielles et logicielles. Il est bien entendu demandé d’utiliser ces ressources d’une manière respectueuse de l’ensemble. Pour mémoire, il est interdit de stocker des logiciels et/ou données non légaux. Une attention particulière est demandée en cas d’utilisation des ressources communes à des fins personnelles. En particulier, merci de ne pas abuser de l’espace disque. En cas d’abus, des quotas seront mis en place.

Le laboratoire dispose d’une imprimante multifonction située dans la réserve. Une règle à retenir quant à l’utilisation du papier: la personne qui ouvre la dernière ramette du dernier carton est automatiquement responsable d’aller chercher un nouveau carton de feuilles. Pour cela, aller à l’accueil de l’EPITA (entrée rue Voltaire), se présenter en tant que membre du LRDE et demander à la personne présente un carton de papier pour l’imprimante du LRDE.

2.4.2  Configuration logicielle

2.4.2.1  Base logicielle

Le LRDE utilise le système de paquet de Debian afin de faciliter l’installation de tous les paquets requis par les différents projets sur chaque machine. N’importe qui pouvant travailler sur n’importe quelle machine, il faut garantir une base commune de logiciel installés.

Pour cela, chaque machine est installé par défaut avec tous les logiciels indispensables pour chacun des projets du LRDE.

En plus de cela, tout le monde disposant d’un compte LRDE possède certains droits systèmes comme installer des paquets en passant par la commande sudo.

2.5  Bibliothèque

Emprunts de livres

Beaucoup de livres ont déjà disparu de la bibliothèque, et nous sommes donc contraints d’adopter des consignes assez strictes.

• Interdiction formelle de prêter des livres à des non LRDE.
• Les étudiants du laboratoire n’ont pas le droit de sortir les livres du laboratoire à moins de le consigner auprès de Daniela Becker.

Commandes de livres

N’hésitez pas à proposer des achats aux permanents.

2.5.1  Classification EPITA des publications

2.5.2  Classification LRDE des publications

C’est également la structure retenue pour ‘/lrde/doc/’. Si vous installez des publications ici, il serait très apprécié de prendre le temps de lui donner une entrée BibTeX dans ‘share’, et que cette entrée BibTeX ait un champ lrdedoc qui pointe sur cette publication.

2.6  Les Bureaux du LRDE

2.6.1  Paritalie

Nos locaux sont dans un bâtiment hébergeant de nombreuses sociétés qui tiennent au standing de l’ensemble. Le propriétaire donne donc des consignes très strictes quant aux comportements admissibles. Réfléchir un peu suffira pour savoir ce que l’on peut ou ne peut pas faire, mais pour vous aider:

• ne pas faire de sitting dans les escaliers
• ne pas faire d’attroupements avachis à fumer sa clope etc.
• ne pas s’entraîner au roller dans la cour
• ne pas rentrer en roller dans le bâtiment
• ne pas attacher de vélo à un endroit quelconque de la cour
• etc.

2.6.2  L’allure

La direction nous reprend régulièrement sur divers sujets relatifs à l’allure, la propreté du LRDE. Croyez bien que nous ne sommes pas toujours d’accord avec ces remarques, en revanche certains points sont à respecter…

• Les livres inutilisés seront plus utiles dans la bibliothèque.
• Veillez en permanence à ce que rien de gênant ne soit visible:
  • consoles de jeu, cartouches, joysticks
• Les déchets sont mieux installés dans la poubelle qu’à côté.
• Les fonds d’écrans indécents sont à exclure.
• Le labo devrait être plus beau pour les JPOs.
• Le couloir doit aussi être dégagé. Lorsqu’on l’on y dispose des choses qui doivent être jetées ou récupérées, préférer le stockage dans nos salles dans la mesure du possible, et s’assurer que l’enlèvement est bien demandé. Typiquement, c’est le soir que l’on dépose des objets pour enlèvement avant la porte du couloir en ajoutant un papier demandant l’enlèvement.

En aucun cas les activités compromettantes ne doivent être visibles depuis le couloir, quel que soit l’heure et le jour. Il n’est pas interdit de jouer, il n’est pas acceptable que ça se voie depuis le couloir. Par ailleurs, pour ce genre de chose faites en sorte de ne pas tourner le dos à la porte.

2.6.3  Vigilance

Des vols ont déjà eu lieu au LRDE, et il n’y a aucune raison pour que ça ne recommence pas. Nous sommes tous concernés, nous devons tous être vigilants.

• Ne laissez pas d’objet de valeur visible non attaché, surtout près de la porte d’entrée.
• Si vous êtes au fond du labo ou dos à la porte, fermez la porte. Si en plus vous mettez un casque, verrouillez la porte.
• Quand la salle est vide, fermez la porte.
• Les individus manifestement en train de visiter le bâtiment, possiblement soi-disant pour chercher une machine à café, doivent être éconduits, ou signalés au gardien. Prévenir le labo de l’événement.

2.6.4  Accès au LRDE

L’accès au LRDE la nuit peut poser des problèmes avec les gardiens. Il faut savoir que dans la version Courtois, nous pouvons rester et rentrer à toute heure (i.e., aucune limitation), et dans la version gardien de jour, seulement avant minuit (voire 22h les nuits de pleine lune). Ce différend est récurrent... Il existe une feuille signée par le gérant de Paritalie listant les personnes autorisées à rentrer après 22h. Cette feuille peut être photocopiée et présentée au gardien afin de prouver votre droit.

Pour se signaler au gardien, trois possibilités:

• la sonnerie rue Salengro. Ce n’est pas un interphone, mais ça sonne à l’accueil Paritalie.
• l’interphone du garage (qui sonne à l’accueil Paritalie). Le bouton de l’interphone est dur: appuyer fort jusqu’à ce que vous entendiez une sonnerie de téléphone (à peine audible). Parlez fort.
• le numéro de téléphone du gardien: 01 46 71 34 05

L’accès après 22h se fait par l’entrée rue Salengro, car la loge du gardien de jour se situe près de l’autre entrée et l’oreille de celui-ci serait sensible à l’ouverture d’un portail.

Pour minimiser les tensions:

• ne pas sortir comme par hasard juste après que le gardien ait fermé les grilles. Pensez à vous acheter vos sandwiches avant 22h !
• minimiser les A/R (départs/arrivées groupés etc.)

La nuit, ne pas introduire de personnes qui ne sont pas sur les listes données au gardien. Restez plus intelligents que lui, et surtout évitez de faire monter la tension. S’il ne veut pas vous laisser reporter les problèmes sur la main courante, faites le sur une feuille de papier que vous nous donnerez dès le lendemain.

2.7  Année typique

Janvier

• Bilan et rapport d’activité du labo ; séminaire CSI ING3.

Février

• Départ des CSI ING3.
• Retour des CSI ING2 de leur stage.
• Possibilité de recrutement d’ING2.

Mars

Avril

• Implication des permanents dans les oraux du concours Advance.
• Décider de dates pour Fontainebleau (généralement entre juin et juillet).

Mai

Juin

• Séminaires CSI ING1 et ING2.

Juillet

• Soutenances de stages de fin d’études.

Août

Septembre

• Départ des CSI ING2 en stage.
• Présentation du LRDE aux InfoSup (requête de la direction).

Octobre

Novembre

• Présentation du labo aux ING1, préparation au recrutement.
• Appel à candidatures pour le LRDE.

Décembre

• Recrutement d’ING1.
• Récupération des notes de partiels et de projets.
• QCM pour les candidats ING1.
• Un mercredi soir: recrutement.

2.8  Dépôts Git

Le labo utilise Git comme système de gestion de version. Historiquement, Subversion (SVN) était également utilisé, mais la plupart des dépôts ont été convertis à Git ou transformés en lecture seule.

Avant toute utilisation de Git au labo, apprenez-lui votre nom et votre adresse e-mail :

La liste des dépôts est visible sur ici : https://gitlab.lrde.epita.fr. La première chose à faire est de demander l’accès au groupe LRDE : https://gitlab.lrde.epita.fr/lrde.

D’anciens dépôts sont encore disponible sur gitolite, l’ancien serveur git. La liste des dépôts est accessible à l’adresse suivante : https://svn.lrde.epita.fr.

2.9  Newsgroups LRDE

Le labo dispose d’un serveur de news (NNTP) accessible à l’adresse news.lrde.epita.fr.

Les news sont également accessibles depuis l’extérieur, en NNTPS, avec authentification par login et mot de passe (le même que pour le compte mail). Voici les paramètres à utiliser:

serveur

news.lrde.epita.fr

chiffrement

SSL/TLS

port

563 (port par défaut)

2.10  ‘/lrde/doc’

Le répertoire ‘/lrde/doc’ contient diverses publications, externes ou internes. Certains répertoires contiennent un index, ‘contents.bib’, au format BibTeX.

2.10.1  ‘contents.bib’

Un exemple:

Merci de suivre les règles suivantes dans les fichiers BibTeX. Cela s’applique tout particulièrement à ‘bib/lrde.bib’ (dans le dépôt git@gitlab.lrde.epita.fr:lrde/share) qui est utilisé dans beaucoup d’endroits différents.

• Utilisez des accolades, et non des guillemets.
• Utilisez un jeu de caractères ascii de telle sorte que nous puissions mettre ces entrées Bib sur le Web (pour des utilisateurs n’utilisant pas forcément Latin 1).
• Alignez les signes ‘=’.
• Mettez des retours à la ligne.
• Les clés sont author.year.conf. La clé devrait être le nom du fichier enregistré dans le même répertoire.
• N’utilisez pas de mots en capitales, à moins que ce ne soit absolument nécessaire.
• Le champ month doit indiquer uniquement les trois premières lettres du mois en anglais, sans accolades.

2.10.2  ‘lrde/papers’

Ce répertoire contient toutes les publications et soumissions du LRDE. N’y incluez pas de rapports techniques.

Le fichier ‘bib/lrde.bib’ du dépôt git@gitlab.lrde.epita.fr:lrde/share indexe toutes ces publications. Utilisez le champ note pour spécifier le statut du papier: «Submitted» ou «To appear». D’autres annotations utiles peuvent être les éventuels prix, ou «In French».

2.10.3  ‘csi’

Ce répertoire contient des documents utiles à la scolarité CSI.

On y trouve notamment les consignes de stage de fin d’étude du service des Relations Entreprise de l’EPITA. Ce document recense – entre autres – les points que les étudiants doivent suivre lors de la rédaction de leur rapport, et que les correcteurs se doivent de vérifier (plan, contenu attendu, etc.).

Ce répertoire contient également des cours d’étudiants (documents électroniques ou numérisés), anciens ou actuels, qui peuvent être utiles aux étudiants de CSI. Si vous souhaitez faire plusieurs copies papier de ces cours, vous êtes invités à utiliser une photocopieuse; l’imprimante du LRDE ne doit en aucun cas être utilisée pour des tirages multiples de documents volumineux, a fortiori lorsqu’il s’agit d’images.

Chapitre 3  Communication

3.1  Décharges

Nous savons tous que les règles suivantes sont stupides, mais notre histoire nous a conduit à les décider pour éviter les problèmes inutiles.

Lorsque vous êtes politiquement incorrect merci d’éviter toute mention du LRDE dans votre message, pas même dans votre ‘From:’. Ceci s’applique tout particulièrement pour les forums de l’école.

Lorsque vous faites appel à un pseudo pour ne pas mouiller le LRDE, veuillez en prendre un de bon goût. Le laboratoire a suffisamment de détracteurs pour que leur donner de quoi critiquer soit totalement superflu. Ceci s’applique au contenu également: veillez à rester corrects, même si «ce n’est pas vous qui avez commencé».

3.2  Actualités

3.2.1  Que sont les actualités

Chaque évènement (public) notable est une news. Cela inclut:

• une nouvelle publication
• les séminaires CSI
• les journées à thème
• la sortie d’une nouvelle version
• un nouveau membre (ou stage, ou sabbatique)
• un nouveau contrat
• une nouvelle importante sur un ancien membre (par exemple, soutenance de thèse, Prix Nobel...)

et ainsi de suite.

Chaque nouvelle doit être signalée:

sur nos pages

La page News a deux buts: en plus des nouvelles détaillées, de courts extraits sont affichés sur la page principale. Envoyez votre texte pour publication sur le WIKI à Daniela.

sur les newsgroups de l’école

Si vous avez une nouvelle importante, envoyez votre texte (en Français) à Daniela qui le postera sur les newsgroups epita.adm.adm, epita.adm.com, and epitech.adm.com.

à la liste de diffusion «annonce» (annonce@lrde.epita.fr)

Voir section 3.2.2.

3.2.2  Les messages d’annonce

La liste «annonce» (annonce@lrde.epita.fr) (répliquée dans le forum annonce.lrde.epita.fr) inclut des membres de l’adm (au moins Joël Courtois, Fabrice Bardèche et Christian Dujardin), des anciens du labo, l’équipe communication d’EPITA, les membres du conseil scientifique, mais aussi des extérieurs intéressés par l’actualité du labo. La communication s’y fait souvent en français, sachant que de toutes façons les actualités sur notre site Web sont, elles, en anglais.

Étant donné les abonnés, il faut soigner les messages. Ça signifie par exemple inclure le résumé de l’article (un exemple d’annonce de publication), l’édito et/ou le sommaire pour l’«l’air de rien», etc. N’oubliez pas de publier des URLs courtes (section 3.6). Les étudiants doivent envoyer leur texte à Daniela pour diffusion par elle.

Voici quelques exemples d’annonce.

3.2.2.1  Parution de l’air de rien

3.2.2.2  Publication

3.3  Journées Portes Ouvertes (JPO)

L’EPITA organise régulièrement des journées portes ouvertes, auxquelles le LRDE se doit de participer. La liste des dates est disponible sur l’Intranet LRDE, à l’adresse https://www.lrde.epita.fr/Intra/RecrutementEpita. Les permanents doivent se partager les tâches de présence à ces événements et s’inscrire sur cette même page du Wiki. Les étudiants CSI sont invités à participer aux JPO (cf. infra).

3.3.1  De l’importance des JPOs

Les JPOs ont une double importance pour le labo.

D’abord c’est par les JPO que l’école rencontre les étudiants les plus intéressants, ceux qui feront l’avenir de notre école, de votre diplôme, et peut-être aussi dans quelques années, du LRDE. Si vous avez foi dans votre école, comme nous l’avons, alors vous devez sentir à quel point il est vital qu’elle soit belle durant les JPOs. N’oubliez pas que le discours Epitech est beaucoup plus séduisant que le nôtre: c’est plus dur d’expliquer à un terminal que non, vraiment, il faut faire des maths et des sciences et en chier pour être un bon informaticien quand à côté on montre les réalisations des meilleurs et l’absence de cours «inutiles». La santé d’EPITA n’est pas acquise éternellement, elle doit être défendue en permanence par chacun. En interne, il faut continuer de se battre pour corriger ses tares congénitales, en communication externe, il faut être positif.

Le deuxième point est presque plus important encore: se joue l’image du LRDE au sein de l’école aux yeux de l’école. Bien trop souvent le LRDE et CSI se distinguent des autres, sortent du rang. Dans une certaine mesure, c’est bien et c’est notre rôle. Quand c’est exagéré, on passe pour imbus de nous-mêmes, avec un complexe de supériorité vis-à-vis des basses besognes dont se charge le reste de l’école. Les JPOs sont une opportunité de montrer qu’on est là, et que comme les autres, on tient à l’école, pas seulement au labo. Alors montrez-vous ici, montrez-vous là-bas, soyez pro-actifs: montrez aux visiteurs comme au reste de l’EPITA que le LRDE fait cause commune.

3.3.2  Participation à une JPO

Au cours d’une JPO, les permanents et les étudiants CSI présents doivent accueillir les visiteurs et leur présenter le laboratoire. Essentiellement, cela recouvre:

activités

Enseignement, recherche, développement ;

CSI

Son fonctionnement original au sein de l’EPITA (la formation par la recherche offerte par la majeure CSI). Environ 5 CSI par promo EPITA. Un sur deux qui va vers Master/Doctorat.

thèmes de recherche

Ne surtout pas rentrer dans les détails, quelques idées suffisent (e.g., expliquer «performance et généricité» est déjà une performance en soi). Les posters (et particulièrement celui de galaxie) sont une très bonne aide.

projets

Pareil, pas de détails, mais insister sur l’aspect pratique: quelque soit le degré d’abstraction, tout ici termine par de l’implémentation.

etc

Soyez créatifs.

Quelques remarques:

• Le labo doit être présentable, voir section 2.6.2.
• Il faut être proactif et ne pas simplement se mettre dans son coin en espérant qu’on ne viendra pas vous ennuyer. Au contraire, il est important de prendre contact avec les épitéens en charge des visites pour être certains qu’ils sachent où nous nous trouvons (il y a beaucoup d’étudiants de prépas qui ne le savent pas), et les encourager à passer par le labo.
• L’auditoire est essentiellement constitué de gens qui ne savent pas ce que nous faisons ⇒ expliquer de façon simple.
• Ne surtout pas rentrer dans les détails, ça ennuie rapidement.
• C’est plus sympa d’être plusieurs (versus «être tout seul») lors d’une JPO ⇒ étudiants CSI, n’hésitez pas à venir aux JPO ! D’autant plus que vous êtes sans doute les mieux à même de parler de la scolarité CSI (et de répondre aux questions des futurs padawan !) ;
• le flux de visiteurs n’est pas constant, et certaines journées très faible (inférieur à dix candidats) ; il est donc possible de travailler au laboratoire en parallèle, sous réserve qu’au moins une personne soit disponible (ou puisse interrompre son activité du moment) afin de présenter le LRDE aux nouveaux arrivants.

3.4  Publications

3.4.1  Rédaction

dépôt

Les sources des articles que vous écrivez et soumettez aux conférences et revues doivent être stockées à un endroit raisonnable. Nous vous invitons à créer un dépôt sur le gitlab pour chaque article. Attention cependant, les sources des rapports CSI (et des rapports techniques en général) doivent être placées dans le dépôt ‘lrde/techreps’ (cf. 4.4.2). Le dépôt ‘lrde-publis’ (git@git.lrde.epita.fr:lrde-publis) est considéré comme obsolète, mais il peut être intéressant d’y jeter un oeil, par exemple pour savoir comment construire un Makefile complet à partir des morceaux proposés dans ‘share’ (cf. infra). Une pratique courante consiste à utiliser ‘share’ comme un sous-module Git du dépôt de l’article courant.

Les articles sont identifiés par une clef de la forme ‘author.year.conf’ où ‘author’ est le nom du premier auteur, ‘year’ est l’année sur deux ou quatre chiffres et ‘conf’ est un sigle de la conférence ou de la revue ciblée. Vous êtes priés d’utiliser ce format d’identification lorsque vous ajoutez un article à un document .bib du LRDE.

share

Le dépôt Git ‘share’ (git@gitlab.lrde.epita.fr:lrde/share) fournit de nombreux services qui peuvent vous faciliter la rédaction en L^AT_EX: des styles, des bibliographies, des bouts de Makefile, etc. Consultez ‘share/README’ pour en savoir plus.

Historiquement, ‘share’ était un sous-répertoire du dépôt Subversion ‘lrde-publis’ (https://svn.lrde.epita.fr/svn/lrde-publis). Ce répertoire a été converti en dépôt Git (git@gitlab.lrde.epita.fr:lrde/share)¹ et c’est ce dernier qui est désormais le dépôt ‘share’ de référence. Les deux dépôts étaient synchronisés régulièrement, en attendant que tous les dépôts avec une dépendance sur SVN ‘share’ aient été convertis à Git. SVN ‘share’ n’est désormais plus accessible qu’en lecture seule.

Institution

Pour des raisons évidentes de référencement, il faut faire apparaître les sigles EPITA et LRDE. Par ordre décroissant de préférence, utilisez en français:

1. Laboratoire de Recherche et Développement de l’EPITA (LRDE)
2. Laboratoire de R&D de l’EPITA (LRDE)
3. Labo de R&D de l’EPITA (LRDE)
4. EPITA/LRDE

et en anglais:

1. EPITA Research and Development Laboratory (LRDE)
2. EPITA R&D Laboratory (LRDE)
3. EPITA R&D Lab (LRDE)
4. EPITA/LRDE

Les traductions dans les autres langues sont laissées en exercice pour le lecteur.

Steve Frank

N’hésitez pas à envoyer vos articles à frank@epita.fr (Steve Frank). Bien sûr il faut lui laisser un peu de temps pour travailler avec vous, du jour au lendemain c’est rarement possible.

/lrde/doc

Faites une copie (de préférence en PDF) de votre papier dans ‘/lrde/doc/lrde/papers/’, voir section 2.10.2. Oui, il s’agit bien d’inclure ici les soumissions. Ce répertoire n’est pas public, c’est seulement pour le LRDE.

Si vous utilisez un modèle construit avec le script ‘new-publication.sh’ du dépôt Git ‘lrde-publis’, qui repose sur ‘share’ (dépôt ‘lrde-publis-share’), vous pouvez installer votre papier dans ‘/lrde/doc/lrde/papers/’ en utilisant make install (voir la variable ‘papers_DATA’ du ‘Makefile’).

lrde.bib

Mettre à jour ‘lrde.bib’ en indiquant bien que l’article est «Submitted» dans le champ note. Cf. section 2.10.2.

3.4.2  Rejet

Si l’article est refusé, merci de:

• déplacer l’article de ‘/lrde/doc/lrde/papers/’ à ‘/lrde/doc/lrde/papers/rejected/’,
• retirer l’entrée de ‘lrde.bib’,
• à votre discrétion, de mettre cette entrée BibTeX dans ‘/lrde/doc/lrde/papers/rejected/contents.bib’.

3.4.3  Acceptation

C’est l’acceptation qui est l’événement, pas la parution. Voici les 3 étapes :

lrde.bib

Mettre à jour l’entrée correspondante. Ajouter des champs pour faciliter la mise à jour Wiki:

lrdenewsdate

(obligatoire) au format ‘YYYY-MM-DD’ pour qu’une page soit généré sur le Wiki;

lrdeprojects

projets (séparés par des virgules) du LRDE concerné par cette publication;

lrdekeywords

mots clés (séparés par des virgules);

lrdeinc

nom d’une page du Wiki qui sera incluse dans la page de la publication (exemple: ‘Publications/carlinet.14.icip.inc’). Une bonne pratique peut être d’utiliser la forme ‘Publications/bibtexid.inc’.

lrdepaper

URLs vers le PDF de la publication.

lrdereport

URLs vers le PDF du rapport.

lrdeslides

Idem pour les planches.

lrdeposter

Idem pour un poster.

urllrde

Ne plus utiliser.

Le fichier lrde.bib est dans le dépôt git@gitlab.lrde.epita.fr:lrde/share.git.

/lrde/doc/lrde/papers

Ajouter une copie du papier qui porte le nom ‘clef-bibtex.pdf’ (si vous n’avez pas ce répertoire sur votre machine, voire avec l’administrateur système).

Annonce

Créer une actualité et la diffuser (section 3.2).

3.4.4  Parution

Comme pour l’étape précédente, vous pouvez simplement envoyer les données supplémentaires à Daniela et lui demander de compléter.

lrde.bib

Il faut le mettre à jour avec toutes les données de la conf: les numéros ISBN, les pages de la parution etc.

/lrde/dload/papers/

Vous pouvez installer votre article dans le répertoire ‘/lrde/dload/papers/’, pour le rendre accessible depuis l’extérieur, et le référencer depuis la page Wiki correspondante. Vous pouvez aussi installer du matériel supplémentaire comme une présentation, un poster, des images ou du code, référencés depuis le Wiki également.

Si vous utilisez un modèle construit avec le script ‘new-publication.sh’ du dépôt Git ‘lrde-publis’, qui repose sur ‘share’ (dépôt ‘lrde-publis-share’), vous pouvez installer votre papier dans ‘/lrde/dload/papers/’ en les ajoutant à la variable ‘dload_DATA’ du ‘Makefile’ puis en exécutant make install.

Il est déconseillé de diffuser des papiers avant leur parution officielle (conférence, revue).

3.5  L’air de rien

L’air de rien est le bulletin du laboratoire. Il sert à véhiculer de l’information du LRDE vers l’extérieur de façon informelle (annonces de publications, de releases, de recrutements, de séminaires ; vulgarisation de travaux réalisés au laboratoire ; présentation de projets internes ou communs ; etc.).

Sa fréquence de publication n’est pas fixe. Cependant, des numéros spéciaux sont édités en amont d’événements récurrents (rentrée de septembre, séminaires CSI). De temps à autre, nous essayons également de publier un numéro «spécial anciens» relatant le parcours d’étudiants CSI diplômés.

3.5.1  Rédaction

Rédacteur en chef

Avant de commencer un nouveau numéro, un rédacteur en chef doit être choisi. Son rôle est de collecter les articles du nouveau numéro et de vérifier la mise en page de celui-ci.

l-air-de-rien

Le sources des numéros de L’air de rien sont stockées dans le dépôt ‘l-air-de-rien’ (git@git.lrde.epita.fr:l-air-de-rien). Le dépôt ‘l-air-de-rien’ fournit un script ‘new-edition’ à utiliser pour créer un nouveau numéro à partir d’un modèle (situé dans le répertoire ‘template’). Il fonctionne comme suit :

1. Si vous ne l’avez pas déjà récupéré, clonez le dépôt ‘l-air-de-rien’:
   94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 53 14 59 22< $ git clone --recursive git@git.lrde.epita.fr:l-air-de-rien $ cd l-air-de-rien

   Sinon, mettez simplement votre copie à jour:

   $ cd l-air-de-rien $ git pull --rebase
2. Lancez ensuite le script ‘new-edition’ en lui passant le numéro du nouveau bulletin :
   $ ./new-edition 51

   Le script crée un répertoire (ici ‘51.0’) avec un squelette de bulletin prêt à l’emploi. En particulier, il inclut une copie du répertoire ‘share’ sous forme de sous-module Git, contenant de nombreux outils pour la rédaction de documents avec L^AT_EX, tels des styles L^AT_EX, des bibliographies BibTeX, des éléments de ‘Makefile’, etc.

3. Enregistrez le nouveau numéro et poussez-le sur le serveur:
   $ git ci -m "New issue: L'air de rien 51.0." $ git push origin master
4. Par la suite, vous pouvez utiliser make dans ce nouveau répertoire pour construire votre article, make view pour l’afficher et make clean pour tout nettoyer. La commande make booklet produit une version livret (au format A5) du bulletin. Enfin, make install installera le bulletin (en versions A4 et livret A5) dans ‘/lrde/dload/bulletin’, diffusé sur le site Web du laboratoire à l’adresse http://www.lrde.epita.fr/dload/bulletin/.

3.6  URLs

Publiez les URLs courtes lorsqu’elles existent. Elles sont plus élégantes, mais aussi plus robustes puisque nous sommes susceptibles de remplacer TWiki MediaWiki dans le futur.

• http://olena.lrde.epita.fr
• http://vcsn.lrde.epita.fr
• http://publis.lrde.epita.fr/demaille.13.ciaa
• http://projects.lrde.epita.fr/Nolimips

En particulier, évitez les URLs contenant ‘wiki’ et autres:

• https://www.lrde.epita.fr/wiki/Publications/demaille.13.ciaa
• https://www.lrde.epita.fr/wiki/Olena

3.7  Séminaires CSI

Ci-dessous les instructions pour monter une session de séminaire CSI. Elles concernent tant les orateurs que les maîtres de cérémonie («chairmen»).

3.7.1  Organisateur du séminaire CSI

Cette section détaille la liste des tâches pour monter un séminaire. Elles sont à peu près présentées dans l’ordre chronologique.

Choix des dates

Choisir les dates le plus tôt possible. Attention aux autres événements (English Week etc.). Faire le préprogramme: décider du découpage thématique, éviter les journées void *.

Remise des sujets

Arrêter la date de rendu des sujets de séminaire CSI.

Le Wiki

Faire une page Wiki par séminaire, ‘Seminar.YYYY-MM-DD’. Si le jour est inconnu, prendre ‘Seminar.YYYY-MM’ puis, après le séminaire, la renommer.

Demander un résumé aux orateurs (voir section 3.7.3, l’item correspondant).

La salle

Demander une salle à Pedro Miranda ; l’Amphi 3 de préférence, car on souhaite filmer le séminaire et cet amphi est équipé pour les captations. À mettre sur le Wiki. Typiquement réserver la salle pour une heure avant le début du séminaire, de façon à pouvoir vérifier la salle avant de commencer, et la garder jusqu’à 19h00 au cas où.

Chronos

Demander à Pedro Miranda de le mentionner dans les emplois du temps des étudiants. Ceci est une demande de la direction.

Le programme du séminaire CSI

Faire un premier programme. Entre trois exposés de 30 minutes (tout compris) mettre un quart d’heure de pause.

Ne pas dépasser 4h-4h30 de présentation. Quand c’est une après-midi, on commence à 14h, la fin ne doit pas dépasser 18h30.

L’air de rien

Faire faire les numéros spéciaux par les orateurs. Nommer un responsable de chaque numéro.

Le poster

Pour la préparation du poster, il existe un script sur lrde-csi-seminars. Envoyer le pdf à Daniela pour impression en A3. En tirer pour le KB, VJ, mais aussi ailleurs (e.g., ENST etc.).

J - 2 semaines: Vérification

Vérification des points précédents. Envoi du programme dans les news (section 3.2) et mise à jour du site des actualités du laboratoire. Ne pas oublier la date et l’heure, le lieu, l’URL et le programme.

J - 1 semaine: Transparents

Demander les transparents aux orateurs. Avant la dernière semaine, s’assurer que tous ont bien eu au moins une répétition avec d’autres étudiants, puis une répétition avec un permanent.

J - 1

Refaire une annonce. Mettre tous les transparents sur un portable, ainsi que les transparents de présentation de la séance du jour suivant.

Jour J

Le premier orateur doit être en place 15 min avant le début. En particulier s’assurer que le vidéoprojecteur marche correctement.

J + 1

Demander un tirage papier des transparents pour relecture et correction par un permanent. Lorsque les transparents ont reçu cet aval, les mettre en ligne.

3.7.2  Sujet d’un exposé au séminaire CSI

Afin d’éviter tout malentendu entre les étudiants, les encadrants et l’ensemble du laboratoire, les sujets d’exposé et de rapport doivent faire l’objet d’une approbation par l’ensemble des permanents. Pour ce faire…

• Rédigez un sujet comprenant titre et résumé en anglais et français. En plus du thème de travail, précisez les objectifs, de façon la plus mesurable possible.
• Créez une entrée dans ‘csi.bib’ avec ces items. Les champs author, title, titre, abstract et resume doivent impérativement être renseignés. Après avoir modifié ‘csi.bib’ et avant de faire un commit, exécutez make neat à la racine de ‘share/’.
• Créez une impression L^AT_EX de votre sujet à l’aide du script share/bin/abstract (qui va lire ‘csi.bib’).
• Faites signer ce sujet par votre permanent encadrant dans les délais (la pénalité habituelle -1pt/j s’applique).
• Remettez cette feuille à Daniela.

Ne faites pas l’erreur d’appeler votre travail un séminaire. Le séminaire désigne la séance pendant laquelle vous ferez un exposé de vos travaux. Le résumé que vous rédigez apparaîtra sur votre rapport et sera aussi utilisé pour annoncer votre exposé: évitez donc d’y employer les mots «séminaire», «exposé» ou «rapport».

3.7.3  Préparation d’un exposé au séminaire CSI

Lire aussi les sections 3.7.1 et 3.7.2. Prendre connaissance des commentaires quant à l’écrit et l’oral, section 3.9.

Sujet

Cf. section 3.7.2.

Nombre

Les exposés communs ne sont pas tolérés. Vous pouvez faire une introduction commune, et c’est même recommandé. Vous pouvez écrire un rapport commun. Mais chaque orateur doit ensuite avoir un temps de parole clairement démarqué.

Durée

Visez 20 min d’exposé, puis 10 min de questions. Vous pouvez avoir plus de temps, mais exclusivement si vous le faites savoir très à l’avance.

Résumé (abstract)

Écrivez un résumé en français et en anglais pour le Wiki. Inclure:

• sa durée
• son titre
• votre nom TWiki
• un résumé (accentué) de quelques lignes décrivant le contexte, le problème, votre approche, le plan.
• quelques mots-clés.

Préparation

Faire de bons transparents prend beaucoup plus de temps que vous ne le croyez. Donnez vous une semaine au moins. N’attendez pas le dernier moment pour préparer votre exposé.

Transparents

• Faites du paysage, pas du portrait.
• Choisissez le format que vous voulez: PDF, PS, DVI, ADVI... Mais assurez-vous que le portable le supporte.
• Utilisez exclusivement des figures en format vectoriel (typiquement du PDF, mais pas de PNG, GIF etc.).
• Comptez en moyenne 2 à 3 minutes par transparent.
• Mettez tout sur le portable le matin du séminaire au plus tard.
• Utilisez Beamer (une classe L^AT_EX).
• Pensez à utiliser ‘share/’ qui, entre autre, fournit le thème Beamer KremlinBicetre prêt à l’usage.
• Écrivez vos transparents en anglais.
• Faites apparaître des numéros de transparents (pour faciliter les questions et les corrections).
• Incluez la bibliographie dans vos transparents mais sans nécessairement la montrer: elle est surtout là pour ceux qui liront vos transparents depuis l’Internet.

Mettez les transparents en PDF sur Publications après la présentation et après validation par un permanent. Vous pouvez mettre d’autres formats en complément du PDF.

Exemples d’erreurs courantes:

• Passer 15 min à présenter le contexte d’un projet ne laissant que 5 min sur le projet lui-même et son futur.
• Faire des transparents trop pleins qu’on n’a pas le temps de lire.
• Lire les transparents à voix haute.
• Laisser des erreurs manifestes de style, typographie ou orthographe. En particulier soyez sûrs d’être très mal notés si un correcteur orthographique n’a pas été utilisé.
• Utiliser des figures denses et incompréhensibles, mais indispensables pour comprendre.
• Mettre trop d’exemples pour illustrer une idée.
• N’avoir qu’une seule figure UML pour présenter un projet (une figure avec 20 classes est probablement illisible).
• Montrer des bouts de code 100 colonnes, 30 lignes.
• Utiliser des couleurs pâles qui tendent vers le blanc avec certains vidéoprojecteurs (ne vous fiez pas au rendu sur un écran).
• Utiliser des polices toutes petites.

Répétitions

Faites plusieurs répétitions quelques jours avant avec des étudiants. Après avoir tenu compte de leurs commentaires, faites une répétition avec un permanent. Faites ça en avance: on ne conseille à personne d’apprendre le matin du jour J que l’exposé n’est pas bon.

3.8  Journées thématiques

Préparer des évènements comme OlenaDay, VcsnDay etc. en n’oubliant rien nécessite une liste de contrôle. Elle est destinée aux:

Orateurs

Les personnes qui vont vraiment s’occuper de la partie enseignement.

Organisateurs

Les personnes qui vont faire en sorte que les orateurs puissent faire et fassent leur travail.

Pour l’instant, lisez seulement les sections correspondantes pour les séminaires CSI: sections 3.7.1 et 3.7.3.

3.9  Faire de bonnes publications

Une lecture attentive de cette section est indispensable avant de rédiger un rapport ou article, mais également en phase de relecture: de nombreuses erreurs courantes y sont consignées. Produire un rapport avec certaines de ces erreurs est un moyen sûr d’obtenir une note exécrable.

3.9.1  Avant propos

Écrire n’est pas aisé, et nous avons tous fait les mêmes erreurs. Ce n’est pourtant pas une fatalité pour peu que vous prêtiez attention à éviter les erreurs les plus classiques, et que vous suiviez les guides qui suivent.

Une fois ces propos bien compris, vous êtes invités à consulter d’autres sources, telles que:

Guide d’écriture pour les jeunes auteurs – ACM

http://web.archive.org/web/20100528233157/http://www.acm.org/crossroads/doc/information/wg/text.html

Academic Writing for Graduate Students

Livre disponible dans la bibliothèque du LRDE.

The Elements of Style – William Strunk Jr., E.B. White

Published by Pearson Allyn & Bacon; 4th edition (January 15, 2000); ISBN: 020530902X.

Ce petit livre (105 pages) est parfait pour les personnes qui veulent améliorer leur prose anglaise. Il est assez célèbre, et, en plus de fournir des règles d’écritures utiles, il contient des règles qui sont littérairement intéressantes ! Par exemple “The writer must, however, be certain that the emphasis is warranted, lest a clipped sentence seem merely a blunder in syntax or in punctuation”.

Vous pouvez trouver la plus courte First Edition of The Elements of Style en ligne.

Mathematical Writing – Knuth et al

Ce livret archive le cours d’Écriture des Mathématiques donné par Don Knuth à Stanford en 1987. Parmi les 31 cours apparaissent comme invités Herb Wilf, Jeff Ullman, Leslie Lamport, Nils Nilsson, Mary-Claire van Leunen, Rosalie Stemer, et Paul Halmos.

Le livre est à la bibliothèque du LRDE. Une version est disponible sur le net: Mathematical Writing – Knuth et al.

Writing Advice for Students

http://www.clt.mq.edu.au/~rdale/resources/writingnotes/index.html

3.9.2  L’écriture de papiers et de rapports

Il est très important de prêter beaucoup d’attention à la qualité de vos écrits. La plupart des lecteurs sont d’abord sensibles au style, à la clarté, et la concision; avant même d’essayer de comprendre ce que vous écrivez. Et effectivement, c’est plutôt naturel. Voici quelques conseils sur la manière d’écrire vos papiers et vos rapports de sorte à ce que vous ayez effectivement des lecteurs…

3.9.2.1  Plan d’un rapport

Vos écrits doivent être bien structurés, sémantiquement parlant. Cela implique que les choses n’iront probablement pas par ordre chronologique. Essayez plutôt d’imaginer les attentes d’un lecteur néophyte: quel est le but / la direction globale du travail, quels sont les différentes étapes à effectuer etc.

Voici le plan typique à suivre pour les rapports CSI.

Titre

Il doit être compréhensible et décrire le contenu du rapport. Évitez les phrases.

Abstract/résumé

De l’ordre de 10 lignes chacun, ils introduisent le domaine, la problématique et la contribution du rapport. Il s’agit d’un résumé pour l’humain pressé qui doit comprendre rapidement si ce rapport le concerne ou pas.

Table des matières

\tableofcontents.

Autres tables

Uniquement si c’est pertinent, vous pouvez inclure une table des figures, tableaux etc.

Introduction

D’une à plusieurs pages selon qu’elle contient ou non l’état de l’art.

Elle doit comprendre les parties suivantes:

Introduction

Une introduction avec le contexte général de votre travail, une description des problèmes auxquels vous voulez répondre et comment vous y répondez.

L’introduction doit capturer le lecteur et lui donner envie de lire la suite. Elle doit donner assez d’informations pour que celui-ci puisse comprendre l’intérêt de votre travail et la portée de vos résultats.

Contributions

Une liste explicite et synthétique de vos contributions. Annoncer à l’avance au lecteur les résultats importants que vous avez obtenus: un article scientifique n’est pas un roman à suspense.

Plan

Annonce du plan du rapport, typiquement une phrase par chapitre.

Remerciements

Tout rapport doit être relu avant rendu. Remercier ici les CSI qui vous ont relu et corrigé avant soumission aux permanents.

Contexte/État de l’art

Présenter plus en détail le cadre de travail, la problématique, et l’existant. C’est d’ici que doivent partir la plupart des références bibliographiques. S’il y a des prérequis, des notions que devraient connaître le lecteur, c’est ici (ou en annexe) qu’il faut les mettre. Vous êtes invités à maintenir dans chaque projet une collection de morceaux de texte prêts à l’usage. Par exemple le projet a souvent besoin de revenir sur les bases des transducteurs; il est alors stupide de taper à nouveau cette introduction. Il vaut mieux maintenir une base commune, et clairement faire apparaître ses auteurs.

Corps du document

La substantielle moelle de votre travail. Autant de chapitres que nécessaires pour articuler votre présentation, en commençant généralement par les questions bibliographiques. Si votre document se compose de plusieurs parties indépendantes, il est acceptable de disséminer le contenu bibliographique dans les différents chapitres auxquels ils appartiennent.

Mesures

Analyses de complexités, résultats des campagnes de test, benchmarks, comparaison avec d’autres outils.

Discussion

Comparaison avec d’autres. Peut être faite en trois temps:

Previous Work

Ce qui a déjà été fait auparavant. Rejoint l’état de l’art. Les deux sections ne sont pas nécessaires.

Related Work

Ce qui est analogue, ce qui inspire, mais n’est pas tout à fait la même chose.

Future Work

Ce que vous comptez faire par la suite.

Conclusion

Quelques paragraphes. Une conclusion qui résume clairement le contenu de votre rédaction, dans le même ordre que le contenu présenté était détaillé. La conclusion doit ensuite mettre l’accent sur les principaux intérêts / fonctionnalités de ce que vous avez présenté et mettre en avant votre travail.

Ne pas se contenter de faire une resucée du résumé. D’ailleurs, ce n’est pas une «synthèse», c’est une «conclusion». En d’autres termes, ne pas s’arrêter à un résumé de l’article, mais finir en ouvrant le débat: quelles pistes restent encore à explorer, quels nouvelles questions ou problèmes se posent, quels autres sujets semblent liés etc.

Bibliographie

Voir section 3.9.2.3.

Annexes

Listings trop longs, graphiques en séries (e.g. pour les mesures de performance), etc.

Index

Inclure un index. Les indexes font généralement la différence entre un livre que l’on ne lit qu’une fois, et un livre que l’on peut lire plusieurs fois.

3.9.2.2  Organisation

Du général au détail

Allez toujours du général vers le détail. N’ayez pas peur d’être redondant de temps en temps. Cela ne signifie pas qu’il faut redire les choses différemment dans le même paragraphe; ce serait inutile. Mais de temps en temps, il est agréable de revoir une chose qui a été vue dans un chapitre précédent, quand elle est nécessaire pour comprendre ce qui vient après.

Structure claire

Faites en sorte que la structure et la logique de votre document apparaisse toujours très clairement. Il doit toujours y avoir une raison logique de passer d’une section à une autre. S’il n’y en a pas, alors quelque chose ne va pas avec votre raisonnement. La majorité des articulations structurelles doivent aussi être explicites. Par exemple, le lecteur apprécie beaucoup un court paragraphe disant quelque chose tel que "Dans le chapitre précédent, nous avons vu ceci et cela. Cela amène telle et telle questions, ce qui est le sujet de ce chapitre". Autrement dit, ne laissez pas l’utilisateur deviner votre structuration. Dites-lui explicitement comment elle s’organise.

Contributions

Faites toujours apparaître clairement ce qui est votre travail, et ce qui provient de la bibliographie. Cela va aider le lecteur à saisir l’intérêt de ce qu’il lit : où est la nouveauté, quel est l’actuel état de l’art.

Prérequis

Faites toujours apparaître très clairement les pré-requis, et aussi tôt que possible : si une certaine connaissance est requise pour pouvoir lire votre document, dites-le, et fournissez des références. Encore une fois, cela est vrai même pour ce qui vous semble évident. Si vous supposez que le lecteur a une connaissance rudimentaire de la syntaxe d’OCaml, ne le présumez pas. Dites-le.

Le début à la fin

Écrivez l’introduction et la conclusion en dernier. N’écrivez le résumé que lorsque tout le reste est écrit. Le résumé devrait venir plutôt facilement lorsque le document est écrit, excepté le fait que vous devez résumer un chapitre entier en une seule phrase bien sûr.

3.9.2.3  Bibliographie

Conséquente

Incluez toujours une bibliographie conséquente, même pour les choses que vous trouvez évidentes. Rien n’est évident pour tout le monde, et il vaut mieux avoir trop de références que pas assez.

Classez

En cas d’équivalence, préférez dans l’ordre décroissant article de revue, article de conférence, rapport technique.

Promotion

Il faut promouvoir les articles existants. Dans le cas de Transformers par exemple, c’est une erreur de ne citer que les rapports techniques: faire au moins référence aux publications existantes.

URLs

Ne disséminez pas les URLs un peu partout dans le document: elles sont aussi à inclure dans la bibliographie.

Wikipedia

Les URLs pour Wikipedia doivent, bien sûr, inclure la révision. Utilisez l’entrée BibTeX fournie en cliquant sur «Cite this article».

Information non publique

Si vous voulez faire référence à un travail non publié (un exposé informel, une conversation téléphonique etc.), inscrivez-le dans votre bibliographie et citez-les.

Complétude

Décrivez complètement vos entrées: se contenter du nom de l’auteur et du titre ne convient pas. Il est bien trop courant de ne pas avoir les numéros de pages, le numéro ISBN etc.

Rapports techniques

Les rapports techniques doivent être complètement qualifiés, en particulier numéro, mois et année.

Abréviations

On rencontre parfois des abréviations pour les conférences ou revues les plus connues. Évitez d’utiliser ces abréviations.

‘share’

‘share/bib’ fournit un moyen cependant de faire des références aux conférences et revues communes de façon à ce que l’on puisse utiliser ou bien la version longue, ou bien l’abréviation communément admise. Consultez ‘share/bib/acronyms.bib’ et ‘share/bib/acronyms-abrv.bib’.

Maintenez ‘share’

Utilisez les bibliographies de ‘share/bib’, et maintenez-les. Cela signifie qu’il est en général incorrect d’avoir votre propre fichier ‘article.bib’ dans votre dépôt: exploitez, complétez ceux de ‘share’, voire créez-en de nouveaux.

natbib

Nous recommandons d’utiliser ‘natbib’ et ses commandes \citep ou \citet (lire sa documentation). Voici quelques exemples:

\citet{jon90}	⇒	Jones et al. (1990)
\citet[Chap.~2]{jon90}	⇒	Jones et al. (1990, Chap. 2)
\citep{jon90}	⇒	(Jones et al., 1990)
\citep[Chap.~2]{jon90}	⇒	(Jones et al., 1990, Chap. 2)
\citep[see][]{jon90}	⇒	(see Jones et al., 1990)
\citep[see][Chap.~2]{jon90}	⇒	(see Jones et al., 1990, Chap. 2)
\citet*{jon90}	⇒	Jones, Baker, and Williams (1990)
\citep*{jon90}	⇒	(Jones, Baker, and Williams, 1990)

Groupez

Lorsque vous citez plusieurs références au même endroit, n’utilisez qu’une seule commande : \citep{geraud.05.ismm,geraud.04.jasp}. Attention, pas d’espace après la virgule.

Style apalike

Utilisez un style qui utilise les noms des auteurs dans les références dans vos rapports. À la rigueur, vous pouvez également utiliser un style numérique en crochets carrés (e.g., [1], [12] etc.) dans les rapports, mais ce n’est pas ce que nous préférons. Mais

• Ne pas utiliser le style (1), (12).
• Ne pas panacher comme dans [1], [12], [at&t].

Numérique indésirable

Si en dépit de votre requête pour un style de référence en lettre votre sortie est numérique, c’est peut-être parce que l’une de vos entrées n’a pas d’année. Dans ce cas, natbib bascule en numérique, puisqu’il n’est pas possible d’utiliser auteur+année.

\chapter

Ne créez pas un nouveau chapitre pour la bibliographie (\chapter), \bibliography le fait pour vous. Ne la mettez pas non plus en annexe.

3.9.2.4  Références

Cette section traite de \ref et consorts. En ce qui concerne l’utilisation de \cite etc., voir section 3.9.2.3.

Référence avant

Dans la mesure du possible, évitez de faire référence à des figures etc. qui apparaissent plus loin dans le document. De façon modérée, on peut renvoyer à des sections plus éloignées. Pas de contrainte pour les annexes, ni pour annoncer un plan.

Figure 1

En anglais, mettre une majuscule aux noms propres et ce qui est utilisé comme un nom propre. C’est pour cette raison qu’on écrit «See Figure 2», «in Table 3», «according to Definition 4» (ils jouent ici le rôle de noms propres), mais «in the next section», «in the following definition» etc.

\vref

Varioref est un paquetage L^AT_EX séduisant: il produit également le numéro de la page. Cependant son utilisation intensive est assez lourde à la lecture. Nous ne le recommandons pas.

\cref

Ne pas utiliser \ref, mais \cref{label} (cf. la doc de cleveref) plutôt que ‘Section \ref{label}’ pour que l’ensemble soit cliquable. Valable pour tous les types de label: section, figure, tableau etc.

Passer l’option ‘nameinlink’ (et ‘french’ si c’est le cas) au chargement de cleveref. Pour s’assurer d’une numérotation unique pour tous les types de «théorèmes», adapter ce qui suit. Ne pas utiliser \newtheorem avant d’avoir importé cleveref.

% cleveref, a replacement for autoref that allows to use newtheorem, *and* % to use a unique counter for theorem, definition, and the like. If you do % that with autoref, all the \autoref{...} appear as "Theorem ..." (instead % of "Definition ..." for instance). \usepackage[french,nameinlink]{cleveref} % Mathematical environments. Let's have a single counter per chapter, % to make it easier to find an item. \newtheorem{theorem} {Théorème}[chapter] \newtheorem{definition} [theorem]{Définition} \newtheorem{exercise} [theorem]{Exercice} \newtheorem{lemma} [theorem]{Lemme} \newtheorem{proposition}[theorem]{Proposition} \crefname{exercise}{exercise}{exercises}

Avec cleveref, ne pas utilisez ‘:’ dans les labels, mais ‘.’.

Pour convertir:

git grep -E -l 'autoref|label|ref' | xargs perl -pi \ -e 's<(\\(?:autoref|label|ref)\{.*?\})> < ($r = $1) =~ s/:/./g; $r =~ s/autoref/cref/g; $r >ge'

Comparé à \autoref, \cref sait prendre en compte correctement les différents types de théorème même s’ils utilisent les mêmes compteurs, il sait gérer les pluriels (‘voir les \cref{sec.foo,sec.bar}’), etc.

Subsubsection

Ne pas tomber dans l’excès de «Subsubsection 2.1.2», «Subparagraph 2.1.2a» etc. La seule utilisation de «Section» suffit: «Section 2.1.2», «Section 2.1.2a» (on garde «Chapter II.2» ou «Part I» bien entendu).

Compteurs

Utiliser une numérotation unique pour tableau, figure, listings etc. Il est insupportable de chercher la figure 3.2 entre les tableaux 3.5 et 3.6. Pour fusionner les compteurs, incluez le code suivant dans votre préambule, et ajustez-le.

% Use the counter of figures for tables and algorithms. \let\c@table\c@figure \let\c@algorithm\c@figure

\caption puis \label

N’oubliez pas qu’un \label dans un flottant doit être après son \caption, sinon vous ferez référence au numéro de la section courante.

myhyperref

Le paquetage ‘share/style/myhyperref.sty’ fournit une version améliorée de \autoref qui produit en général le résultat attendu. Les options ‘colorlinks, citecolor=blue, linkcolor=blue, hyperindex, backref, breaklinks=true’ améliorent le rendu.

3.9.2.5  Figures, notes de bas de pages, etc.

Ce que l’on appelle un environnement flottant sont les portions (e.g., figure ou table) que L^AT_EX est libre de placer indépendamment du corps du texte.

Vectoriel

Ne faites pas de schémas en format bitmap, les pixels finissent toujours par se voir. Travaillez avec des outils vectoriels (e.g., Dia, Inkscape, OmniGraffle, XFig, ...) et exporter PDF. L’utilisation de ‘share/’ et en particulier ‘share/make/pdf-figs.mk’ aide à mécaniser ces conversions.

Numéroté

Si vous avez besoin de faire plusieurs fois référence à une figure, une définition, un extrait de code, c’est le signe qu’il vaut mieux faire une figure, ou faire appel à un environnement de type definition.

Compteurs

Il est extrêmement désagréable qu’un document manipule plusieurs compteurs: retrouver la définition 1, différente du théorème 1, de la proposition 1, de la notation 1, du corollaire 1 etc. tend au supplice. De même, merci de n’avoir qu’un seul compteur pour les flottants: il ne devrait pas y avoir simultanément une figure 1, un tableau 1 et un algorithme 1. Cf. l’item correspondant dans la section 3.9.2.4.

En ligne vs. flottant

Si la figure fait partie du discours, si le texte ne se comprend pas sans regarder la figure ou lire le code correspondant, alors il est sans doute plus adéquat de la mettre en ligne à l’endroit précis où elle est attendue.

Si la figure est une illustration qu’on peut lire indépendamment du texte, faites-en un flottant. Il est alors plus agréable de les avoir en haut d’une page.

Légende des flottants

On voit souvent des figures incompréhensibles parce que la légende est incluse dans le corps du texte. Parfois même cette légende pollue le texte ! Dans ces cas-là, ne pas hésiter de faire de longues légendes, en rendant ainsi texte et figure relativement indépendants.

Listings

Les gros morceaux de code sont totalement inutiles — ils sont même nuisibles — dans le corps du texte. À une étape donnée de votre discours, seule une petite partie du code est liée au message que vous essayez de faire passer. Mettez donc quelques lignes en exergue, et si nécessaire, renvoyez la version intégrale en annexe.

Parenthèses vs. notes de bas de page

Une note de bas de page et une mise en parenthèse n’ont pas la même fonction: un contenu entre parenthèses se lit dans le flot du texte tandis qu’une note de bas de page se lit après (notez que la position physique d’une note de bas de page est disruptive). En conséquence, une note de bas de page doit pouvoir se lire toute seule. Si elle définit un mot, reprendre celui-ci dans la note.

Finition

Si au cours de la rédaction il est contre-productif de se préoccuper du placement des figures, il faut néanmoins faire un effort pour le lecteur dans la version livrée. Chercher des figures trois pages plus loin est extrêmement désagréable. Le paquet afterpage peut aider: ‘\afterpage{\clearpage}’ produit une page pour vider les flottantes non placées.

Environnements «Théorème»

Utiliser librement les environnements de type théorèmes proposés par L^AT_EX. Dans ce cas, assurer une numérotation unique, voir l’item sur \cref dans section 3.9.2.4. Donner un titre à ces environnements (nom de ce qui est défini, nom du théorème, etc.). Utiliser \dfn dans les définitions pour démarquer le mot défini (en plus de changer la casse, il prépare l’indexation).

Preuves

Correctement baliser les preuves dans un environnement dédié commençant par «Preuve» et finissant par \qed. Une taille de police plus petite avec une marge légèrement supérieure aide à retrouver la structure du document. Envoyer les preuves longues en annexe, sans oublier d’y référencer l’énoncé du corps de texte ici prouvé.

3.9.2.6  Mathématiques

Cohérence

Garder des notations constantes dans tout le document!

Bon goût

Faire preuve de bon goût en écrivant des mathématiques. Le mathématicien prête autant attention à l’indentation que l’informaticien: s’assurer que les énoncés ne sont coupés en fin de ligne.

eqnarray

Les jeux d’équations, de définitions, de relation etc. doivent être alignées sur le symbole de relation. Utiliser les environnements eqnarray et eqnarray*.

Identificateurs

Attention la concaténation de lettres en mode maths désigne un produit: ‘$xy$’ parle du produit de x et de y, pas d’un nom de deux lettres. Utiliser \mathrm et consorts pour les identificateurs longs. Comparer efficiency et efficiency.

3.9.2.7  Style

Première Personne

En règle général, on n’écrit pas à la première personne du singulier. Même si l’on est seul, la première personne du pluriel passe mieux. On peut parfaitement faire des périphrases telles que «dans un article précédent, le premier auteur a…». Dans certains cas, la première personne du singulier est adaptée, pour marquer votre contribution majeure par exemple, mais certainement pas pour écrire «In the first section I show that…».

De la même façon on ne s’adresse pas au lecteur avec des «you».

Pas d’oral

Pas de tournures plutôt orales, genre «pretty good results». D’une façon générale exclure également «we talked about» etc.

Pas de flou artistique

Des mots comme «very» sont dangereux: ils soulignent le flou artistique dans lequel vous drapez votre indécision.

Découpage…

N’ayez pas peur de couper vos écrits. Chapitres, sections, sous-sections et paragraphes sont nécessaires; n’ayez pas peur d’en avoir beaucoup. Si vous finissez avec 3 pages de texte sans découpage apparent, il y a probablement quelque chose qui ne va pas ou qui manque dans votre structuration.

…mais pas trop !

D’un autre côté, attention à la sur-paragraphisation. Si un texte monobloc est illisible, une succession de paragraphes de deux lignes l’est tout autant. On a coutume de dire qu’un paragraphe doit correspondre à une idée (et son développement). Une seule et unique phrase ne peut donc en aucun cas constituer un paragraphe.

Numérotation des sections

Avoir beaucoup de niveaux de découpage ne veut pas dire que vous devez tous les numéroter ! Quatre niveaux de numérotation sont probablement déjà trop. Souvenez-vous que vous avez une commande \paragraph en L^AT_EX.

3.9.2.8  Langage

• Restez concis: écrivez des phrases courtes et utilisez des connecteurs logiques. N’essayez pas d’être trop littéraire, vous êtes en train d’écrire un document scientifique. Une phrase de quatre lignes est trop longue. Vous devez la divisez.
• Pour l’écriture en anglais, le dialecte traditionnel est l’anglais américain. Merci de rester cohérent dans votre document, ne passez pas de l’un à l’autre. Voici quelques spécificités de l’anglais américain:
  • vous devez écrire «honor», et non «honour» ;
  • vous devez écrire «specialization», et non «specialisation» ;
  • ...
• Pour l’écriture en anglais, faites attention aux faux amis et aux expressions idiomatiques. Si vous essayez d’être (trop) littéraire en imitant un joli style français, vous avez fondamentalement tort. Ils ne traduisent jamais comme vous pensez qu’ils le font. Prenons un très bon exemple d’un rapport de 2003 (exercice: devinez lequel): «Among other things, were developed improvements relative to typing». Cette phrase est triplement fausse: premièrement, la virgule est inutile puisqu’il n’y a aucune entité logique à séparer du reste. Deuxièmement, c’est une traduction mot-à-mot du français, mais cela n’est pas correct en anglais: le sujet ne peut être après le verbe qu’en de très rares occasions. Je reconnais que cela rend bien en français, mais cela ne marche tout bonnement pas en anglais. Enfin, le mot «relative» n’est pas un très bon choix (bien que correct). «related» est un meilleur choix en anglais («relative» peut aussi signifier un membre de la famille). section 3.9.3.
• Par pitié, utilisez au moins un vérificateur d’orthographe, et relisez votre document au moins 3 fois avant de le soumettre à d’autres personnes. Vous devez laisser passer un peu de temps entre chaque relecture car nous avons une tendance à ne pas voir des fautes évidentes quand elles sont encore «chaudes». C’est incroyablement difficile et douloureux de devoir lire un document mal écrit, mais lorsqu’il s’agit de fautes d’orthographe évidentes, cela s’avère tout simplement impossible. On ne peut pas se concentrer à la fois sur le sens et le déchiffrage.
• Pendant la phase finale de relecture, ne vous concentrez pas sur le contenu. Il est trop tard pour ça. N’essayez pas de comprendre ce que vous avez écrit. Faites attention à la grammaire et à l’orthographe. La plupart des fautes qui ne sont pas remarquées sont dues au fait que les gens ne réalisent pas qu’il y a plusieurs manières de lire un document.

3.9.3  Erreurs d’anglais communes

Cette section est dédiée à la mémoire de la langue anglaise, si souvent massacrée par les Français. La structure de ce document est loin d’être claire pour le moment, mais son contenu est bien défini: toute faute qui a été repérée plusieurs fois dans nos documents.

Ce document contient des mots mal orthographiés, des phrases mal construites et ainsi de suite. Merci soit de rayer la version incorrecte, soit d’y apposer une étoile (*) (le standard utilisé par les linguistes).

3.9.3.1  Verbes irréguliers

Voir Complete List of English Irregular Verbs by Susan Jones, particulièrement leur liste.

3.9.3.2  Formes spéciales

• The dog, which lives next door, is dangerous ≠ The dog that lives next door is dangerous

  Dans la première phrase, le fait que le chien habite à côté n’est pas nécessaire pour comprendre. Remarquez qu’il n’y a pas de virgule avant «that» dans la seconde phrase.

3.9.3.3  Ponctuation

• N’en abusez pas (guillemets, parenthèses, texte en gras ou italique).
• Pas d’espace devant les ponctuations anglaises («?», «! », «,», «.», «;», «—»).
• Deux espaces derrière le point final de phrase en anglais (c’est plus joli en français, mais ce n’est pas la norme).
• Une espace devant les ponctuations composites en français («? », «! », «;»).

3.9.3.4  Pluriels

• Beaucoup de mots sont indénombrables en anglais, à l’instar de milk, water, etc. (Il s’agit le plus souvent de formes partitives.)
  • advice (a piece of advice)
  • software
  • syntactic sugar («* syntactic sugars»)
  • information («* informations»)
  • data («* datas», en fait data est déjà pluriel, la forme singulière, assez pompeuse, est datum)
• Certaines terminaisons invariables en français ne le sont pas en anglais:
  • one canvas, several canvases
  • one syntax, several syntaxes
• Bien sûr, les adjectifs n’ont pas de forme plurielle:
  • efficient algorithms
  • «* efficients» algorithms
• La même règle s’applique aux noms utilisés en tant qu’adjectifs:
  • type declaration lists
  • «* type declarations lists»
  • «* types declarations lists»
• Porter une attention spéciale aux cas suivants, où être un adjectif fait toute la différence:
  • an 8-bit machine
  • «* an 8 bits machine»
  • a 22-year-old boy
  • «* a 22 years old boy»
  • a boy 22 years of age
  • a boy 22 years old
• Faites attention à ce qui suit, cela diffère du français:
  • they took off their hats (even though they only wear one)
  • «* they took off their hat»

3.9.3.5  Noms propres

Les noms propres ont toujours une majuscule, y compris leur adjectifs correspondants: Boolean, Cartesian, etc.

3.9.3.6  Noms communs

to aim at doing

Préférer «to work toward doing something».

to allow s.o. to do sth

on ne peut pas laisser tomber le «s.o.». «* It does not allow to do something», «It does not allow one to do something».

allow

«to allow someone to do something»

Ne dites pas «* This property allows this and this». Utilisez «offers» ou «enables the programmer to» à la place.

authentication

et non «* authentification» (pas de ‘fi’)

Boolean

et non «* boolean» (section 3.9.3.5).

Cartesian

et non «* cartesian» (section 3.9.3.5) ou «* Carthesian».

contrary to

Préférer «unlike (something)».

a «* critical» problem

préférez crucial, decisive

to depend on

et non pas «* dependant of».

disambiguation

et non «* disambiguization»

everybody

est singulier, au contraire de «people». Tears for Fears chante «Everybody wants to rule the world». «Each, every, either, neither, many a, a person, and compounds of body, one, and thing are singular and take a singular verb.»

finite

se prononce «FAÏ-naïte» (comme «PHI night»), au contraire de «infinite».

infinite

se prononce «INN-fi-nit», au contraire de «FInite».

literature

et non «* litterature» au contraire du français «littérature»

people

est pluriel lorsqu’il se réfère à un ensemble d’individus. Depeche Mode chante «People are people, so why should it be»...

relevant

signifie «having importance, influence.»

semantics

«the semantics of lambda calculus», et non «* the semantic of...».

theoretical

et non «* theoric», «* theoritic» etc.

usual

lui préférer «common» ou «standard».

«* it is not the case»

Utiliser «it is not so» or «It is the case that ...».

in the same way

the same ... AS ...

but similar TO

thanks to

= «due to», «as a result of».

precise

n’est pas un verbe. Utilisez «specify», «point out» à la place.

a large amount

utilisez many ou a great number à la place.

different from

préférez «other that».

implies

est vague, préférez «leads to» ou «results in».

intend

«* this work intends to» est faux. someone (not something) intends to do something. Utilisez «the intent of this work», «the objective of».

«* a need of»

Préférez «a need for» (need for speed) or «need of» without article.

need be

«I can be available 24 hours per day, if need be.» meaning if there is a need that I be available.

indeed

N’en abusez pas. «It is indeed the case.» meaning that it is the case even if you doubt(ed) it, or perhaps even if it surprising.

«* evocate»

Préférez evoke.

inasmuch as

signifie «dans la mesure où».

issue

Ce mot a une connotation politique. Ne l’utilisez pas pour dire «problem».

remind

«to remind someone of something».

in terms of

terms est pluriel.

thereby

in that way

somehow

by some means (not designated)

from a point of view

et non «* from the point of view».

nice

est trop imprécis. «* nice error messages», «informative error messages».

used to + verb

something was true in the past: «I used to eat meat, but I don’t anymore.» = It was true in the past, but is not true now.

used to + noun/gerund

accustomed to: «I’m used to his insults.» or «I’m used to hearing his insults.» = I’ve grown accustomed to hearing his insults. vs «I used to hear his insults.» = In the past I heard them, but I no longer hear them.

anymore vs. any more

«I don’t want any more children» = I have enough children, I don’t want another one. vs «I don’t want children anymore.» = I used to want children, but I changed my mind.

however

«It used to be true; however, it is not longer the case.» (followed by a comma) vs. «I’ll take however many you can give me.» Not followed by comma.

3.9.3.7  Faux amis

• Voir English faux amis for francophones learning English.
• important: on peut dire «an important meeting», mais pas «* an important amount of money».
• eventually = at the end.

1

Tout comme ‘lrde-publis’ (git@gitlab.lrde.epita.fr:lrde/share).

Chapitre 4  La scolarité CSI

4.1  Le recrutement

Le LRDE recrute des étudiants de première année du cycle ingénieur d’EPITA pour le début du 2nd semestre en février. Il arrive parfois que des étudiants de deuxième année soient recrutés. Dans les deux cas, intégrer le LRDE signifie choisir la majeure CSI en ING2, et réciproquement.

Ce recrutement se fait sur dossier et sur entretien, par cooptation.

Une fois le recrutement effectué, les jeunes doivent:

• lire ce document et se souvenir que certaines parties seront à relire (par exemple celles sur la rédaction)
• lire les forums principaux du laboratoire:
  • lrde.general
  • lrde.system
  • lrde.csi
  • lrde.projet.* selon votre projet (vcsn etc.)
• élire un délégué et le faire savoir
• faire en sorte que les CSI n’appartiennent qu’à un seul groupe de promotion (A ou B): il faut maximiser les périodes où tout le laboratoire est disponible
• se décharger de toute activité le mercredi dans la mesure du possible

4.2  La majeure CSI

La majeure CSI a été créée afin que les étudiants du LRDE suivent une majeure en concordance avec leurs activités du laboratoire. Néanmoins, cela ne résout (sic) rien, bien au contraire.

La création de CSI visait aussi à résoudre les interactions problématiques entre les majeures (feu les options de spécialisations) habituelles et le LRDE, mais il reste des interactions problématiques avec le Tronc Commun.

Dans la suite, nous mélangerons librement LRDE et CSI, l’un à la place de l’autre et vice-versa; néanmoins, par rapport à l’EPITA, CSI ne désigne pas les étudiants de première année.

4.2.1  Communication

Des médias officiels existent:

• le newsgroup ‘lrde.csi’
• la liste de diffusion ‘année@lrde.epita.fr’

Bien que vous ne soyez pas obligés de les utiliser, vos professeurs et vos superviseurs utiliseront ces médias quand ils voudront envoyer des informations au groupe.

De plus, quand vous êtes chargés de chercher des renseignements sur l’organisation de votre cursus, les résultats de votre recherche doivent être postés là: cela sert à la fois à informer vos camarades et à être utilisé comme référence pour les étudiants des années suivantes.

4.2.2  Administration

Soyez vigilants et surveillez les notes qui sont données aux autres, et pas à vous. S’il manque des notes, contactez le responsable CSI.

Soyez aussi très vigilants sur les emplois du temps. Si aujourd’hui ils sont assez stables, ils restent susceptibles de modifications tardives.

4.2.2.1  Dispenses, équivalences

Les étudiants du LRDE suivent la majeure dédiée, CSI. Selon l’interlocuteur, un ING1 du LRDE appartient ou n’appartient pas à CSI. De fait, du point de vue du labo il s’agit bien d’une majeure qui démarre dès l’ING1, avec un cursus alternatif, différent, de celui commun aux autres majeures. Une formation par la recherche, qui repose en grande partie sur le travail mené au sein du labo, sur les différents thèmes de recherche et de développement.

Cependant, les cursus aménagés «n’existent» administrativement qu’à partir de la seconde année, par conséquent la première année est un peu bâtarde: vous êtes notés à l’aune de votre travail au LRDE, et ces notes sont reportées dans un bulletin standard de tronc commun. De ce fait s’ensuivent quelques malentendus, et du vocabulaire maladroit.

Il est d’usage de parler de dispense et note d’équivalence, mais c’est impropre. Les étudiants du LRDE ne sont pas «dispensés» d’un projet, Tiger par exemple, parce qu’ils y ont une formation équivalente, mais parce qu’ils ont une formation différente. Les notes «d’équivalence» sur Tiger ne montrent bien sûr aucune équivalence à Tiger. Les étudiants d’ING1 ne sont pas plus «dispensés» de Tiger que les étudiants de SCIA ne seraient dispensés du projet Kernel. De même la note donnée en «équivalence» n’est pas plus une équivalence que la note obtenue en réseau de neurones n’est une équivalence au projet Kernel.

Les problèmes d’échelle de notes (notes d’équivalence trop bonnes ou trop mauvaises par rapport à la moyenne) sont aussi dus à ce fait.

Le vocabulaire est trompeur, derrière les mots «équivalence» et «dispense» se cachent l’unique format de bulletin en ING1. L’administration nous a fait savoir que dans un futur proche, il y aurait possibilité de spécialiser ces bulletins.

4.2.2.2  Projets scolaires

Le LRDE ne peut pas fonctionner sans que vous soyez «dispensés» de la plupart des projets. Il faut que vous consacriez du temps au labo, sinon l’échange ne va que dans un seul sens. Par conséquent merci de respecter vos dispenses en ne faisant pas ces projets.

Pour les projets à faire, faites des groupes avec d’autres membres du LRDE. Ceci simplifie entre autres les problèmes d’emploi du temps, de mutualisation des moyens (réseau LRDE, dépôts Git, etc.).

Un projet comme la Business Week est assez différent. Si vous souhaitez vraiment la suivre, il est préférable de se mêler à des groupes d’autres majeures, qui apporteront des idées différentes.

Ne faites pas seuls des projets prévus pour quatre. Ne faites pas de vos projets scolaires de véritables projets de recherche: tenez-vous au sujet, n’attaquez pas les questions ouvertes !

Attention aux échéances. Les dates de rendus peuvent entrer en collision avec d’autres dates importantes du LRDE. C’est à vous de lisser votre effort.

Il y a des projets que les étudiants CSI n’ont pas à faire, principalement parce que:

1. vous avez fait, ou ferez, quelque chose d’équivalent pendant votre séjour au LRDE.
2. nous considérons que le retour sur investissement n’en vaut pas la peine.

Des exemples typiques sont:

Tiger

Nous savons que vous êtes capables de le faire. De plus, les buts principaux de ce projet sont déjà largement traités au LRDE (projet long, C++, travail en équipe etc.)

Java

Les étudiants CSI sont typiquement des experts C++: apprendre Java viendra lorsqu’ils en auront besoin. Nous leur faisons confiance pour rattraper le niveau habituel des étudiants en peu de temps.

Les exemptions sont habituellement proposées par le responsable CSI en se fondant sur l’opinion des étudiants des promotions précédentes, et de l’expérience passée. Mais la décision doit être faite avec la direction pédagogique de l’école. Dit autrement, ils sont les seuls à accepter ou non nos suggestions sur les exemptions CSI.

Ces projets seront listés sur la page Csi/Curriculum dédiée à votre classe (par exemple, Csi/Curriculum2005). Quand un nouveau projet est annoncé, écrivez ce projet sur la page de votre cursus, puis demandez à votre superviseur de prendre une décision. Tout doit être écrit, y compris des choses comme "Akim a envoyé un message à Y. Goix sur ce sujet", etc.

La mauvaise nouvelle, c’est que vous aurez un 0/20 pour ce projet, puisque nous devons fournir une note de remplacement, mais cela nous est impossible jusqu’à ce que 1. l’école nous prévienne qu’il manque des notes (ce qui se fait via ces fameux 0/20), et 2. le séminaire CSI ait lieu et que les rapports soient écrits.

4.2.2.3  Cours d’anglais

Nous avons demandé des cours d’anglais spécifiques aux étudiants CSI. Le but de ces cours est de vous aider à écrire des meilleurs rapports, faire de plus jolis transparents, et améliorer votre anglais. Le LRDE fournit beaucoup de substance (site Web, rapports, ‘README’s et ainsi de suite), et en conséquence, le but de ces cours est aussi de corriger les fautes réelles.

Steve Frank est votre professeur. Et cette fois, c’est un succès: les étudiants font des progrès significatifs, et le contenu est fixé.

4.2.2.4  Cycle de conférences

En règle générale, il n’y a pas de conférences obligatoires, mais certaines sont fléchées à votre intention. Merci de les suivre.

4.2.3  Vacances

Malgré la charge de travail que l’on vous donne, il vous est suggéré de faire des pauses pendant votre cursus à chaque fois que vous le pensez nécessaire. Prenez-les avant que vous ne vous rendiez compte que la pression continuelle du travail, combinée avec le manque d’organisation de l’EPITA, atteigne sévèrement votre santé mentale et réduise la qualité de votre travail. Prendre de courtes vacances de temps en temps aide à rester calme, à se détacher des projets et à vous vider l’esprit.

4.3  Activités extra-LRDE

Chaque année, lors du recrutement, les permanents tiennent le discours suivant aux candidats:

Venir au LRDE c’est accepter ses règles, parmi lesquelles une certaine forme d’exclusivité. Il n’est pas accepté de cumuler une activité chronophage simultanément, comme par exemple être membre du BDE, être assistant (ACU ou YAKA), être chef d’une grosse association, travailler à mi-temps etc.

Nous avons du respect pour chacune de ces activités, mais d’expérience nous savons que le cumul ne marche pas. Si vous ne souhaitez pas vous interdire ces activités, ne postulez pas au LRDE.

En pratique les choses sont un peu plus flexibles que cela, et nous avons déjà eu quelques anciens ayant participé à l’assistanat des épitéens, des départs en mission humanitaire etc.

Ces exceptions peuvent se discuter avec votre responsable de groupe, qui n’accordera d’exemption que si votre travail a été parfaitement satisfaisant, et que dans le cadre d’un investissement borné dans le temps. En particulier, vous ne serez jamais assistants au même titre que les Yakas ou Acus; il s’agit seulement d’intervenir sur tel ou tel projet, ou pendant la piscine, ou pendant l’atelier, etc.

4.4  Notes CSI

---

Note	Signification
[18–20]	Excellent
[16–18[	Très bon
[14–16[	Bien
[12–14[	Assez bien
[10–12[	Passable
[7–10[	Inachevé
[2–7[	Bâclé
[0–2[	Inacceptable

Figure 4.1: Étalon de notation

---

Toute forme de travail doit être notée. Ce n’est pas seulement un vœu des enseignants, c’est aussi une demande expresse de la part des étudiants qui ont besoin d’avoir une grille de lecture des attentes des encadrants. La figure 4.1 donne notre échelle de notation.

Les permanents font tout leur possible pour que toutes les notes soient données au moins par deux permanents, ce qui malheureusement n’est pas toujours possible étant donné nos emplois du temps.

Les différentes notations qui s’appliquent aux CSI sont:

Encadrement

Tutorat (mentoring) des premières années par les anciens.

Séminaire CSI

Détaillé dans la section 4.4.1.

Rapport

Détaillé dans la section 4.4.2.

Recherche

Originalité de votre travail, résultat de votre recherche, autonomie, persévérance, etc.

Développement

Appliquer le résultat de vos recherches est attendu de tout étudiant CSI. Dans LRDE il y a développement. On évaluera donc votre aptitude à parachever votre travail, ce qui comprend les tests, la documentation, la maintenabilité de votre code (lorsque cela s’applique).

Vie sociale

Votre participation à la vie du labo.

La figure 4.2 donne des échelles de notes pour chacune des catégories ci-dessus.

---

Note	Signification
	Générale	Encadrement	Séminaire CSI	Rapport	Recherche	Développement	Vie sociale
[18–20]	Excellent	Pilier de la formation des nouveaux	Présentation exemplaire, digne d’être filmée et diffusée	Travail publiable / diffusable en l’état	Avancée importante dans la recherche au LRDE ; publication possible	Contributions essentielles au(x) projet(s)	G.O. du LRDE
[16–18[	Très bon	Encadrant(e) de référence pour un projet ou un sujet donné	Oral de qualité, apprécié de l’auditoire	Travail publiable / diffusable après modifications mineures	Avancée significative dans la recherche au LRDE ; publication possible	Contributions régulières et significatives au projet	Présent(e), animateur(trice)
[14–16[	Bien	Fait preuve de disponibilité et d’initiative pour assurer la transmission du savoir	Bonne présentation, retenant l’attention	Bon travail, non publiable / diffusable en l’état, mais constituant une bonne base dans ce but	A contribué à la recherche, s’implique activement et obtient des résultats corrects	Du travail, valable par sa qualité ou sa quantité	Présent(e) régulièrement, fait preuve d’initiative
[12–14[	Assez bien	Répond régulièrement aux questions des jeunes	Prestation orale honnête	Résultat moyen, ne pouvant pas prétendre à une diffusion à l’extérieur à moins de remaniements profonds	Participe aux travaux de recherche mais ne fait pas preuve de beaucoup d’initiative	Du travail correct, lorsqu’il/elle est sollicité(e)	Présent(e) régulièrement, aide ponctuellement lorsqu’il/elle est sollicité(e)
[10–12[	Passable	Distille de l’information de temps en temps	Présentation se contentant du minimum	Travail minimal, ne faisant pas montre d’efforts	Participe au minimum, sans plus	Participe au minimum, sans plus	Présent(e) régulièrement ; discret(e), mais sympathique
Point de «rentabilité»: en deçà, l’étudiant(e) nous fait perdre du temps.
[7–10[	Inachevé	Ne se préoccupe que rarement de ses cadets	Présentation en deçà du minimum, pêchant par le contenu ou par sa forme	Travail en deçà du minimum attendu	Participe très peu aux travaux de recherche ou use d’une mauvaise méthodologie	A fait avancer le projet mais a manqué de rigueur ou de volume de travail	Peu présent(e) ; ne participe que très ponctuellement à la vie du labo
[2–7[	Bâclé	Ne répond pas aux questions	Mauvaise prestation orale	Très incomplet ou comporte trop de fautes de forme	Participe trop peu aux travaux de recherche ou fournit un travail inexploitable	Participe trop peu au développement ou fournit un travail inexploitable	Peu ou pas présent(e), ne participe pas à la vie du labo ou pêche par sa mauvaise humeur
[0–2[	Inacceptable	Sape la formation dispensée par ses pairs	Je-m’en-foutisme affiché ou grossièreté	Rapport vide ou absent	Aucun travail de recherche	Participation au projet inexistante / sape le travail des autres	Instaure une mauvaise ambiance au labo

Figure 4.2: Étalon de notation par catégories

---

4.4.1  Les Séminaires CSI

Il y a trois séminaires dans une scolarité CSI. Leur objet est de nous permettre de juger votre aptitude à faire une présentation scientifique. Ce séminaire doit être vu comme une mini-conf. Le sujet est préférentiellement celui sur lequel vous avez travaillé, mais dans certaines situations discutées avec le chef de groupe, le sujet peut être très différent. Un rapport et des transparents peuvent avoir plusieurs auteurs, mais l’exposé se fait par une seule personne, pas d’exposé en duplex.

La section 3.7 contient beaucoup d’information sur la préparation d’un séminaire.

4.4.2  Les rapports

4.4.2.1  Comment créer un nouveau rapport

1. Dans un premier temps demander l’accès au groupe LRDE sur gitlab puis vous pourrez récupérer le dépôt ‘lrde/techreps’:
   $ git clone --recursive git@gitlab.lrde.epita.fr:lrde/techreps

   Assurez-vous d’avoir bien renseigné vos noms et adresse e-mail dans la configuration Git (à ce sujet, voir par exemple la page
   http://git-scm.com/book/en/Getting-Started-First-Time-Git-Setup).

2. Lancez ensuite le script ‘new-techrep’ en spécifiant le nom de votre rapport (en anglais):
   $ cd techrep $ ./new-techrep "A Survey of Programming Languages Used by Cats"

   Un numéro vous est attribué dans le fichier ‘numbers.txt’ sous la forme ‘YYNN’, où ‘YY’ correspond aux deux derniers chiffres de l’année et ‘NN’ au numéro du rapport dans l’année (par exemple «01» si vous êtes le premier étudiant à appeler le script). Un répertoire portant ce numéro comme nom est créé à la racine du dépôt et rempli avec les fichiers du modèle, que vous pourrez utiliser pour écrire votre rapport. L’ensemble est enregistré dans un commit Git, qu’il vous faut envoyer vers le serveur du LRDE:

   $ git push origin master
3. Il vous faut ensuite mettre à jour le fichier de bibliographie BibTeX des rapports CSI
   (‘bib/csi.bib’ dans le dépôt ‘lrde-publis-share’) avec les informations données par le script.
   $ cd /tmp $ git clone lrde-publis-share $ cd lrde-publis-share $ $EDITOR bib/csi.bib

   Copiez-collez le modèle donné dans la sortie du script dans ‘bib/csi.bib’ (en respectant le tri alphabétique sur les clefs) et complétez cette entrée. N’oubliez pas de fournir un titre et un résumé en français et en anglais. Faites aussi attention aux champs ‘urllrde’ et ‘url’: le premier est une clef de la forme ‘YYYYMM-Seminar-Lastname’ qui est utilisée dans le second pour former une URL vers une page qui référencera votre rapport dans le site Web des publications du LRDE (cf. infra).

   Enregistrez ‘bib/csi.bib’ dans le dépôt et poussez votre commit sur le serveur:

   $ git commit -m "Add KEY to bib/csi.bib." bib/csi.bib $ git pull --rebase $ git push origin master

   où ‘KEY’ est la clef de l’entrée BibTeX (sous la forme ‘lastname.yy.seminar’) que vous venez d’ajouter à ‘bib/csi.bib’.

4. Enfin, créez une page pour votre rapport sur le «Web» Publications du site du LRDE. If suffit pour cela d’aller à l’URL contenue dans le champ ‘url’ de votre entrée BibTeXde ‘bib/csi.bib’ avec un navigateur Web, puis de cliquer sur «Create». Remplissez le formulaire et copiez-collez vos résumés en anglais et en français. Enregistrez vos changements.

   
   

5. Une fois la dernière passe de relecture et de correction de votre rapport effectuée, il vous faudra installer votre séminaire sur le site du labo. Le plus simple est d’exécuter make install depuis le répertoire des sources de votre rapport:
   $ cd techreps $ cd YYNN $ make install

   La règle ‘install’ copie votre rapport dans un répertoire avec une URL du type
   ‘http://www.lrde.epita.fr/dload/YYYYMM-Seminar’. Vous pouvez changer cette destination en modifiant le ‘Makefile’ qui figure dans le répertoire des sources de votre rapport. Modifiez ensuite la page de votre rapport sur le Web Publications du labo (cliquez sur «Edit») afin d’y ajouter l’URL précédente, ainsi que tout autre ressource que vous auriez pu mettre en ligne (par exemple, la présentation que vous avez utilisée pour votre exposé au séminaire LRDE).

4.4.2.2  Rédaction des rapports

Trois rapports sont attendus durant la scolarité CSI. Le troisième est typiquement une complétion et correction du second.

Ce rapport doit être un transfert de compétence vers le lecteur, qui sera typiquement un étudiant plus jeune, un permanent, ou n’importe quelle autre personne susceptible de s’intéresser à votre travail, voire de le poursuivre. Faites donc une présentation en profondeur de tout votre travail. Par ailleurs, ce sera l’occasion de montrer votre aptitude à structurer un raisonnement.

Un rapport qui n’est compréhensible que par l’équipe participant au projet est inacceptable. Veillez à bien introduire toutes les notions que vous utilisez de façon à être auto-contenu. Par exemple si votre sujet porte sur une optimisation de la composition des transducteurs temps-réels de , votre rapport devra nécessairement définir ce qu’est un transducteur temps-réel (ce qui vous conduira à définir ce qu’est un monoïde, un semi-anneau, un produit de monoïdes libres...) ainsi qu’introduire . Pour tous ces préliminaires il vous est vivement conseillé de réutiliser et d’améliorer ce qui a déjà été fait dans des rapports ou articles précédents: citez vos sources et ne réinventez surtout pas la roue. Veillez d’autre part à employer des notations uniformes et à être cohérent dans vos définitions lorsque vos sources sont multiples.

On peut faire un rapport à plusieurs personnes, mais bien sûr dans un tel cas on attend que le travail soit d’autant plus fourni. La même note sera donnée à tous les auteurs.

Vous ne manquerez pas de lire les conseils de rédaction qui vous sont donnés (section 3.9).

Le rapport doit exploiter le style mis au point par User:didier, voyez SeminarPapersHowTo. Il doit être écrit en anglais, et avoir été vérifié par un prof avant d’être mis en ligne. Pour la mise en ligne sur Publications, voyez PublicationsDoc et SubmittingSeminarDocsToTheWiki.

4.4.2.3  Correction des rapports

À partir de 2007, les correcteurs évaluent les rapports sur le fond et vérifient que la forme respecte les critères attendus (cf. infra).

Parmi les éléments qui composent le fond, on entend notamment les points suivants.

La mise en contexte

Re-situez votre apport vis-à-vis du travail accompli par vos prédécesseurs au LRDE ainsi que la communauté scientifique. Par ailleurs, votre rapport doit pouvoir être lu par une personne n’ayant pas encadré votre travail, par exemple un élève de première année intégrant le labo l’année suivante.

Le caractère pérenne du rapport

Ayez en tête le fait que votre rapport s’inscrit dans un travail collectif, et dans le temps. Veillez à son caractère «réutilisable».

La pertinence vis-à-vis du LRDE

Le travail réalisé au LRDE doit chercher à s’inscrire dans les thèmes de travail du laboratoire, et dans la continuité des travaux existants. Sauf accord explicite de votre encadrant, votre rapport doit se rattacher aux projets du LRDE.

Complétude

Est-ce que tout a été dit ? La différence entre le travail qui est vôtre et ce qui est de l’ordre de l’état de l’art est-elle assez marquée ?

Cet aspect de «fond» est noté sur 20 points, en suivant la figure 4.1. Cette première note est modifiée par une note de forme. Des points négatifs sont appliqués, qui sanctionnent les manquements aux exigences de forme. Il existe aussi des gratifications liées à la forme, quand celle-ci a été particulièrement soignée.

Points de forme négatifs

Les éléments suivants doivent figurer dans votre rapport. Absents ou mal traités, ils donneront lieu à des pénalités sur la note du rapport.

Introduction

Elle ne doit pas se réduire à une simple présentation du plan de votre rapport.

État de l’art

Citez les travaux similaires accomplis par vos prédécesseurs et les membres de la communauté scientifique, et situez-vous par rapport à eux.

Si votre état de l’art se limite à une paire de paragraphes, n’en faites pas un chapitre à lui tout seul: fusionnez-le avec l’introduction, par exemple.

Conclusion

Là encore, évitez les conclusions trop courtes ! Ne vous contentez pas de recopier votre résumé dans la conclusion.

Bibliographie

C’est un point important dans toute publication scientifique. Une entrée dans une bibliographie doit être précise et donner assez d’informations à quelqu’un qui voudrait retrouver l’article dans une bibliothèque sans moteur de recherche. Soignez vos entrées et relisez-les au même titre que le reste du rapport. Utilisez autant que possible ‘share/bib’, tant pour y puiser des références que pour y ajouter de nouvelles entrées.

Bon usage des citations

Les modèles standard de rapports de séminaire CSI offrent plusieurs variantes de la commande \cite permettant d’insérer proprement une références dans le discours. Documentez-vous notamment sur les commandes \citet et \citep.

Index

Un rapport est d’autant plus réutilisable que l’on accède facilement à l’information. La constitution d’un index étant particulièrement fastidieuse à réaliser a posteriori, il est recommandé de le constituer au fil de l’écriture du rapport.

Usage parcimonieux des notes de bas de page

Les notes cassent le rythme de la lecture. Dans la mesure du possible, reformulez votre prose pour en réduire le nombre. Les notes de bas de page doivent être des phrases complètes.

Figures (illustrations et tableaux)

Veillez à leur pertinence, leur lisibilité (éviter le format timbre postal !), leur titre, leur numérotation et leur(s) références.

Références

Les références (citations et renvois aux éléments flottants) doivent être des liens hypertexte.

Robustesse à l’impression en noir et blanc

Votre rapport doit être composé en couleurs, mais doit supporter une impression bichromatique tout en restant lisible.

Listings «digestes» et pertinents

Dix pages de code non commentées en annexe n’apportent rien ! Utilisez le paquet mylistings de ‘share’ pour la mise en page d’extraits de code. Lorsque c’est possible, reformulez votre algorithme sous une forme générale plutôt que dans un langage donné (il existe plusieurs styles L^AT_EX pour mettre en page un algorithme, comme newalg).

Correction de la langue

Pas de fautes. Un rapport ne doit jamais être soumis à un permanent sans avoir été relu par un de vos pairs. Soyez sûrs d’être très pénalisés s’il est manifeste que le correcteur orthographique n’a pas été utilisé.

Typographie

Faites attention aux polices utilisées, à la ponctuation, aux césures, etc.

Mise en page

Faites attention aux marges, aux interlignes, à la table des matières, etc.

Qualité de rédaction

Pas d’oral à l’écrit. Articulez votre discours, usez et abusez des prépositions (section 3.9.2.7).

Et enfin, le respect de tout autre point du Guide

Points de forme positifs

Les éléments suivants peuvent donner lieu à des bonus sur la note de forme.

Bibliographie commentée

Bien entendu, le fait d’annoter une bibliographie ne dispense pas de ce qui a été mentionné plus haut !

Figure soignées

Les belles figures qui ont exigé un soin particulier et/ou qui illustrent particulièrement bien un propos seront sujet à bonification.

Glossaire

Un glossaire n’est pas indispensable, mais sa présence pourra être considérée comme un bonus.

4.4.2.4  Étapes de rendu d’un rapport

Chacune des étapes suivantes est obligatoire, et il est du devoir des étudiants CSI de s’assurer qu’ils sont en conformité avec les points suivants. Des pénalités sont appliquées tant que votre rendu n’est pas conforme (1 point sur la note finale par jour de retard).

Choix du sujet

avec votre encadrant.

Correction par un pair

les permanents ne sont pas là pour corriger les erreurs grossières, tous les rapports doivent avoir été relus par un pair avant d’être rendus. Remercier explicitement dans la section idoine (e.g., un ‘\paragraph{Acknowledgements}’ à la fin de votre introduction) le (les) étudiant(s) ayant relu votre rapport.

Enregistrement

Compléter/corriger le fichier ‘bib/csi.bib’ (dans git@gitlab.lrde.epita.fr:lrde/share) avec votre rapport ainsi que le champ urllrde qui pointe sur la page wiki. Par exemple:

@TechReport{sigoure.06.seminar, author = {Beno\^it Sigoure}, title = {{eXtended Reactive Modules}}, titre = { ... Titre en fran\,cais ... }, institution = {EPITA Research and Development Laboratory (LRDE)}, year = 2006, abstract = { ... English abstract ... }, resume = { ... R\'esum\'e en fran\,cais ... }, url = {http://publis.lrde.epita.fr/200607-Seminar-Sigoure}, urllrde = {200607-Seminar-Sigoure}, }

Rendu

à Daniela (i) d’une impression de votre rapport, (ii) d’une impression de la page wiki "student report" pour montrer que cela a été fait. Sur la page de garde de votre rapport, reporter (i) la clé de citation BibTeX utilisée dans ‘csi.bib’.

Par la suite,

Correction par les permanents

Le premier correcteur donne à l’étudiant des modifications à effectuer avant de passer le rapport corrigé au relecteur suivant. Si le calendrier ne se prête pas à la souplesse, le deuxième relecteur peut travailler sur la première version du rapport.

Publication

Créer une page pour rapport d’étudiant sur le Wiki. Pour cela, allez sur l’URL: ‘http://www.lrde.epita.fr/Publications/AAAAMM-Seminar-Nom’ où:

• AAAA est l’année du séminaire
• MM est le numéro du mois du séminaire
• Nom est votre nom avec une majuscule

Un exemple d’URL: http://www.lrde.epita.fr/Publications/200607-Seminar-Sigoure

Une fois dessus, cliquez sur le lien "create" en bas à gauche de la page. Vous devez maintenant remplir les différentes sections, recopiez les lignes ci-dessous et complétez avec votre abstract et résumé

%PUBLIHEADER% _English:_ Put your abstract here. _French:_ Votre r\'esum\'e i\ci.

Impression définitive

Faire une copie recto verso format A4 pour les classeurs de rapports des projets. L’y insérer.

Upload sur l’intranet

Une fois le séminaire passé, ajoutez vos documents en version finale corrigée dans le wiki. Pour cela il vous faut les mettre dans le dossier dload, sur une machine du lrde:

$ cd /lrde/dload

Si le dossier de votre séminaire n’existe pas encore, créez le:

$ pwd /lrde/dload $ mkdir AAAAMMJJ-Seminar $ chmod 775 AAAAMMJJ-Seminar

Avec:

• AAAA: l’année du séminaire
• MM: le numéro du mois du séminaire
• JJ: le numéro du jour du séminaire

Important: N’oubliez pas de mettre les bons droits sur le dossier sinon les autres CSI ne pourront pas rajouter leurs fichiers!

Une fois vos fichiers ajoutés, éditez la page wiki de votre rapport et rajoutez les lignes suivantes à la fin:

* [[%LRDEDOWNLOAD%AAAAMMJJ-Seminar/MYREPORT_FILENAME.pdf][report.pdf]] * [[%LRDEDOWNLOAD%AAAAMMJJ-Seminar/MYSLIDE_FILENAME.pdf][slides.pdf]]

Vérifiez que tout marche bien.

4.4.3  Développement

N’hésitez pas à vous impliquer entièrement dans votre projet préféré. Cependant, n’essayez pas d’entamer des projets dont la charge de travail dépasse votre capacité. Préférez un développement par petits pas incrémentaux, en documentant votre feuille de route de sorte à ce que les gens puissent suivre, et rejoindre le projet facilement lorsque vous avez besoin d’aide. Évitez de travailler «dans votre coin», d’annoncer vos résultats à la fin (particulièrement s’ils sont négatifs) et de conclure que vous avez manqué de temps pour finir.

4.5  Après

4.5.1  Lettres de recommandation

Pour postuler pour un Master (autrefois un dea), vous aurez sans doute besoin d’une lettre de recommandation. Les pages suivantes sont de bons guides pour les auteurs de ces lettres:

• Tips for Writing a Letter of Reference
• Sample Faculty Reference Letter

En ce qui concerne les étudiants, quelques recommandations:

Faire corriger votre bulletin

Si vous avez des notes extrêmes (trop basses, ou bien trop élevées: avoir plus de 20 est suspect pour l’extérieur), demandez leur correction à Hélène Vaury (vaury_h@epita.fr)

Ne demander qu’une seule lettre de recommandation au LRDE

Plusieurs lettres provenant du même endroit ne sont pas la meilleure approche. Demandez-en une ici, et d’autres d’ailleurs, préférentiellement hors EPITA.

Choisissez votre recommandataire

Ne demandez pas des lettres de quelqu’un qui ne vous connaît pas bien (avez-vous travaillé ensemble ?), ou qui ne vous a pas vu sous votre meilleur jour (avez-vous échoué ses examens ? Pour commencer, les avez-vous réussis ?)

Donner un dossier complet à votre recommandataire

La personne qui vous soutiendra ne devrait pas perdre de temps à chercher l’information que vous devriez lui avoir fourni. En particulier, fournissez:

• Le nom du Master
• La majeure que vous choisissez
• Le lieu du Master (nom de l’université etc.)
• L’URL du Master
• Toute information susceptible de nous aider (est-ce que des enseignants EPITA participent à ce Master ? etc.)
• Votre CV
• Vos atouts à faire valoir

Merci de consulter et de tenir cette page à jour: Csi/Dea.

Fournir un squelette de lettre de recommandation

Un bon moyen d’aider (et donc d’avoir une bonne recommandation…) consiste en l’écriture d’une esquisse par vous-même. Suivez ces trois étapes:

• Comment vous connaît-on ? Depuis combien de temps ?
• Un résumé de ce que vous avez fait avant et pendant notre période commune.
• Pourquoi on devrait être contents de vous et avoir envie de faire une bonne lettre de recommandation.

Ne lisez pas les lettres des autres

Certains d’entre nous donnent parfois des lettres ouvertes. Ne vous amusez pas à les faire circuler, à les comparer etc.

Classement à l’EPITA

Beaucoup de formulaires demandent comment vous vous classez dans votre promotion, explicitement ou implicitement («dans les premiers 1%, 5% etc.»). C’est une information difficile d’accès à l’EPITA: la direction pédagogique n’y semble pas favorable, mais si c’est nécessaire, en luttant, ce doit être possible.

Les problèmes pouvant se poser : les majeures ne notent pas de la même façon, toutes les notes ne sont pas encore rendues, certaines notes EPITA sont bien connues pour ne pas vraiment avoir de sens pour les gens de l’extérieur (e.g., Bistro ou piscine), les demandeurs ne veulent pas toujours la même chose, etc. Il faut que vous, étudiants, preniez l’initiative en préparant le document que vous souhaitez obtenir. Après vérification de sincérité, Hélène Vaury ou Christian Dujardin le validera ou éventuellement le corrigera, le tirera sur papier à entête EPITA, le signera, et vous le remettra. Il faut que ce document soit compatible avec les outils que vous devinez (feuille de calcul ou traitement de texte).

Chapitre 5  Maintenance des Projets

5.1  Maintenance des avis du droit de copie

Vous pensez peut-être que nous ne nous soucions pas vraiment de ces avis, mais en fait, nous nous en soucierons quand nous aurons de gros problèmes. Ainsi, comprenez bien que nous ne pouvons pas jouer avec le feu sur ce point, même si cela semble autant bénin, ou même simplement douloureux.

Voici les règles à suivre absolument:

• Utilisez ‘Copyright (C) Year1, Year2, Year3 LRDE’ dans chaque fichier long d’au moins 15 lignes environ. Incluez la licence ci-dessous. Cela comprend ‘ChangeLog’, ‘README’ et ainsi de suite.
• À chaque fois que vous modifiez un fichier, mettez à jour les dates du droit de copie.
• Pour le faire automatiquement avec Emacs:
  • Ajoutez ‘(add-hook ’write-file-hooks ’copyright-update)’ dans votre fichier d’initialisation d’Emacs,
  • Lancez M-x customize-group Copyright dans Emacs, et réglez le valeur de ‘Copyright Query’ à ‘don’t ask’.

• N’utilisez pas d’intervalles tels que ‘Copyright (C) 2001-2003’.
• N’oubliez pas le ‘(C)’, même si la FSF ne l’impose pas ci-dessous.
• N’ajoutez pas des années pour rien, uniquement celles où le fichier a été modifié.

Les raisons et des détails supplémentaires sont disponibles dans un document similaire écrit par la FSF pour ses mainteneurs. La section en question est Copyright Notices. Il ne s’applique à nous que partiellement, mais il est inclus en l’état ci-dessous. On vous fait confiance pour voir où des ajustements sont nécessaires.

5.2  Le fichier ‘ChangeLog’

Ce chapitre résume les choses les plus importantes sur les entrées de ChangeLog. La source principale d’informations reste la page GNU Coding Standards: Change Logs.

5.2.1  Quoi et comment

Dans le concept originel des ChangeLogs, on décrit tout changement que l’on a fait. Cela rend la chasse aux bogues plus facile, et cela aidera d’autres gens à suivre le développement.

Voici quelques exemples d’entrées de ‘ChangeLog’:

5.2.2  ChangeLog: Le bien

• Lisez ce que les autres ont fait, et imitez les.
• Une entrée de ChangeLog par checkin. Puisqu’il n’y a qu’un checkin par but, cela fait une seule entrée pour chaque but.
• Commencez votre entrée de ChangeLog par la raison de votre correctif; le noyau du ChangeLog est dédié à lister quels changements vous avez effectués, et comment.

  S’il y a un bug, décrivez le; si cela ajoute une fonctionnalité, décrivez la; s’il y a des références, fournissez les; etc. Quelques exemples avec une telle introduction:

  2004-05-29 Paul Eggert <eggert@cs.ucla.edu> Fix some "make check" problems with C++ reported by Albert Chin-A-Young for Tru64 C++ in this thread: http://lists.gnu.org/archive/html/bug-bison/2004-05/msg00049.html * m4/cxx.m4 (BISON_TEST_FOR_WORKING_CXX_COMPILER): Check for std::cerr. * tests/actions.at (_AT_CHECK_PRINTER_AND_DESTRUCTOR): Output to a .cc file for C++, not to a .c file. * tests/calc.at (AT_CHECK_CALC): Likewise. * tests/regression.at (AT_CHECK_DANCER): Likewise. * tests/local.at (AT_COMPILE_CXX): Default to OUTPUT.cc, not OUTPUT.c. 2004-05-27 Paul Eggert <eggert@cs.ucla.edu> Spent a few hours checking out which prerequisite versions the current sources actually require. I went all the way back to Gettext 0.10.40, Automake 1.4, and Autoconf 2.57 and investigated a seemingly endless set of combinations of versions more recent than that. The bottom line is that the current sources require fairly recent versions of the build tools, and it'll be some work to change this. * configure.ac (AC_PREREQ): Increase from 2.58 to 2.59. (AM_INIT_AUTOMAKE): Increase from 1.7 to 1.8. (AM_GNU_GETTEXT_VERSION): Increase from 0.11.5 to 0.12. Add comments explaining why those particular versions are currently needed.
• Après les deux points (‘:’), écrivez une phrase impérative. L’entrée de ‘ChangeLog’ décrit ce que votre correctif fait (et non ce que vous avez fait). Une autre métaphore est de penser que vous donnez des ordres à quelqu’un qui va implémenter les changements que vous décrivez.
• Une phrase commence avec une majuscule et finit avec un point.
• Coupez les longues listes de fichiers comme suit:
  * parse/task-parse.hh, ast/task-ast.hh, escapes/task-escapes.hh, * parse/task-parse.cc, ast/task-ast.cc, escapes/task-escapes.cc: Rename as... * parse/parse-tasks.hh, ast/ast-tasks.hh, escapes/escapes-tasks.hh, * parse/parse-tasks.cc, ast/ast-tasks.cc, escapes/escapes-tasks.cc: These.
• Les entrées de ChangeLog ne sont fondamentalement à écrire qu’une fois, particulièrement celles loin dans le passé. Néanmoins, corrigez les erreurs dans les entrées récentes. Si des détails sont demandés sur un correctif, c’est probablement un signe que l’entrée du ChangeLog est incomplète: complétez la ! Ne remplissez pas une entrée de ChangeLog pour un correctif d’une entrée de ChangeLog.
• Lorsque vous fusionnez une branche, ajoutez une tabulation aux en-têtes du ChangeLog ajouté, et collez tous ça dans le nouveau ChangeLog. Voici un exemple:
  2003-10-01 Raphael Poss <raph@lrde.epita.fr> Merge the following changes. 2003-10-01 Raphael Poss <raph@lrde.epita.fr> * src/translate/translation.cc: Fix bug where reference to temporaries were stored in the heap. 2003-09-30 Raphael Poss <raph@lrde.epita.fr> * Synchronize with main project. [...] * src/misc/Makefile.am: Mention the new files.

5.2.3  ChangeLog: Le mal

• N’utilisez pas plus de 80 colonnes (sauf si, bien sûr, un nom est trop long).
• N’abrégez pas les noms de fichier, les noms de fonction, les noms de variable, ou quoi que ce soit susceptible d’être «grepé» plus tard dans le ‘ChangeLog’.
• N’oubliez pas de rapporter tous les changements. Cela prend du temps, je vous l’accorde, mais c’est un investissement pour les futurs mainteneurs.
• Expliquer dans le ‘ChangeLog’ pourquoi le changement est nécessaire peut être utile, cependant l’explication est habituellement mieux placée en commentaire dans le code.
• Le ‘ChangeLog’ concerne le paquet, pas le dépôt. Ainsi, n’écrivez pas de choses telles que «Remove from the repository», ou «Add missing file» puisque ça n’a aucun sens du «point de vue de la tarball». Mais bien sûr, «New file» est une autre affaire.
• Ne dites pas «Add» pour des nouveaux fichiers, dites «New». «Add» se réfère typiquement au dépôt, mais le dépôt n’est pas le but du ‘ChangeLog’, qui vise le paquet seulement. Bien sûr, vous pouvez utilisez «Add» dans le journal du système de contrôle de versions.

5.2.4  Emacs et ChangeLog

• Sous Emacs (ou XEmacs), tapez ‘C-x 4 a’ dans le fichier où vous avez fait des changements. Cela vous emmènera au fichier ‘ChangeLog’ le plus proche, et apposera un squelette d’entrée que vous pourrez compléter.
• L’adresse qu’Emacs utilise pour le ‘ChangeLog’ se configure comme suit:
  (setq add-log-mailing-address "duret_g@epita.fr")
  ou tapez M-x customize-variable RET; add-log-mailing-address RET.

5.3  Enregistrement d’une révision

Enregistrer une modification n’est jamais une opération bénigne puisque cela concerne tous les utilisateurs de l’application, maintenant et même dans le futur.

5.3.1  Pourquoi utiliser un système de contrôle de versions

Les motivations pour utiliser un système de contrôle de versions sont:

Synchroniser les Utilisateurs

Quelqu’un qui récupère le projet doit être en mesure de travailler, le projet doit donc se comporter correctement.

Revenir en Arrière pour Isoler les Bogues

Parfois, un nouveau bogue se montre, et l’on remonte dans l’historique jusqu’à ce qu’on trouve la modification qui a introduit le bogue. Mais bien sûr ce n’est pas possible s’il y a des versions qui ne compilent pas ou qui ont d’autres bogues.

5.3.2  Définir un enregistrement de révision

Gardez cela en tête:

En particulier:

• lorsque vous enlevez un fichier du dépôt (par exemple, ‘install-sh’ etc.), enregistrez une révision dédiée, de sorte à ce que
  • le «diff» soit facile à lire
  • les gens qui reviennent en arrière sur cette révision précise ne voient pas ‘install-sh’ apparaître soudainement.

5.3.3  La procédure d’enregistrement

1. Vérifiez vos changements

À moins que vous soyez sûrs que vos modifications ne puissent pas être dangereuses, qu’elles ne changent rien de significatif, vous devez lancer la suite de tests.

2. Mettez à jour votre copie locale

Pour avoir les derniers changements:

$ svn update

3. Ajoutez les nouveaux fichiers et supprimez les obsolètes

Afficher la liste des fichiers que svn veut ajouter/supprimer:

$ svn status

Des fichiers générés ou inutiles peuvent être listés. Ajoutez les à la liste des fichiers ignorés du répertoire:

$ svn propedit svn:ignore .

Dans ce fichier, vous pouvez mettre des fichiers à ignorer via des «globbing patterns». Un «globbing» par ligne:

*.o *~

Quand ‘status’ affiche une liste propre des nouveaux fichiers, lancez:

$ svn add files_or_directories_to_add $ svn remove files_or_directories_to_remove

pour réellement ajouter/supprimez les nouveaux/anciens fichiers.

4. Écrivez un ChangeLog

Affichez le contenu de vos modifications :

‘$ svn diff’ pour voir tous les changements.

Mettez à jour les fichiers ChangeLogs en conséquence avec tous les fichiers modifiés. Utilisez ‘C-x 4 a’ sous Emacs pour écrire votre ChangeLog en même temps que les modifications, et lisez les ChangeLogs pour avoir plus d’informations sur comment les mettre à jour.

Pour avoir la liste des fichiers modifiés, lancez ‘$ svn status’. Relancez ‘$ svn diff’ pour afficher vos changements, y compris la nouvelle entrée du ChangeLog.

5. Enregistrez vos changements

Souvenez-vous: une révision, un sujet (Lisez la documentation de svn pour apprendre comment enregistrer uniquement des parties de vos modifications). Puis lancez ‘$ svn commit’, et collez l’entrée du ChangeLog (ou les entrées s’il y a plusieurs ChangeLogs). Supprimez la première ligne du ChangeLog (Nom et Date, car svn connaît déjà ces informations).

6. Postez vos Changements

Choisissez un sujet intelligent. Il commence par le nom du projet, puis le numéro de révision. Si vous postez dans un group dédié à un projet, disons Olena, il n’est pas nécessaire de spécifier le nom une fois de plus, le numéro de révision est suffisant. Ensuite, incluez un court titre définissant l’enregistrement de révision. Puisque vous venez de faire l’enregistrement, vous connaissez aussi le numéro de révision.

De mauvais exemples de ‘Subject:’ sont:

• ‘vampire 123: Some changes’
• ‘vampire 123: Update’

De bons exemples de ‘Subject:’ sont:

• ‘vampire 123: parser fixed’ in ‘projects at lrde.epita.fr’.
• ‘590: Use TimeVar’ in ‘tiger-patches at lrde.epita.fr’.
• ‘7.22: Upgrade to Autoconf 2.57’ in ‘olena-patches at lrde.epita.fr’
• ‘meta-c++-grammar 99: upgrade to StrategoXT 0.9’ in ‘transformers-patches at lrde.epita.fr’.

Incluez l’URL (‘svn info | grep ’URL:’’), diffstat (‘svn diff | diffstat’), et diffs (‘svn diff --diff-cmd diff --extensions ’NPbuw’ ’) dans le corps, et envoyez le au newsgroup ou à la liste de diffusion approprié.

7. Répondez aux commentaires

Si des changements sont demandés, implémentez les, et postez les en réponse au commentaire. Si le ChangeLog doit être corrigé, faites-en un seul enregistrement de révision (pas d’autre modification).

5.4  Inspection de Correctifs

Une fois que le message de nouvelle révision a été posté (section 5.3), il doit être inspecté: chaque correctif devrait être inspecté.

Le but de l’inspection est bien sûr de chercher des erreurs, des fautes de frappes, une documentation ou un ChangeLog flous, un style de code incorrect, ou même une suggestion de meilleure implémentation, et ainsi de suite.

S’il n’y a rien à signaler sur le correctif, répondez juste «Ok», en citant uniquement le ChangeLog. Généralement, le fil s’arrête là.

S’il y a des problèmes à signaler, ne citez que les portions pertinentes du correctif. Si vous avez plusieurs gros problèmes à rapporter, vous pouvez peut-être faire plusieurs réponses séparées pour diviser le fil. L’auteur du correctif doit répondre à ces commentaires, et si des enregistrements de révision s’adressent à certains de ces problèmes, la réponse doit y faire référence (par exemple en donnant le numéro de révision).

Tout le monde est invité à commenter un correctif, néanmoins, cette responsabilité incombe typiquement au mainteneur du projet, ou au pair de l’auteur du correctif chargé d’inspecter le code.

5.5  Release de logiciel

5.5.1  Préparer le release

Comment faire une release de votre projet.

• Soyez sûrs que le projet est gelé: Demandez au directeur du projet (si ce n’est pas vous), regardez l’agenda du projet et les nouvelles.
• Récupérez la dernière archive de développement (Git).
• Traquez les «FIXME».
• Résolvez tous les tickets correspondants à ce release.
• Mettez à jour le fichier NEWS avec la nouvelle version et les changements majeurs. N’hésitez pas à montrer des morceaux de code (e.g., des «avants/après» pour les changements d’interface).
• Mettez à jour tous les numéros de version (documentation, ‘configure.ac’ …).
• Récupérez les archives finales et soyez sûrs que tout marche bien: ‘make distcheck’ (produit des archives ‘tar.gz’ et ‘tar.bz2’).
• Publiez ces archives, mettez à jour les liens de téléchargement sur votre site Web.
• Faites des annonces publiques (newsgroup…).
• Créez la nouvelle version majeure de développement.

5.5.2  Page de release

Faire une page Wiki pour la diffusion du logiciel. Suivre le schéma suivant, librement inspiré des pages de releases du groupe Stratego/XT:

Download

Une section avec des pointeurs vers les différents paquets, tarballs etc.

Documentation

Des liens vers toutes les formes de documentation disponibles (PDF, HTML, utilisateur, programmeur, Doxygen, Wiki etc.).

License

Celle qui s’applique.

Changes

La liste détaillées des changements. Dans l’idéal, il s’agit de ’fileNEWS. En pratique ce fichier est rarement assez complet et détaillé. C’est peut-être le moment de le faire.

Issues

Les problèmes connus avec ce release. Des informations sur comment envoyer des rapports de bogue.

Thanks

Remerciements des différents contributeurs de ce release.

Quelques exemples de pages suivant plus ou moins bien ce schéma:

• Stratego 0.16
• Vaucanson 0.7.2

Index

Ce document a été traduit de L^AT_EX par H^EV^EA