# Brainstorming Execution de pipeline et jeu de données

> [time=Wed, Sep 15]
> [name=Complete Poyphene team]

Enjeu du brainstorming

- Définir ce qu’est le run de pipeline
- Définir les fonctionnalités associées.
- Définir le scope de Dakar

*Discussion préliminaires : doit on définir maintenant des cas d’usage pour le travail de wireframing ? Non, cela doit faire l’objet de discussion mais le sujet sera abordé plus tard dans l’objectif de la présentation des wireframes*

# I. Définition des éléments associés à l'éxecution de pipeline.

Les élements : la source de données, le résultat d'éxecution (donnée transformée) et l'éxecution elle-même. L'idée est donc de partager notre vision sur ces trois élements pour s'assurer qu'elle soit alignée, et défnir le périmètre fonctionnel de Dakar pour ces trois élements.
la dimension collaborative : essentiel pour Web3 (sera taclée à la fin du brainstorming)

***L’objectif pour Dakar est de proposer une XP complète et utile (pas juste une étape dans le dévelopement).***

# II. Tour de table

## Les sources de données
**Thomas :**
Il faut prévoir post Dakar différent moyen d’ingérer de la donnée : une connexion à une source distante de données par exemple, ou l'upload manuel de sources de données.Il faudrait également prévoir une description de la source de donnée.
Pour Dakar : upload manuel, possibilité d’ajouter de la métadonnées simple (nom, description).
Hébergement de sources de données ? Si on prone la collaboration , c’est une fonctionnalité importante.
**Philippe :**
On doit rester focaliser sur le run de pipeline. On ne se connectera avec une source de données distante. On pourra se connecter avec Airbytes post Dakar.
On doit proposer une expérience complète mais isolé/ J’ai une donnée sur la plateforme, je peux la run sur des pipelines. Upload le plus basique possible.
Les usecases auxquels on devra répondre à Dakar seront de l’Open Data. On va permettre aux data scientist d’expliquer les transformations qu’a subies la données. Donc tout les élements doivent être sauvegardées. On est compatible IPFS : doit on créer une fonctionnalité qui permettent de pousser automatiquement les données transformées sur IPFS ? Oui, car c’est une attente de la communauté web3., c’est un espace de stokage ou tout le monde a accès à la donnée.
Pour Albert, ce n’est même pas une question. On pourrait même optimiser l’utilisation d’IPFS, en réalisant l’execution de transformations directement à la source de données. Pour Philippe cela pourrait être utilie mais pas adapté à ce que l’on fait.
Description des jeux de données : pas une nécessité pour Dakar car le problème sera reglé par Airbytes.
**Albert :**
Les call d’Open Data nous ont montré que la communauté aimait récuperer de la donnée , en API par exemple.
Pour Philippe c’est le rôle de solution comme Airbyte ou 5tran.
API pour ne pas avoir à upload la donnée (idée intéressante qui doit faire l’objet d’un point dédié —> plannifié)
Feature proposée : pouvoir controler la plateforme à l’aide de la CLI.

## La nouvelle donnée produite (output)
**Philippe :**
Comment rendre le partage de la donnée historicisée aussi simplement que le patage de la donn? Doit on produire un “lien, “certificat” ou une “doc” associés au résultat de la donnée produite. Pour Philippe oui, on répond au cas d’usage. A définir, la manière de partager ce “certificat” : lien vers PDF ?, lien vers une interface IPLD?.
Visualisation ? C’est une fonctionnalité attendue, mais cela doit être bien fait et demande un temps de developpement trop important pour s’adapter à tout type de données. Au de la de la business intelligence, ne doit on pas proposer une fonctionnalité de visualisation minimale pour visualiser du binaire dont la représentation brut n’est pas idéal ?
**Albert :**
Des exemples d’outil DAG a montré que la visualisation reste une fonctionnalité powerful notamment dans le cas d’usage ou l’on voudrait utiiser la visualition comme outil de debug (pouvoir visualiser les résultats de son pipeline en cours de dévelopement.
**Thomas :**
On doit vraiment se focaliser sur une fonctionnalité minimale pour s’assurer qu’elle soit utile. Pouvoir visualiser le résultat d’un CSV ou un JSON (format bien connu) sur une plage de certaines colonnes/lignes.

## L’éxecution du pipeline, les conditions

**Thomas :** Comme pour les sources de données , on doit rester simple : on éxecute via un bouton de la donnée en entrée.
Philippe : L’execution doit se faire oublier. Des outils dédiés. Pas de choses spécifiques à faire au niveau des logs. Le pipeline peut s’éxecuter au fur et à mesure de son dévelopement.
**Albert :** Question du coût importante à garder en tête, même si au début on aura peu d’utilisateur et que la question ne se posera pas forcément.
Nicolas : Temps d’éxecution. enjeu de limiter le point de friction. Pouvoir éxecuter le pipeline au fur et à mesure

# Miscellaneaous

**Collaboration :** Doit on viser de la collaboration à la Figma pour Dakar ?
Pour Philippe oui, mais cela demande un temps de developement important, on doit donc s’assurer que c’est un besoin essentiel pour se lancer dans cette fonctionnalité.
Pour Thomas ça ne l’est pas, on devrait réserver cette fonctionnalité pour les releases futures.

# Next step :

**Réflexions à mener :**
- Fonctionnalité run d’un pipeline autre que sur la plateforme. Pour Philippe, ce n’est pas important et rendrait confus le scope d’utilisation de la plateforme. On réservera la réflexion sur cette fonctionnalité au moment de l’intégration avec Airbyte.