-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jeux de données périmés - réflexions sur les notifications #2379
Comments
La configuration des notifications est pour le moment réalisée à la main, c'est quelqu'un qui doit faire une association slug de jeu de données/liste de contact https://github.com/etalab/transport-notifications. Ça a donc plusieurs limitations :
à noter que plusieurs producteurs sont déjà autonomes et disposent d'outils proposant des fonctionnalités similaires. Des réutilisateurs, en particulier calculateurs d'itinéraires font aussi des relances par des canaux privés ou par le biais de commentaires sur le PAN. Pour les GTFS saisonniers il y a moyen de gérer ça dans le GTFS, mais il faut que les producteurs jouent le jeu #2336 |
Pour les mails à l'équipe, je me demande s'il serait utile de savoir qu'un rappel a été envoyé aux gestionnaires (AOM/transporteur). |
1/ Pour les mails à l'équipe je pense que ça serait effectivement intéressant de savoir quand un rappel a été fait, pour qu'on puisse relancer également de notre côté au moins à J-1, voire appeler quand c'est une AOM avec laquelle on échange souvent. 2/ Pour les JDD déjà périmés, je trouve que les informations fournies dans le backoffice suffisent mais si tu ne trouves pas ça suffisant @ChristinaLaumond, ça pourrait être ajouté oui. 3/ Pour la configuration des notifications , ces limitations présentent également des avantages :
4/ Pour les GTFS saisonniers il me semble que c'est principalement Zenbus qui en publie. @AntoineAugusti a laissé un message dans le Channel Slack Zenbus<>PAN |
Merci à tous pour vos retours. Concernant les mails aux producteurs : Pour les GTFS saisonniers c'est noté. Pour les jdd périmés le back-office est suffisant en effet pour notre usage interne. Mais quid des producteurs ? le système de notification actuel envoie des mails de relance avant et après la péremption ? cela rejoint le point 1 sur la gestion des notifications des producteurs où l'idée serait d'avoir une configuration adaptée par chaque producteur : je souhaite recevoir un mail 15 jours avant, 1 jour avant et si mon jeu est périmé un mail d'alerte hebdomadaire me rappelant que mon jeu est périmé (par exemple). Je ne me rends pas compte de la complexité et de la durée de l'ajout de cette fonctionnalité côté dev mais on pourra en parler en réunion d'équipe pour voir si ca vaut le coup de se lancer là dedans ou non ;) |
@ChristinaLaumond Voir l'issue précédente pour l'historique concernant les notifications de péremption #1461 Le fonctionnement que tu décris avait été envisagé mais écarté pour le moment au vu du temps de travail requis. On ne stocke aussi pas d'informations personnelles dans notre base de données et changer ceci est notable. Ceci est susceptible de prendre plusieurs jours de travail de dev, il faudra donc en parler. À noter qu'actuellement il n'y a pas de rappel après péremption. Envoyer des rappels réguliers avec le système actuel est relativement aisé par rapport à l'alternative que tu proposes. |
Merci, j'ajoute ces éléments dans l'investigation authentification (qui était orienté plutôt authentification réutilisateur mais qui peut être élargi à l'authentification producteur également) pour arbitrer ce sujet à la fin de l'investigation. En attendant, c'est noté pour l'ajout d'un rappel après péremption via le système actuel. @Miryad3108 qu'en penses-tu ? ça nous permettrait d'automatiser cette tâche de relance si le jdd est périmé. On pourrait imaginer envoyer un mail automatique tous les lundis par exemple, dès lors que le jeu est toujours périmé ? |
Après péremption je pense que c'est mieux que soit un.e membre de l'équipe qui reprenne la main parce que si ils ne font rien après avoir reçu un mail 14j, 7j et 1j avant la péremption je me dis qu'ils ne le feront pas après et qu'un mail plus "direct" aura plus d'effet. Sinon envoyez quelques jours après la péremption puis qu'on prenne le relai. |
etalab/transport-validator#144 devrait amener des dates d'expiration par agence à terme |
ça peut être fermé @AntoineAugusti ? |
Hello,
Suite à une discussion avec @thbar sur les emails envoyés par le PAN en automatique nous avons réfléchi en particulier aux alertes envoyés sur les jeux de données arrivant à expiration.
Aujourd'hui :
- Mail envoyé à l'équipe :
le PAN envoie un mail récapitulant les GTFS arrivant à expiration à différentes échéances : demain, +7j, +14j (et peut-être +30j ?)
Il serait peut-être intéressant d'ajouter à ce mail la liste des jeux de données déjà périmés (tous ou uniquement ceux qui sont périmés depuis moins de 2 mois par exemple).
Autre solution -> au lieu d'un envoi par email, avoir une notification quotidienne sur mattermost indiquant les jdd périmés.
- Mail envoyé aux producteurs
Il semblerait qu'ils ne reçoivent qu'un mail leur indiquant la péremption à l'échéance qu'ils ont configurée. S'ils n'ont rien configuré, ils ne reçoivent rien. On pourrait envoyer un ou deux mails supplémentaires au moment de l'expiration du jeu de données -> le jour de l'expiration, 1 mois après l'expiration si c'est toujours le cas.
Un point de vigilance : les jdd périmés mais dont la péremption est normale -> transport saisonnier par exemple ou funiculaire en panne (donc pas de données à jours). L'idée serait de pouvoir temporairement "désactiver" ce jdd pour ne pas qu'il apparaisse dans les notifications.
Pour en reparler avec @Miryad3108
The text was updated successfully, but these errors were encountered: