Skip to content

Brouillon - Guide des contributions (AMUE)

Remarque :

Brouillon d'un guide des contributions au logiciel DS pour l'AMUE et les ESRs. C'est basé sur les premiers échanges entre l'AMUE, l'Université de Tours, l'Adullact et l'équipe DS de la DINUM, avec quelques ajouts qui me semblaient important.

Ouvert à commentaire (correctif, amélioration, remarque, ...).
Ping @mfaure @davidrongeat @krichtof

Vocabulaire

  • DS = Logiciel "Démarches Simplifiées"
  • L'équipe DS = l'équipe de la DINUM en charge du développement du logiciel DS et la gestion de l'instance DS de l'état (DS.fr).
  • Instance DS de l'Adullact = service "Démarches Simplifiées" utilisant le logiciel DS

Principes

  • "No fork" : les nouvelles fonctionnalités doivent être développées pour être intégré dans le code source du logiciel DS et une phase d'échange avec l'équipe DS sera certainement nécessaire en amont du code.
  • Le temps de l'équipe DS est précieux et l'objectif est de ne pas surcharger l'équipe DS qui a sa propre roadmap.
  • L'AMUE et l'ADULLACT centralise et relaye les demandes d’évolutions pour les ESRs. TODO à compléter...

Bugs

Bug sur l'instance DS de l'Adullact

Si vous êtes un utilisateur (usager, expert, instructeur et administrateur) :
pour un bug sur l'instance DS de l'Adullact contacter l'AMUE.

Si vous êtes un développeur : pour un bug sur l'instance DS de l'Adullact,
mais non présent dans la dernière version du logiciel DS, contacter l'AMUE.

Bug sur logiciel DS

Si vous êtes un développeur, pour un bug présent dans la dernière version du logiciel DS, vous pouvez suivre le processus suivant sur le dépôt Github du logiciel DS :

  • vérifier si le bug n'est pas déjà décrit ;
  • si ce n'est pas le cas, ouvrir un ticket en précisant bien le contexte, le dysfonctionnement et le comportement attendu.
  • si vous pensez pouvoir créer un correctif, consulter en amont les bonnes pratiques de développement du logiciel DS.

Pour l'inspiration, exemples de tickets :

Nouvelles fonctionnalités

Pour de nouvelles fonctionnalités, nous vous invitons à suivre processus suivant :

  1. Contacter l'AMUE en premier qui centralise et relaye les demandes d’évolutions du service auprès de l’Adullact et de la Dinum pour vérifier :
    • si c'est une fonctionnalité existante et activée sur l'instance de l'Adullact ?
    • si il existe des solutions alternatives ?
    • si c'est une fonctionnalité en cours de développement ?
    • si il faut documenter ce besoin ? si oui, passer à l'étape 2 !
  2. Créer un ticket dans ce dépôt pour décrire le besoin. (Exemple #4 (moved))
    • contexte et résumé du besoin
    • éventuellement rédiger les "user stories" (les besoins du point de vue des utilisateurs)
    • éventuellement rédiger les "tests d'acceptation" (le descriptif des fonctionnements attendus)
  3. Solliciter un échange avec l'AMUE et Adullact pour vérifier ensemble les points suivants :
    • si c'est une fonctionnalité existante et activée sur l'instance de l'Adullact ?
    • si il existe des solutions alternatives ?
    • si c'est une fonctionnalité en cours de développement ?
    • si c'est une fonctionnalité qui ne sera jamais implémentée dans DS ?
    • si c'est une fonctionnalité intéressante mais non planifiée par l'équipe DS ?
    • si il faut affiner l'analyse du besoin avant d'en parler à l'équipe DS ?
    • si il faut demander à l'équipe DS si c'est pertinent, possible techniquement et acceptable ?
  4. Définir les prochaines étapes avec l'AMUE et Adullact :
    • rédiger ou affiner les "user stories" (les besoins du point de vue des utilisateurs)
    • rédiger ou affiner les "tests d'acceptation" (le descriptif des fonctionnements
    • planifier un échange avec l'équipe DS
    • ...

Bonnes pratiques de développement

Ressources :

TODO à compléter...

Guide de démarrage pour les développeurs

Ressources :

TODO à compléter...

Edited by Fabrice Gangler