Présentation retour des consultations sur les indicateurs

• L'animateur est debout
• Mail de rappel pas indispensable, la réunion est dans l'agenda OSUG-DC
• Partager l'agenda en 2 agendas : consacrer l'un des agendas aux réunions OSUG-DC
• Relevé de réunion à faire dans la foulée
• Prendre les notes sur le wiki pendant la réunion (les notes sont directement en ligne)
• Précision sur les trolls : si une discussion démarre sur un sujet qui n'est pas à l'ordre du jour, on met le sujet dans backlog-meetings.

Les droits du groupe OSUG ne conviennent pas. Trop de personnes OWNER ou MAINTAINER du groupe. Risque de casser quelque chose dans un projet qui n'est pas le nôtre. On ne veut pas avoir de reponsabilité sur les dépôts d'un autre projet.

Droits Gitlab

Proposition de modification des droits OSUG

La proposition est acceptée. Les OWNERs du groupe OSUG seront : Laurent B., Damien A., Rémi C. Laurent effectue les modifications qui ont été entérinées, sur le groupe OSUG.

Le rôle de OWNER est valorisant. Le OWNER doit être conscient de sa responsabilité. Il est responsable de la création des sous-groupes et projets. Des projets qui n'étaient pas dans le groupe OSUG vont pouvoir le rejoindre, voir aussi avec les labos.

Sur l'infrastructure, 1.41 TB (incluant backups) / 2.49 TB utilisés (git) et 40 / 200 GB utilisés pour docker registry. Pas de limite pour l'instant sur la taille des dépôts.

Remarque sur le nombre d'utilisateurs actifs : c'est surtout l'évolution de ce nombre qui est un bon indicateur plutôt que le nombre lui-même.

JMMC : a pour objectif de mettre en place des solutions pour traiter des données d'observations en direct.

RESIF : 1 DOI par réseau sismologique. C'est Catherine qui contacte les correspondants des réseaux pour le référencement des DOIs. Une automatisation de cette tâche serait intéressante. Une personne de Strasbourg a fait le travail pour récupérer la liste des citations de RESIF.

RESIF fera un retour en réunion OSUG-DC sur sa demande de certification.

2 points de vigilance sur les postes :

• Remplacement de Catherine sur RESIF
• Fin de CDD de Philippe pour SHADE

Ne pas se fier seulement aux indicateurs, faire une analyse de risques. Risques sur le projet, sur l'exploitation (disponibilité du service, disponibilité et intégrité de la donnée). Plan d'actions pour baisser le niveau de risque. Cartographier les risques permet de justifier les RHs.

1 indicateur manque : la fraction de temps passée entre développement et ASR.

Sur le plan d'actions, préciser ce qui est facile à résoudre et ce qui ne l'est pas.

Se poser la question au niveau des infrastructures logicielles : à partir de quand celà devient trop complexe et peut générer des risques.

Décision : faire une fois par an un point sur les indicateurs. Transmettre le résultat aux responsables scientifiques, présenter un plan d'action, pour justifier une demande de poste.

Arrêt de l'ancien serveur de monitoring zabbix d'ici la prochaine réunion.