Chiffrer le coût de chantiers importants

[srosset81]

Cela pourrait être très utile de prendre un moment pour définir clairement les chantiers envisagés à court et moyen terme et pour évaluer leur coût.

Chantiers actuels ou envisagés à court/moyen terme

Sans ordre de priorité

• Mettre en place les droits ACL #52
• Pouvoir lier deux instances SemApps #451
• Intégrer la nouvelle version de PAIR #452
• Visualiser les ressources sous forme de carte géographique #2
• Avoir une complétition Wikidata / Dbpedia #43
• Afficher les activités des utilisateurs #448
• Recherche avancée via Sparnatural #13
• Visualiser les données en graph #4
• Afficher l'historique d'une ressource #7

[bouviermullerp]

@srosset81

• il y a un chantier intégrer sparnatural - peut être après l'intégration de la nouvelle mouture de PAIR ? Le besoin de rechercher/trier des données exprimé par les utilisateurs est très fort.
• Une autre fonctionnalité exprimée serait traçabilité - pouvoir suivre l'évolution d'une donnée, qui a fait quoi en terme de création/modification/suppression - et faire de la pédogogie plutôt que du contrôle - peut être lié au fil d'actualité, ou une première étape
• La complétion Wikidata/DbPedia n'est pas forcément ultra prioritaire dans les ateliers que j'ai fait.
• Le besoin de pouvoir avoir le contrôle sur les données, sur qui peut publier quoi - donc un module "administration", créer des groupes d'utilisateurs avec des droits de publication/modération.

[srosset81]

• Une autre fonctionnalité exprimée serait traçabilité - pouvoir suivre l'évolution d'une donnée, qui a fait quoi en terme de création/modification/suppression - et faire de la pédogogie plutôt que du contrôle - peut être lié au fil d'actualité, ou une première étape

Oui ce serait lié à ActivityPub. Il faudrait que ça vienne après "Pouvoir voir les activités d'un utilisateur / suivre un utilisateur / avoir un fil d'actualité", car la notion d'historique d'un objet (lister les activités liées à l'objet) n'est pas défini dans la spec ActivityPub, il faudra donc un peu de réflexion / concertation en amont.

• Le besoin de pouvoir avoir le contrôle sur les données, sur qui peut publier quoi - donc un module "administration", créer des groupes d'utilisateurs avec des droits de publication/modération.

C'est en lien avec le chantier WebACL, qui est en cours.

Je me demande quel serait le meilleur moyen de garder une liste de ces chantiers ? @GuillaumeAV va nous dire "Sur une instance SemApps !" et je suis bien d'accord (c'est notre projet de "Chantiers collaboratifs" qu'on avait proposé avec @ReX-AV-Gab ) mais ça va prendre du temps. En attendant on pourrait peut-être créer des issues taggées chantier qui seraient simplement une liste de lien vers des sous-issues, avec des checkboxes pour marquer quand elles sont terminées ?

[srosset81]

Oh il y a justement une action Github pour gérer les epics: https://github.com/marketplace/actions/epic-issues-for-github S'il n'y a pas d'objection, je pourrai la mettre en place.

L'avantage des checkbox c'est que ça permet d'afficher un truc assez visuel:

[srosset81]

Voilà quelques avancées:

• J'ai mis en place l'action Github mentionnée ci-dessus.
• J'ai créé plusieurs templates d'issues, dont une pour créer un nouveau chantier
• J'ai transformé deux issues existantes en chantiers, visible ici.
• J'ai ajouté une colonne Chantiers dans la page projet afin de leur donner plus de visibilité. Je laisse @bouviermullerp décider si ça lui convient ou pas (peut-être que ça peut être mis dans un autre projet ?)

Reste encore à créer les autres chantiers mentionnés, puis surtout à les chiffrer une fois que tout a été clairement spécifié.

[bouviermullerp]

@srosset81 merci pour ces progrès, très cool. ça me convient d'utiliser les chantiers - on peut tester comme tu le proposes, j'ai plutôt l'habitude de travailler avec plusieurs projets, mais pourquoi pas. merci en tout cas

[GuillaumeAV]

Helloo !

Très rapidement ..

• Il y a les milestones aussi qu'on utilise pas (ca pourrait correspondre à des Epics / chantiers ?
• Complétion DbPedia / Wikidata : Je persiste à penser que ça doit être une priorité forte, dans la mesure où ça permet de produire des données structurées (plutôt que des chaînes de caractère non sémantiques) et de faciliter grandement le matching sur compétences, centres d'intérêts etc. sur la base d'URIs uniques. Sans ça, on va rapidement produire beaucoup de données de mauvaise qualité avec du bruit, des fautes et de la redondance. => Juste pour les données du meetup, j'ai passé 30mn à changer la casse des compétences et des centres d'intérêts (strings), à corriger les fautes d'orthographe et à fusionner des trucs pour avoir un résultat qui soit à peu près correct à l'arrivée.
  • Pour DBPedia, voici le service qu'on utilisait dans SemApps v1 : https://wiki.dbpedia.org/lookup
  • POur wikidata, la doc de l'API peut être utile ? https://www.wikidata.org/w/api.php

[srosset81]

Je ne crois pas que les milestones peuvent être utilisées, c'est plutôt pour des étapes globales du projet (beta, v1...)

[bouviermullerp]

++ seb. Les milestones ont caractère temporel (on peut livrer quelques issues d'un chantier dans une milestone par exemple, puis d'autres dans la suivante). @GuillaumeAV oui c'est une fonctionnalité importante ! Je te rejoins complètement, mais il y a des fonctionnalités encore plus prioritaires à ce stade (car beaucoup les demandent)

[srosset81]

J'ai mis à jour la description de cette issue, avec la liste de tous les chantiers qui ont été évoqués dans les discussions. A voir encore l'ordre des priorités, en fonction des besoins et des budgets. Pour la mise en priorité, je propose de le faire via le kanban, ce sera plus simple que d'éditer la description.

[srosset81]

Pour finir j'ai créé un autre kanban pour les chantiers. C'est expérimental, mais je pense que ça peut aider à mieux s'organiser, notamment à voir ce qui doit encore être spécifié. L'idée serait donc que les issues type "Chantier" n'apparaisse que dans le projet "Chantier", et que les issues spécifiques soient dans le tableau principal.