Devenez partenaire Principal ou Majeur de Neogia

• Accueil
• Fonctionnalités
  • Acteurs
  • Articles
  • GRC (CRM - SFA)
  • Vente/Achat (Expéd. Récept.)
  • Terminal point de vente
  • Stock
  • Production
  • Qualité
  • Prestation de Service
  • Finance/Comptabilité
  • eCommerce
  • Business Intelligence
• Documentation
  • Menu principal
  • Doc. Fonctionelles
  • Architecture
  • Doc. Techniques
  • Doc. développeur
  • Doc. contributeur
  • Doc. du projet
  • Doc. administrateur
• Téléchargement
• Démo. en ligne
• Qui sommes nous
• Plan du site

Développer de nouvelles fonctionnalités

Règles et processus pour les contributions

1. avoir un compte utilisateur et être déclaré sur le projet Neogia sur Sourceforge, pour être capable de voir et de déclarer toutes les tâches qui seront réalisées par la communauté (et vous ;-) dans le FeatureRequest tracker, autrement appelé le "gestionnaire..."
2. déclarer une tâche (ou un ensemble de tâches) dans sourceforge pour chacune des réalisations souhaitées (une tâche pour des réalisations de 1-3 jours)
3. pour des tâches plus longues (supérieures à 5 jours), ajouter une page au wiki en utilisant le modèle de spécification ; dans cette page, seront détaillés l'analyse et le plan de la réalisation (cette règle est mise en place depuis mai 2006)
4. pour une modification UML : pour le moment il faut une licence Poseidon (version communauté), il n'est pas possible de gérer des modifications concurrentes
   1. toutes les modifications UML devront être effectuées dans la branche "head" ; pour les modifications importantes, elles devront d'abord être soumises au mainteneur du composant pour être acceptées.
   2. toutes les modifications UML devront être faites dans la dernière version cvs ; il n'est pas possible de fusionner les diagrammes UML et nous n'intégrons jamais des codes générés ; la génération est toujours effectuée à partir des dernières versions des générateurs et des diagrammes UML
   3. après chacune des modifications UML (nouvelle entité, nouvel attribut ou diagramme mais pas de nouvelle balise ;-), il est nécessaire de mettre à jour le wiki Néogia, en y mettant la documentation s'y rapportant (cette règle est mise en place depuis mai 2006)
   4. après chaque modification UML, il faut regénérer en effectuant un commit approprié dans la version "head"
5. avoir un compte utilisateur sur labs.libre-entreprise.org, être déclaré sur le projet Néogia, mettre sa clé publique ssh dans son profil afin d'avoir l'accès pour commiter sur cvs
6. juste avant de commencer le codage, se mettre à jours avec le cvs sur Head, afin d'être sûr d'avoir la dernière modification UML
7. une fois la tâche terminée :
   1. faire une synchronisation cvs, pour gérer d'éventuel conflit avec les dernier commit
   2. faire un test selenium qui vérifiera et validera la tâche ; ce test est très utile à la personne qui validera la tâche car cela lui permettra de voir ce qui a été fait et à quel niveau (cette règle est établie depuis mai 2006 ; elle s'avère être très efficace)
   3. générer un patch (il inclura le selenium)
   4. relire et faire des corrections, si nécessaire, dans la page de spécifications écrire précédement
   5. écrire la documentaiton fonctionnelle (entre 1 et 3 lignes pour une petite tâche)
   6. modifier la description de la tâche à ajouter [TBT] (To Be Tested)
   7. joindre le patch à la tache
   8. si vous avez échangé avec le mainteneur durant la phase d'analyse, vous pourrez lui demander quand il sera en mesure de valider votre tâche dans "head"
8. si vous avez des impératifs de délai, il faut demander à l'organisation neogia une prestation de mainteneur, dans ce cas le delai sera garantie. On compte habituellement de l'ordre de 20% du temps de réalisation.