Si vous lisez ce fichier, c'est que vous pensez pouvoir nous aider d’une manière ou d’une autre, et nous vous en remercions d'ores et déjà ! :)
Notre objectif est évidemment d’élargir l’étendue des cotisations calculées. Pour dépasser la limite de nos ressources, nous cherchons à ouvrir au maximum cet outil à la contribution. Ainsi, tout le code du moteur de calcul comme de l’interface utilisateur est sous licence libre, et toute forme de contribution peut aider à l’intégration de nouvelles cotisations : recherche législative préalable et rédaction des règles à implémenter, ajout de tests pour valider le calcul de prestations…
Pour suggérer l'ajout de cotisations ou statuts supplémentaires, créez une issue pour chacune d'entre elles, avec la référence la plus officielle possible vers le descriptif de la cotisation. Nous cherchons les conditions d'application et les modalités de calcul.
Pour faciliter le suivi des demandes, chaque cotisation demandée est représentée par une issue identifiée par le tag « nouvelle cotisation », afin que toute personne se sentant concernée puisse appuyer la demande, et en suivre l'évolution.
Par souci de lisibilité pour les partenaires, notamment administratifs, la langue utilisée pour la description et le suivi de fonctionnalités est le français.
En revanche, pour éviter le coût du changement de contexte, les discussions techniques peuvent se faire en anglais, la langue la plus utilisée dans le cadre du développement logiciel.
Toutes les évolutions de l'outil, espérées, planifiées ou réalisées, sont représentées par des issues GitHub. L'ensemble des issues sur tous les dépôts composant les différents modules de l'application simulateur de coût d'embauche est donc la seule source de vérité sur ses évolutions.
L'état d'avancement de la fonctionnalité représentée par l'issue est donné par un tag.
Pour faciliter la lecture du processus et regrouper les issues ouvertes sur tous les différents dépôts, nous utilisons Waffle.
Le passage d'une étape du processus est rendu possible par la validation des conditions suivantes.
Décision informelle sur la base de l'analyse des besoins des usagers, des partenaires, des opportunités et contraintes techniques.
- Validation de la définition de l'issue par le demandeur.
- Validation de la définition de l'issue par l'équipe technique.
- Création d'un test invalide (selon la modalité la plus indiquée : unitaire pour l'API, via Ludwig pour une cotisation, d'intégration pour l'interface…).
- Passage du (ou des) test(s) associé(s) à la définition.
- Aucune régression n'est détectée par les tests.
- Pour les forks de dépôts externes (notamment OpenFisca), une pull request proposant nos modifications a été ouverte.
- Une revue de code a été faite sur les modifications.
- Aucune régression n'est détectée sur les tests applicables en production (Ludwig, tests d'intégration).
- Si la fonctionnalité touche les utilisateurs, une release, et potentiellement un tweet, l'ont annoncée.
Cette application utilise du JavaScript Vanilla.