|
|
* revue des deux dernières itérations : voir le wiki https://git.nomics.world/dbnomics-fetchers/management/wikis/iterations. Il devrait y avoir ce qui est prévu et ce qui est réalisé. Note : On passe tous les JSON en JSON schéma.
|
|
|
* itération actuelle : BLS; Eurostat; ILO.
|
|
|
* Michel : pour l'instant, aucun fetcher n'a été passé à la Banque de France. Réponse : WTO, DARES, ONS et DREES sont prêts à être analysés par la BDF.
|
|
|
* Michel : rallonger l'itération n'est pas la bonne méthode. Réponse : Cela ne se reproduira plus.
|
|
|
* WTO : problème de communication entre BDF et développeurs. Michel pensait qu'on allait s'arrêter début octobre. Il faut rappeler que la variable d'ajustement est le nombre de datasets dans le fetcher. Exemple : on remet les quarterly dans le backlog, WTO peut ainsi être mis en revue.
|
|
|
* pas besoin que Michel vienne au début de chaque itération, mais ne pas hésiter à utiliser les video conf.
|
|
|
* indicateurs quantitatifs d'avancement du projet : il faut voir si le système de poids permet de juger efficacement la difficulté des fetchers notamment.
|
|
|
* 2 exigences dans l'écriture de la description du fetcher : i/ vision synthétique pour la planification; ii/ issue par sous-tâche. Réponse : laisser faire les développeurs les sous-tâches en planification. Le bon exemple est ce qui s'est passé sur ONS. On reste à 1 issue par fetcher (plus la fiche).
|
|
|
* quelle techno pour émuler le JS ? réponse : requête POST.
|
|
|
* BLS : reprendre le code écrit par Michel (Bruno en visio avec Michel jeudi matin 9 novembre).
|
|
|
* WORLD BANK : sources très différentes, rend complexe le dataset (API pas forcément la meilleure source).
|
|
|
* BOE : une base de données (BANKSTAT). Tableaux excel avec structures similaires.
|
|
|
* faire une issue à part entière sur l'analyse des anciens fetchers.
|
|
|
* ESRI : Michel refait en effaçant les révisions.
|
|
|
* on acte que les révisions présentes dans Mongo ne sont pas importées dans Solr.
|
|
|
* la contrepartie du point précédent est de porter les fetchers anciens le plus rapidement possible pour commencer à stocker les révisions.
|
|
|
* travail de conceptualisation des révisions encore à faire.
|
|
|
* stockage des dates conforme au fournisseur. |
|
|
\ No newline at end of file |