CR_2021_01_20
Présents : Olivier Meslin, Lino Galiana, Arnaud Degorre, Benoit Rouppert, Patrick Sillard, Marie-Emmanuelle Faure, Pierre-Yves Berrard, Romain Lesur, Cédric Tassart, Claire Legroux
Olivier, Lino et Romain devaient essayer de générer le document via pagedown au lieu de LateX.
L’utilisation actuelle de LateX est lourde et demande beaucoup de travaux de redressement.
pagedown est un package R dont Romain est le créateur. L’appui de Romain a été précieux, il a pu mettre à jour le package pour lever les derniers freins (produire un "gros" document comme UtilitR).
pagedown permet de ne se préoccuper que de la mise en page HTML, l’export dans différents formats de sortie dont le PDF est automatiquement géré par le package. Il n’y a ainsi qu’une seule branche à maintenir pour la mise en forme (et non une pour l’HTML, et une pour le format papier PDF).
Une première version "Preuve de concept" a été réalisée avec pagedown et l’avis des participants est demandé pour valider le passage à pagedown.
Arnaud précise que l’utilisation de pagedown constitue la cible dans la pile technique des circuits éditoriaux Insee. Son usage pour UtilitR est donc un bon signal.
La mise en page est propre, sophistiquée. Les composants utilisés sont variés. Sans qu’ils reprennent toutes les possibilités offertes par LateX, le résultat est en phase avec ce qu’on pouvait attendre. Benoît et Patrick rejoignent l’avis d’Arnaud, notamment sur la richesse des éléments utilisés : "Que dire de plus ? "
Pierre-Yves confirme que le document est très propre : Bien joué ! Olivier insiste sur les nécessaires retours des contributeurs. Toutes les remarques sont les bienvenues pour concevoir un produit convivial.
Des issues sont ouvertes pour se mettre d’accord sur les différents aspects visuels. Les contributeurs sont appelés à participer.
Arnaud soulève une dernière question sur la limitation de pagedown pour la gestion des fins de pages (bascule des éléments d’une page à l’autre par exemple).Cela concerne vraiment peu UtilitR, mais il semble que cette gestion soit plus manuelle avec pagedown.
Olivier précise qu’il manque effectivement une notion de "float " pour gérer le placement automatique des éléments. Cela demandera une correction finale à la toute fin de la validation du document, mais dans le cadre d’UtilitR, cela ne représente pas une charge importante.
Olivier demande à Romain de repréciser pourquoi seule une licence est possible dans le cas d’utilitaire.
L’ensemble des licences ouvertes disponibles, pour les administrations sont présentées sur cette page : https://www.data.gouv.fr/fr/licences
Le choix de la licence varie selon le type d’éléments concernés : • code • données et bases de données • texte, contenu créatif
Selon ces différents types, l’une ou l’autre licence est plus ou moins bien adaptée.
UtilitR rentre surtout dans le cadre de « contenu créatif » et contient aussi un peu de code pour la gestion du dépôt Github.
La seule licence qui peut donc couvrir l’ensemble est la licence etalab 2.0 https://www.etalab.gouv.fr/wp-content/uploads/2017/04/ETALAB-Licence-Ouverte-v2.0.pdf
Patrick demande si la production respecte ce type de licence. Romain précise qu’aucun choix uniforme n’est imposé à l’ensemble des productions. La licence est choisie selon chaque cas.
insee.fr précise par exemple comment le contenu peut être réutilisé, mais ne mentionne aucune licence spécifique. https://www.insee.fr/fr/information/2381863
Pour permettre de travailler pendant le premier confinement, le code a été ouvert au printemps.
Sur Github, tant qu’aucune licence n’est précisée, il n’y a aucun droit de reproduction.
Les contenus soumis à licence ont été retirés.
Olivier prévoit de reformuler quelques paragraphes (la source devra être citée).
Actuellement la licence utilisée est CC by SA 4, compte tenu des échanges, la licence etalab-2.0 va donc être adoptée.
Olivier précise le calendrier prévu pour la mise en production de la V1 Évènement de lancement au printemps (1ère quinzaine de juin au plus tard!) => Finir le contenu fin février (pour Lino et Olivier, si le contenu est bouclé mi-février, ce serait plus pratique !)
- Mars : relecture sur le fond
- Avril : relecture sur la forme
- V1 en prod mi-Fin Avril.
Quelle deadline pour planifier l’évènement ?
Pour les réservations de salle, il faut anticiper le plus possible, pour la communication, 3 mois sont largement suffisants.
Des échanges plus précis auront lieu ultérieurement, et un sous groupe de collaborateurs pourra se mettre en place pour préparer l’organisation. Quelques idées sont déjà lancées, rien n’est arrêté !
Olivier envisage une présentation de 40 minutes, puis de donner la main à Arnaud, par exemple, pour présenter l’ensemble des initiatives sur R (FunCamp, formations R, guide pour les statisticiens de C. Afsa…). Claire propose qu’on intègre aussi un temps d’atelier pour rendre l’évènement plus « actif ».
Elle alerte aussi sur le positionnement d’UtilitR par rapport aux autres initiatives, plus institutionnelles. Il faut savoir positionner UtilitR par rapport à l’ensemble pour que sa « marque de fabrique » soit préservée. Les autres participants, notamment les parrains ne sont pas inquiets. UtilitR reprend souvent les arbitrages du Cops, ou les anticipe. L’appui des parrains est important pour veiller à garder la force collaborative d’UtilitR.
Par ailleurs, le contexte sanitaire ne sera sans doute pas totalement levé en juin, il faudra nécessairement en tenir compte.
Tous les participants se rejoignent : l’évènement ne peut pas être que « présentiel ». Patrick insiste sur la place à donner aux DR. À ce sujet, Lino et Olivier prévoiraient bien un « tour de France » UtilitR pour relayer l’info.
Claire rappelle que les contributeurs sont répartis aussi en DR. Il peut donc être intéressant, de s’appuyer sur chacun pour la mise en place d’évènements locaux. C’est aussi une occasion de valoriser leur investissement.
Arnaud reprend ces idées. Il imagine quelque chose en 2 temps:
- La présentation d’UtilitR, suivie par une présentation de toutes les ressources sur R, notamment dans le cadre de Palettes. Il est tout à fait à l’aise pour présenter ces initiatives et montrer leurs forces, leurs liens et leurs spécificités.
- Il faudrait aussi envisager un temps avec une dimension plus implicante des participants.
Olivier craignait qu’un évènement organisé au Fairway n’attire pas, mais Arnaud relève qu’en mode atelier, ce ne serait pas gênant. Sur le modèle du FunCamp, il pourrait y avoir un temps de prise en main avec un spot pour décrire un sujet. Ce type de configuration se prêterait assez bien à la mise en place de sous groupe virtuels.
Partager l’évènement de cette façon permettrait de passer de la présentation à l’appropriation.
Un tel évènement serait plutôt centré autour de R, en faisant largement appel à UtilitR comme « colonne vertébrale » ?
Pour Olivier, il est hors de question de proposer un évènement qui n’aborde que UtilitR.
En conclusion, Les salles Malinvaud-Closon et une grande salle du Fairway doivent être réservées en priorité dès que possible, éventuellement avec plusieurs options de dates qui seront confirmées début mars. L’ensemble du contenu doit être rédigé pour fin février dernier délai.
(à compléter par Olivier, qui semble-t-il avait une liste sous les yeux!)
Marie Emmanuelle a presque terminé la partie concernant les API. Elle doit compléter pour les API sur les données locales d’ici la semaine prochaine.
Gilles sera aussi disponible pour terminer dans les délais, mais il a du mal avec le nouveau workflow sur Github. Olivier et Lino vont l’aider
Lino a commencé à rédiger la partie sur l’usage de Git
Lino précise que le contributing est presque à jour, et que ce sera bouclé d’ici demain. Gilles pourra faire la relecture (puisqu’il en a justement besoin !)
La question se pose de conserver le guide des bonnes pratiques dans UtilitR.
Ne serait-ce pas trop « prescripteur » par rapport au rôle d’UtilitR ? N’est-ce pas le rôle de l’Unité Qualité d’émettre des recommandations de ce type ?
Les bonnes pratiques ne sont pas des « normes » mais un ensemble de pratiques, partagées, reconnues comme telles. Romain précise que les bonnes pratiques proposées correspondent aux standards internationaux. Il ne s’agit donc pas d’établir une règle pour les agents de l’Insee.
Claire rappelle que l’une des missions des référents LS², en tant qu’utilisateurs qui partagent leurs pratiques, se concertent, et développent une expertise, est d’émettre des bonnes pratiques. La dimension collaborative d’UtilitR y amène naturellement. Les bonnes pratiques proposées, sont aussi celles qui sont utilisées dans le cadre de la rédaction de la documentation. Il s’agit donc des pratiques des contributeurs.
Benoît précise qu’il s’agit d’un partage d’expérience entre pairs. Il n’y a pas de raison qu’une unité particulière puisse émettre une bonne pratique pour les autres.
Arnaud et Patrick partagent aussi ces avis. Arnaud propose que les bonnes pratiques soient publiées sous forme d’un fascicule distinct. Cette proposition est validée.
Néanmoins Patrick pointe certaines fiches qui semblent essentielles mais sont moins du ressort d’une « bonne pratique » (l’écriture vectorielle par exemple).
Olivier précise que dans le cadre des objectifs de la V1, les thèmes abordés par ces fiches allaient sans doute un peu loin. Il faudrait les compléter pour les mettre ailleurs dans une V2.
Claire propose que pour la V1 ces fiches soient conservées dans les bonnes pratiques en y insérant un disclaimer.
Pour finir, qu’en est-il de la diffusion de la partie « spécifique » Insee ?
Lino insiste sur la nécessité d’isoler le contenu pour faciliter la gestion des parties qui ne seraient pas publiques.
Olivier note que cela concerne à priori 2 fiches :
- R sous AUS v3
- R avec le Gitlab interne
Ces fiches ne sont pas encore rédigées, et il est possible que selon le contenu, il soit possible de les rendre publiques (pour exemple l’accès à AUS v3 passe par un raccourci sur le bureau, aucune URL ne serait précisée).
Il faudra donc soumettre ces fiches à l’avis de DSMR. Compte tenu de la charge de validation, Arnaud appuiera le besoin, pour que la publication ne soit pas retardée dans l’attente de cet avis.
Ces fiches devront être rédigées sur le Gitlab interne. Lino prévoit le mettre en place prochainement.
La prochaine réunion sera à programmer début mars.
Il s’agissait de la dernière réunion avec Benoit. Les parrains ont poursuivi l’échange pour envisager la suite du parrainage compte tenu du départ prochain de Benoît, puis d’Arnaud.
- licence du projet : etalab-2.0
- adoption de pageDown
- le guide de BP sera isolé sous forme de fascicule distinct
- Calendrier
- tout le contenu doit être rédigé pour fin février.
- Evènement de lancement pour début juin
- réservation des salles dès maintenant
- contenu à préciser : mise en place d’un sous groupe pour l’orga à envisager
