Mardi en commun 3

hcklabxl

#1

Mardi en commun

Horaire

Tous les mardis matin nous nous retrouvons au HCKLABXL pour discuter d’InCommon, découvrir les applications et avancer ensemble sur le projet.

Lieu

Au hacklab, 46, avenue Princesse Élisabeth à Schaerbeek, face à l’arrêt de tram 92.

Participant·e·s

  • Oui, je serais présent·e
  • Non, je ne peux pas venir

0 voters

Objectifs

Il s’agit de la dernière réunion avant la mise en production de la première version de l’API prévue le 31 octobre. À part les discussions techniques concernant l’API elle-même et le frontend, nous envisageons de finaliser la Charte IN COMMON. D’où cette annonce en avance…

Cette liste est une proposition : si vous voyez d’autres points à aborder, merci des les indiquer dans les commentaires.

API Release Check

Durée estimée : 2 heures

  • finaliser le code : il s’agit de terrasser les derniers bugs avant la mise en production
  • mise en production : sur https://api.incommon.cc
  • publication du code : sur les dépôts officiels (Framagit et les miroirs sur Gitlab et Github
  • annonce de version : il s’agit d’écrire les notes de version.

Point frontend

Durée estimée : 1 heure

  • choix techniques : revue des choix techniques (pour l’instant on est sur Vue.js
  • design : revue des éléments de design (interface, modularité, personnalisation ou ‘marque blanche’)
  • déploiement : quelle stratégie pour le déploiement des fonctionnalités ?

Charte IN COMMON

Durée estimée: 2 heures

  • état des lieux : le point sur la discussion en cours
  • publication : finalisation d’une première version de la Charte dans le but d’une discussion plus large

Mardi en commun
#2

Comme le dit très bien @natacha, étant seul à utiliser ce système, et n’ayant de sensiblité que celle qui, par le biais de mon organisation, conduit les autres à ne pas s’impliquer, je constate que je suis une fois encore seul à montrer un quelconque intérêt pour ces réunions du mardi qui, en tout cas pour celle-ci, a été annoncée une semaine à l’avance ; en en réponse à l’absence de réponse et l’ignorance des arguments des unes et des autres, je m’invite à rester au chaud et poursuivre mon immense travail sans aide aucune, mais surtout sans dériver de ma tâche pour qu’au moment prévu je puisse m’en détacher et la faire porter enfin au “collectif”.

À bon entendeur, salut.


#3

Je suis en désacccord complet avec ce modèle de fonctionnement, je ne pense pas que une personne seule devrait prendre en charge la production logicielle, je crois que la pratique collective doit être à l’origine d’un projet, elle ne peut en aucun cas émerger de façon magique après, une fois que le code est publié. si le code est réalisé par une personne, c’est cette même personne qui sera ultimement responsable de son travail, cela prouve simplement que le projet n’est pas un projet collectif.
Je crois qu’il est urgent d’arrêter cette manière de faire et de prendre le temps de clarifier la situation avec les différents partenaires de in common, et que chacun investisse une énergie propre à faire exister ce projet.


#4

En bref je crois qu’il est urgent de s’arrêter et de penser de nouvelles formes pour ce projet qui le fassent exister collectivement.
Aussi, je voulais préciser à nouveau, bien que cela semble pourtant évident, étant la seule personne du groupe qui ne reçoive par aucun moyen la perspective d’une compensation financière dans ce projet, (ce qui ne fait que reproduire des inégalités structurelles sociales) j’ai décidé de ne plus libérer mon temps bénévolement pour assister à aucune réunion.

@ptr_here @how @fodevaux @mathieu


#5

Montre-moi un seul projet libre qui n’est pas parti d’une personne qui produit du code, et qui ensuite accueille des contributions. 95% des projets libres sont maintenus par une seule personne, avec des contributions de 1 ou plusieurs personnes. Dans tous les cas, il y a d’abord un morceau de code qui est produit, c’est le cas ici.

Dès lors, une discussion peut s’établir sur une base qui n’est pas que de la conversation abstraite.

Pour le reste, notamment “que la pratique collective doit être à l’origine d’un projet”, je suis tout à fait d’accord. Le code présenté ci-dessus par de l’expérience de Dewey Maps et des pratiques évoquées par certains partenaires lors de nos rencontres ces derniers mois. La pratique de Dewey Maps seule n’aurait pas donné ce résultat. Il s’agit donc bien d’une base de code répondant à une pratique collective.

Tout-à-fait. À présent que nous avons une base commune de discussion concrète, nous devons le faire.

Oui.

Je pense que la question du budget, que j’ai évoquée par ailleurs avec @fodevaux est effectivement nécessaire. François tu avais prévu d’ouvrir un sujet dans #staff, je crois que c’est le moment.


#6
  • une première version du code est publiée sur Gitlab (voir le lien ci-dessus) et est en cours d’installation sur https://api.incommon.cc.
  • quelques bugs ont été corrigés pour assurer la viabilité du release. Lorsque l’installation sera terminée, nous pourrons tester les différentes requêtes nécessaires à l’affichage d’une carte.

Requêtes préalables

Requête initiale pour déterminer la clé d’API à utiliser

curl -i https://api.incommon.cc

Cette requête permet de trouver la clé publique pour la lecture : 23d8009f-f2ec-44b6-bcbe-58ad1d3af10b

découverte de la carte

curl -i 'https://api.incommon.cc/maps?api_key=23d8009f-f2ec-44b6-bcbe-58ad1d3af10b

Cette requête permet de trouver l’identifiant unique de la carte de Dewey Maps :
518957a0-6580-4b0a-9d78-8fcd986aec88

Requêtes pour utiliser la carte

Il y a plusieurs manières d’accéder aux données pertinentes :

  • on peut passer par la carte elle-même, c’est la méthode recommandée
  • on peut passer par la taxonomie d’un côté si on connaît déjà les coordonnées de la carte (centre et zoom)
  • les ressources elles-mêmes sont accessibles par une requête séparée afin de faciliter la pagination des résultats. On peut y accéder par la Collection de la carte, ou par les Sections de la taxonomie. (À suivre…)

(Recommandé) Accès par la carte

curl -i https://api.incommon.cc/maps/518957a0-6580-4b0a-9d78-8fcd986aec88?api_key=23d8009f-f2ec-44b6-bcbe-58ad1d3af10b&include=agent,taxonomy,taxonomy.categories,taxonomy.sections

La requête comprend les éléments suivants :

  • identifiant unique de la carte : 518957a0-6580-4b0a-9d78-8fcd986aec88 pour la carte de Dewey Maps
  • api_key : la clé d’API est requise pour obtenir la ressource. Pour l’instant il s’agit d’une clé publique utilisable par quiconque. Elle offre un accès en lecture seule sur les données publiques.
  • include : il s’agit d’inclure les ressources associées à la carte afin de limiter les requêtes HTTP. Une seule requête permet donc d’afficher la taxonomie complète et de centrer la carte à l’endroit prévu.
    • l’Agent (agent) est le collectif responsable de la carte. L’obtenir est utile pour le créditer.
    • la Taxonomy contient la classification spécifique à cette carte. Elle se compose de catégories qui contiennent des sections auxquelles sont associées les ressources. On obtient l’ensemble de cette classification en demandant d’un seul coup la taxonomie (taxonomy), ses catégories (taxonomy.categories) et leurs sections respectives (taxonomy.sections).

Nous voici donc en possession de la représentation JSONAPI de la structure de la carte, nécessaire pour afficher la carte avec Leaflet.

Requête(s) pour obtenir les données

Une fois la carte obtenue, on peut récupérer les ressources associées. Souvent, plusieurs requêtes seront nécessaires afin d’éviter les délais de traitement et d’affichage. Par exemple on pourra demander les ressources associée à une section spécifique ou à une localisation donnée.

(À suivre…)


INCOMMON::API Version 0.5.0
#7

FELICITATIONS c’est un travail énorme


#8

#9

Un immense bravo pour cette release et l’incroyable travail qui a mené à ce résultat. Bravo aussi pour le timing, cette release a été faite à la date prévue (avec un jour d’avance même) !

Étant en vacances en famille et sans ordi, je vais uniquement tenter un résumé de ce que j’ai en tête au sujet des éléments partagés ci-dessus.

J’entends bien la frustration de @natacha et @how qui ne sentent pas encore la dimension “collective du projet”. Je partage ce constat, même si je pense que la publication cette release marquera un tournant dans le projet.

Il y a eu beaucoup d’intérêt pour le projet, mais le fait de ne pas pouvoir “voir” de résultat (carto, classification,…) n’a pas permis de transformer cet intérêt en soutien. Nous nous y attendions tout de même, sachant qu’il est difficile pour des non informaticiens de percevoir le potentiel d’un projet en sa basant sur les specs d’une API. Et nous savons également qu’il faudra encore un peu de développements pour que le projet “parle” à la majorité des curieux. Ceci dit, les plus développeurs vont pouvoir jouer avec l’API (je m’en réjouis perso) et nous allons davantage rentrer dans une phase de co-création.

Nous avons besoin de financements, et devons chercher au delà des soutiens initiaux (Mycélium, Wallonie#Demain, Mutualisons,…) . Chercher ces financements demandera également du temps (rencontres, dossiers, admin,…). Le tout dans une grande transparence. J’avancerai la semaine prochaine à ce sujet dans la section staff.

L’autre priorité est le développement de notre gouvernance partagée afin que les rôles et mandats soient clairs et que l’on puisse permettre à chacun de s’engager dans le projet en fonction de ses disponibilités.

Poursuivre les rencontres des “mardi en commun” est important (même s’il faudrait sans doute revoir le timing car, comme exprimé à @how, je ne suis jamais disponible le mardi avant 15h).

Voilà pour les premiers éléments que je voulais partager avec vous.

Au plaisir de continuer ces échanges, et encore un MEGA bravo à @how pour le travail accompli pour cette release, et à tous (je pense en particulier à @natacha et @mathieu +les acteurs de l’ombre) pour l’énergie mise dans cette première étape, la plus frustrante sans doute.

Longue vie à In Common !

François


split this topic #10

3 posts were merged into an existing topic: Mardi en commun 4


#13

La suite : Mardi en commun 4


#16

Jusqu’ici, ça a été pour tester le code. Impatient de découvrir la suite…

Question, ce tuto se trouve-t-il qqpart dans la section “API” du Discourse ?


#17

Pas encore. Mais quote-paste devrait marcher :slight_smile:


#18

En exécutant

En fait, je m’attendais à recevoir la structure JSONAPI, mais voici ce que j’ai reçu:

{“data”:{“id”:“518957a0-6580-4b0a-9d78-8fcd986aec88”,“type”:“maps”,“attributes”:{“id”:1,“zoom”:12,“center”:{“longitude”:4.35308,“latitude”:50.83906}},“relationships”:{“collection”:{“links”:{“self”:“http://api.incommon.cc/collections/1"},“meta”:{“resource_count”:12018}},“position”:{“links”:{“self”:“http://api.incommon.cc/positions/8230”}},“taxonomy”:{“meta”:{“included”:false}},“resources”:{“meta”:{“included”:false}}},“links”:{“self”:“http://api.incommon.cc/maps/518957a0-6580-4b0a-9d78-8fcd986aec88”},“meta”:{“locale”:“en”}},“jsonapi”:{“version”:"1.0”}}


#19

@fodevaux Il faut ajouter des guillemets autour de l’URL, sans quoi le shell peut interpréter le point d’interrogation comme un motif signifiant “n’importe quel caractère” :

curl -i "https://api.incommon.cc/maps/518957a0-6580-4b0a-9d78-8fcd986aec88?api_key=23d8009f-f2ec-44b6-bcbe-58ad1d3af10b&include=agent,taxonomy,taxonomy.categories,taxonomy.sections"

#20

Super ça marche, merci !


#21

Je pense qu’il y a un souci CORS

Erreur Firefox
Blocage d’une requête multiorigines (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur https://api.incommon.cc/maps/518957a0-6580-4b0a-9d78-8fcd986aec88?api_key=23d8009f-f2ec-44b6-bcbe-58ad1d3af10b&include=agent,taxonomy,taxonomy.categories,taxonomy.sections. Raison : l’en-tête CORS « Access-Control-Allow-Origin » est manquant.[En savoir plus]

_


#22

Oui c’est fort possible. CORS n’a aucune raison d’être déclenché sur une requête GET qui ne passe aucune information susceptible de déclencher CORS. C’est-a-dire que Firefox n’est pas vraiment un client API. D’autre part CORS n’est pas encore implémenté parce qu’on a fait en sorte que les requêtes ne le nécessitent pas.


#23

@mayliss, @fodevaux,
Merci François. On a longuement parlé d’InCommon lors de la réunion “Mutualisons” d’hier matin avec Mayliss et Chalaine. HK n’est dispo le mardi et pas le lundi et Mayliss le lundi et pas le mardi. Donc, il faudra prévoir une première réunion sans Mayliss un mardi matin. J’envoie un mail à tout le monde à ce sujet


#24

ou sans moi un lundi matin :slight_smile: