# Retours des participants sur la formation test

## Amont de la formation

- Faire une fiche d'initialisation (cf. infra)
- s'il y a des participants des SSM, se renseigner sur leur environnement de travail (présence de RStudio, forge git interne)

## Les liens importants

Supports: https://linogaliana.gitlab.io/collaboratif/

## Intro de la formation

beaucoup de comptes différents à créer - datalab, gitlab, tchap, hackmd, peut on rationnaliser ? en tt cas laisser le temps aux gens d'ouvrir tous les comptes.

prévoir une demi-heure avant la formation pour vérifier les comptes, possibilités de connexion de chacun ?

Juste une suggestion pour la formation : faire une fiche d'initialisation pour que chacun puisse faire les étapes jusqu'à Rstudio avant la formation, ça permettrait de déminer les éventuels problèmes en amont.

### Connexion au Datalab

Faire un tutoriel détaillé sur comment se connecter au datalab:
- création de compte, notamment les règles sur le username (tout en minuscules, pas d'espace, pas de caractères accentués, pas de signes de ponctuation);
- comment lancer une instance Rstudio dans le ssplab.

Pour la connexion, ne pas hésiter à faire des copies d'écran successives avec une GROSSE Flèche pointant vers la clé bleue et laisser le username (rstudio) inscrit quelque part (essayer le tableau numérique de zoom pour laisser de l'info ?)

La mise en place nécessite des pauses, afin de permettre la réalisation des consignes.

### Création projet dans RStudio
* File/new project/Version Control/Git (bien dire que c'est la troisième possibilité)
* Coller l'url du projet
* Insister nettement moins sur les raccourcis clavier, fournir plutôt une fiche synthétique dans les supports.

### Gitlab
* ça ne sert à rien de parler du Gitlab innovation : il faut l'oublier. La forge interne des statisticiens de l'Insee c'est https://gitlab.insee.fr
* ne pas oublier qu'il y a des agents de SSM : il faudrait vérifier en amont de la formation si le SSM dispose d'une forge interne, si oui, laquelle ?
* Point sur les forges --> encadrants
* ne plus évoquer SVN (deprecated) : ça ne peut que perturber les stagiaires avec un truc qui n'est pas de la préhistoire mais du moyen-âge

* au moment du clone, je ne suis pas certain que ce soit utile de montrer qu'on peut changer de nom pour le répertoire. Ca peut induire de la confusion.

p
## Eléments spécifiques formation distanciel

Ne pas parler, montrer et demander de faire en même temps - il y a de l'information qu'il faudrait garder plus longtemps à l'écran (clé bleue, username... -> tableau numérique de zoom ?) Faire les manip plus lentement.

Peut - être faire une présentation plutôt que de faire défiler un texte ? Cela permet de rester plus de temps sur les points importants !
Oui c'est vrai que faire une présentation permettrait peut-être de mieux souligner les points importants tout en renvoyant au site utilitR ou la fiche qu'on parcours collaboratif, qui est top, une fois la formation terminée

Annoter le support. Dédier une personne au chat.

lorsque qu'il y une suite d'opérations - comme créer un projet : faire un schéma visuel des étapes à réaliser ? et le laisser apparent ? et refaire plusieurs fois la suite des étapes.

Hors présentiel, c'est plus compliqué de suivre en même temps qu'on fait les manip. Je me demande s'il vaut pas mieux: soit faire une partie théorique (sous format diapo) où on nous explique les grands principes puis ensuite faire des fiches d'exos soit faire des capsules vidéos car dans ce cas on peut faire des pauses ou revenir en arrière

ou alors faire une démo de manip à l'écran, puis afficher un schema des étapes à suivre et laisser le temps aux participant de réaliser la suite des manip

Faire une manip en même temps, sans double écran ...

*Pour les branches : donner d'autres exemples concrets de leur utilité peut être, pour que ce soit parlant pour tous*

Redonner la parole aux participants toutes les heures ?

Branch

## Elements specifiques à la formation orientée "managers"/ prosélytisme

On pourrait commencer par un schema (j'adore les schemas ;-) sur l'ensemble des services/infra ou ils se trouvent qui seront mobilisés et les liens entre eux

![Uploading file..._68v5ucux5]()

## Partie 4

Trois remarques générales:
- Apparemment, la Diit a des ateliers d'incubation dont le contenu est proche de la formation R collaboratif. Il y a peut-être une coordination à trouver. Romain, qu'en penses-tu?
- la présentation de Git est très liée à l'utilisation de Rstudio. Séparer mieux la partie git?
- Les ateliers de la Diit sont très bien sur git, on pourrait s'en inspirer pour améliorer la partie git.

### 4.1

2ème paragraphe: ... ou ont demandé à leurs collègues.
Une petite suggestion : quand vous parlez de Pycharm ou d'Atom, brièvement, rajouter VSCode, car c'est quand même très très utilisé (et dispo sur la plateforme).

### 4.2
Les schemas dans cette partie passent tres bien en zoom, cela permet de synthétiser l'info en restant sur la meme image.

Ajouter une mention sur les branches protégées pour bloquer les git push --force

### 4.3

Plusieurs plateformes pour accueillir les repo. Multiples questions:
- gitlab, GitHub, gitlab interne plateforme innovation.
- Quel répo choisir ? Payant non payant ?
- Quelles bonnes pratiques ?
- Est ce qu'il y a un repo partagé pour le SSP ?
- comment faire quand on change de poste et d'adresse mail ?

1/ gitlab interne Insee : https://gitlab.insee.fr
pas de possibilité de partage avec des SSM

2/ gitlab.com github.com - open source

https://github.com/InseeFr
https://gitlab.com/InseeFr

s'il y a toute l'organisation des répertoires /droits à gérer au niveau du "management" - il y aura certainement besoin d'accompagnement pour homogénéiser l'organisation des projets dépendants du bureau/de la division et de règles de bonnes pratiques.

Ajouter le type de droits qu'il faut activer sous gitlab - maintainer pour pusher sur master

Mettre quelque chose sur pas cliquer sur pull with rebase

Mettre quelque chose sur les recherches dans les commits.

## Retours des stagiaires

Public visé de la formation: managers et chargés d'étude, sans expérience préalable du travail collaboratif.

### Sur le public-cible de la formation

Divergences des contenus nécessaires aux managers et aux chargés d'étude:
- il faudrait davantage d'infos sur ce que les managers ont besoin de savoir. Certains managers stratégiques (qui ne sont pas chefs de projet) ont des besoins qui vont au-delà de l'attribution de droits sur les dépôts.
- Insister davantage sur les bonnes pratiques et sur les rôles.
- Aborder davantage les enjeux spécifiques à la production statistique (maintenabilité, reproductibilité, pérennité des dépôts).
- Cette formation est importante pour la prise de poste de chargés d'études. Serait-il possible d'organiser une session à la rentrée pour les nouveaux arrivants?

### Sur l'organisation de la formation

- Commencer par une vision d'ensemble de l'écosystème logiciel qui sera présenté;
- Insister sur le pourquoi de l'usage des outils collaboratifs, en séparant ces fondements de la présentation des outils.
- Prévoir un moment au début de la formation pour vérifier que tous les comptes sont créés.
- *tester la proposition d'Elise de diviser en sous salons pour la partie exercice en binôme et/ou correction personnalisée*


### Sur le contenu

- La pratique de git est très utile.
- L'explication de l'intérêt de git est bien.
- Sur la présentation de git: bien expliquer que git sert à versioner des codes (et rien d'autre), et git ne se substitue pas à une bonne organisation collective.
- Insister sur la dimension collective du passage aux pratiques collaboratives.
- Il manque des choses sur comment on revient sur un commit précédent, comment on paramètre une clé SSH.
- Mieux alterner les considérations théoriques sur le contrôle de version et les exercices.
- Faire des slides plutôt qu'un texte?
- Est-ce une politique systématique de l'Insee de recommander l'usage de git avec Rstudio?
- Essayer de mieux prioriser les éléments essentiels pour les stagiaires.
- *Ajouter 1 ou 2 schémas au début pour avoir déjà une vue d'ensemble de l'architecture. L'idée serait voire comment les outils (pourquoi pas une version avec les outils internes, une version outils externes pour le public SSM) interagissent. Cela permettrait de voir en un coup d'oeil comment les différents services / instances / plateformes communiquent.*
- Enlever des exercices sur git.
- Faire deux formations différentes avec deux niveaux de technicité différents?
- Insister moins sur `git push force`, et faire la liste de toutes les erreurs qu'on peut faire avec `git` sans conséquences importantes.

### Retour de JLL

- Le niveau technique de la formation est trop difficile pour les agents moyens qui participent aux formations.
- La première partie est trop théorique, confuse, noie les éléments importants.
- La partie sur l'avertissement sur `git push force` est surréaliste.
- On ne peut pas commencer en disant qu'on va se taper la tête contre les murs.
- Un livre html n'est pas un bon support.
- Il manque une démonstration sur AUSv3.

### Post formation :
#### Annie
**Question**
A priori le besoin et l'utilisateur final ont évolué. Si j'ai bien compris la cible est maintenant de produire un support modulable pour :
* 2 publics : encadrant, CE/CP
* dans un format adapté à du présentiel et du distanciel ?

**Remarques**

Le bilan est positif du côté de mes collègues. La formation les a motivée à s'y mettre. Toutefois il manquait une vision d'ensemble ainsi que des éléments pratiques sous forme d'exercice ou de fiches pour pouvoir démarrer rapidement après la formation.

Globalement, je pense qu'on pourrait compléter pour les vrai novices (je ne sais pas qui l'était vraiment. Mes collègues de la DR Hdf connaissaient un peu et avaient assisté juste avant à la présentation du datalab et de git par un membre du PSAR EP.) :
* 1 ou 2 schémas de l'architecture d'ensemble
* ainsi qu'une fiche pratique/mode opératoire d'initialisation afin qu'ils puissent rapidement tester après la formation : cheat sheet git + guide d'installation rapide. Pourquoi pas une version interactive et une version git bash (public PSAR ?).

Il est signalé pendant la formation qu'il faut faire attention aux informations recuillies sur internet, que tout n'est pas à prendre. On pourrait noter également pour ce qui est de l'interne, que l'utilisateur en recherche d'information a également du tri à faire entre les informations consultables sur : Siamois, d'éventuels documents de service, la plateforme innovation, AUS, wiki gitlab SNLA... Quelle source privilégier ?