Atelier Développement et gestion de Logiciel Libre et Ouvert (LLO) 25 juillet 2013 Daniel Morissette dmorissette@mapgears.com
Daniel Morissette Président, Mapgears Inc Bac Génie informatique, UQAC, 1994 Dév. de logiciel libre et ouvert et membre de comités de direction: GDAL/OGR (1998+) MapServer (2000+) Démarrage et contribution à plusieurs autres projets LLO Fondation OSGeo Charter member (2006+) Board of directors (2010+) et trésorier (2011+) Chapitre local OSGeo-Québec (2008+) Prix Sol Katz en 2009 Incubateur OSGeo: 3x mentor (MapGuide Open Source, FDO, MetaCRS) chair du comité incubation en 2011
Fondations LLO
Développement / gestion de LLO Introduction Acteurs / Communauté LLO Infrastructure technique Processus de gestion Exemples d'application des processus Autres considérations Incubateur Liens utiles
Introduction
Libre ou Open Source? L' Open Source est une méthodologie de développement (motivations pratiques) Le Libre est un mouvement social (motivations éthiques) Les motivations diffèrent mais les deux groupes se rejoignent sur la solution
Qu'est-ce qu'un logiciel?
Logiciel * Image courtoisie de Master isolated images / FreeDigitalPhotos.net
Logiciel libre et ouvert Licence d'utilisation Programme Code Source Documentation
Logiciel propriétaire Licence d'utilisation Programme EXE Documentation
Les licences 11
Définition d'une licence libre Une licence libre ou ouverte doit garantir les 4 libertés suivantes: d'utiliser de copier d'étudier de modifier et redistribuer
Catégories de licences Libre ou Open Source Freeware Gratuit Utiliser Shareware Limite temporelle ou fonctionnelle Copier Propriétaire Limite selon licence d'utilisation sauf copie de sauvegarde Étudier Modifier
Licences Obligations??? L'utilisation de code Open Source dans votre application vous oblige à a) retourner vos modifications/améliorations au projet OS correspondant b) publier l'ensemble de votre code source sous la même licence c) aucune obligation de publication 14 dialog-question.png: Human-O² Icon Set (c) Olivier Scholtz and others
Licences GPL LGPL MIT/X BSD Réciproque (copyleft) Non-réciproque 15
Licences Le choix de la licence est très important. C'est une décision stratégique (vs réciprocité ou non) qui doit être faite en début de projet Avec une licence libre/ouverte, on ne cède pas sa propriété intellectuelle, on l'utilise pour rendre le code libre 16
Modèle de fonctionnement Éditeur propriétaire vs Projet LLO 17
Modèle de l'éditeur propriétaire $ $ $$ $ $ $ $ $ $ $ $$ $ $ $ $ $ Direction R&D Marketing RH... Prod. Mgr, devs, docs, QA, etc * Image courtoisie supercoloring.com
Modèle du projet LLO (Mythe) Image: Paul Ramsey, Beyond Nerds Bearing Gifts, The future of the Open Source Economy
Communauté (à la fois conepteur, gestionnaire et utilisateur) Modèle du projet LLO
Communauté (à la fois conepteur, gestionnaire et utilisateur) Modèle du projet LLO
Communauté (à la fois conepteur, gestionnaire et utilisateur) Modèle du projet LLO
Communauté (à la fois conepteur, gestionnaire et utilisateur) Modèle du projet LLO
Modèle du projet LLO Les membres de la communauté agissent à titre individuel, même s'ils sont payés par un employeur Les entreprises et organismes sont bienvenus mais n'ont pas de statut spécial au sein de la communauté, ils sont représentés par des individus La communauté d'un LLO mature a des règle de fonctionnement claires que nous allons découvrir
Acteurs / Communauté LLO
Acteurs / Communauté LLO Usagers (de débutants à power users ) Contributeurs actifs: Développeurs, architectes Rédacteurs de docs, traducteurs, graphistes, etc Autres contributeurs, testeurs (réguliers ou intermittents) Statuts spéciaux: Membres du comité de direction Committeur Les individus peuvent jouer plusieurs rôles (ex: un usager, peut être aussi contributeur et membre du comité direction) Pour qu'une communauté soit équilibrée, les individus doivent être de provenance variée (usagers et devs, entreprises et organismes multiples, etc.)
Acteurs / Communauté LLO Comité de direction Committeurs Power users Contributeurs réguliers
Acteurs / Communauté LLO Comité de direction et committeurs Deux éléments essentiels. On y reviendra plus tard Contributeurs réguliers et Power users C'est la future relève du projet, il faut les accompagner et en prendre soin! Traiter tous les usagers comme des contributeurs potentiels Un projet LLO puise sont énergie au sein de sa communauté (contributeurs, retours des usagers, financement de nouvelles idées, promotion, etc.). Une communauté active et en santé est donc un gage de viabilité d'un projet LLO.
Entretenir sa communauté Listes/forums de discussion publics: Support aux usagers Annonces Planification des révisions, suivis du développement et prise de décisions en public Site Web: À jour et contenant des références claires à la licence du projet, documentation, dernière révision stable, forums/listes de support et instructions pour contribuer Rencontres d'usagers, conférences (ex: FOSS4G) Code Sprint (excellent pour les contributeurs)
Infrastructure technique d'un projet LLO
Infrastructure technique LLO Dépot de code source Licence Site Web d'utilisation Wiki Packaging Programme Code Source Documentation Liste Forums IRC Intégration continue Suite de tests Bug tracker
Dépôt de code source Utiliser un logiciel de gestion de versions (svn, git, ou autre) C'est l'outil de travail quotidien du développeur (imaginez un menuisier sans marteau) Permet de conserver un historique des modifications, gérer la provenance du source, et de faciliter la collaboration entre développeurs et la gestion des révisions du logiciel (branches) Ne pas se limiter à la gestion du code source, mais aussi inclure la documentation, le contenu du site Web, les autres documents de projet
Site Web Le point d'entrée principal du projet, doit être convivial et maintenu à jour Parce qu'on n'a jamais une deuxième chance de faire une bonne première impression. Doit permettre de facilement retrouver: Une introduction au projet claire et concise (page d'entrée) Licence du projet Documentation et tutoriels Version stable courante (téléchargement et dépôt de code source) Options de support/communication: listes, forums, IRC, ainsi que fournisseurs de services privés ($) s'il y a lieu Instruction permettant de contribuer au projet
Wiki Site Web collaboratif Permet le développement de documents en mode collaboratif, ou de documentation préliminaire avant l'intégration dans la documentation officielle Permet aux usagers de contribuer et partager des recettes, etc. Note: souvent victime de spam
Listes, Forums, IRC Ce sont les principaux canaux de communication du projet avec sa communauté. Assurer une présence active des développeurs du projet favorisera la croissance de la communauté Favoriser la communication ouverte et respectueuse Utilisations: Support aux usagers Annonces Planification des révisions, suivis du développement et prise de décisions en public
Bug tracker Permet un suivi efficace des résolutions de bogues et autres changements au logiciel Peut être un outil autonome (ex: Trac, Bugzilla) ou faire partie d'une suite plus complète d'outils (ex: Github, Redmine, JIRA, etc.) Veiller à ce qu'il s'intègre bien avec le logiciel de gestion de versions du code source afin de permettre des références croisées entre le source et les bugs
Suite de tests Utiliser un outil de gestion de tests automatisé en fonction du langage de programmation et de l'environnement de développement Permet d'assurer l'intégrité de l'application suite aux changements des committeurs Rassure les développeurs en leur permettant de valider rapidement et proactivement que leurs changements n'introduisent pas d'effets de bords ailleurs dans le logiciel Peut être combiné à un outil d'analyse du taux de couverture du code source par les tests Ex: MapServer utilise les outils gcov et lcov, voir https://github.com/mapserver/coverage
Intégration continue Exécute la suite de tests automatiquement à chaque commit ou pull request et rapporte les échecs immédiatement via courriel, IRC ou autre Assure l'intégrité du code source en tout temps Ex: MapServer utilise Travis CI, voir https://travis-ci.org/tbonfort/mapserver/
Packaging Pour faciliter l'adoption et l'installation du logiciel Parce que les usagers n'ont pas tous la capacité (ou le désir) de compiler du code source Peut prendre différentes formes selon le type de logiciel et les plateformes supportées. Ex: Installeur Windows ou OSX Paquets sous Linux (deb, rpm, etc.) Paquet binaire à télécharger (.zip ou.tar.gz) Paquet de code source (JavaScript, Python, etc.)
Processus de gestion d'un projet LLO
Processus de gestion LLO Gouvernance Mécanisme de décision Comité de direction Statut de committeur Gestion des changement (RFC) Gestion des révisions Processus/cycle de publication de révisions Branchement du code source Entente de contribution ( Contributor Agreement ) Convention de codage / Committer Guidelines
Mécanismes de décision
Mécanisme de décision En priorité: Discussion ouverte et recherche de consensus Utiliser la liste publique en tout temps (sauf cas extrêmes exigeant confidentialité) Dans 99% des cas, le vote sert seulement à confirmer le consensus et officialiser la décision Mécanisme de vote: +1, 0, -1 Voir RFC 23 MapServer: http://mapserver.org/development/rfc/ms-rfc-23.htm
Mécanisme de vote Chaque membre du comité a droit à un vote Les motions et votes se font en public sur la liste de discussion (ex: mapserver-dev) Le vote est habituellement ouvert pour 2 jours ouvrables sauf exception Vote +1, 0, -1: +1: Je suis d'accord et m'engage à supporter cette décision et collaborer à sa réalisation 0: Abstention, sans effet (aussi sans effet: -0 légèrement en désaccort et +0 légèrement d'accord mais avec des doutes) -1: Objection, veto, doit fournir une avenue de solution alternative
Mécanisme de vote Une proposition est acceptée si elle reçoit au moins +2 (incluant l'auteur) et aucun veto (-1) Si une propostion reçoit un veto (-1) et qu'il est impossible de satisfaire toutes les parties après révision et discussion: La proposition peut être soumise pour un second vote ultime Dans ce cas un vote +1 de la majorité absolue de tous les membres du comité est requis pour que la proposition soit acceptée (et non pas seulement la majorité des votes soumis) Le résultat du vote est compilé et publié par son auteur et archivé sur la liste de discussion et dans les documents associés s'il y a lieu (RFC)
Comité de direction
Comité de direction Autorité ultime du projet Gestion de tous les aspects du projet Processus de décision (consensus + vote) Provenance des membres variée et équilibrée Usagers vs contributeurs Éviter qu'un seul organisme ou entreprise domine le comité Viser 5 ou 7 membres au démarrage pour un bon équilibre et permettre l'expansion (le PSC de MapServer a aujourd'hui 14 membres) Président ( chair ) élu parmi les membres du comité Voir MapServer RFC 23: http://mapserver.org/development/rfc/ms-rfc-23.html
Comité de direction Responsabilités: Conventions et politiques de travail du projet Vision générale du produit ( roadmap ) Coordonner la publication de révisions régulières du logiciel Réviser et approuver les demandes de changement (RFC) Gestion de l'infrastructure du projet (git/svn, site web, etc) Relation avec la fondation OSGeo Définir les priorités du projet Création et supervision de sous-comités au besoin Etc.
Comité de direction Élection de nouveaux membres Au besoin, ou lorsqu'on bon candidat se démarque, il peut être nominé et élu par motion et vote +1 de la majorité absolue des membres existants Démission, renvoi: Un membre peut démissionner en tout temps Un membre inactif pour plus de 2 mois (aucune participation aux votes, réunions et autres activités du comité) peut être remplacé par vote des autres membres du comité
Statut de Committeur
Statut de committeur Privilège: Permission de contribuer au dépôt de code source directement Responsabilités: s'assurer de l'intégrité des contributions (provenance, propriété intellectuelle, brevets, licence, etc.) supporter ses contributions de façon raisonnable (bugs, etc.) respecter les règles d'engagement (RFC 7.1) signer et respecter l'entente de contribution
Statut de committeur Le comité de direction du projet, en tant qu'autorité ultime, vote et approuve l'élection de nouveaux committeurs et gère/active les droits dans le dépôt de code source (git, svn, etc.) Un committeur inactif ou qui ne respecte pas les règles d'engagement peut se faire révoquer son titre/droit de committeur
Statut de committeur Comment y accéder? Commencer par contribuer régulièrement des patch via le bug tracker Un/des committeurs vont réviser et endosser ces patch pour inclusion officielle dans le logiciel Répéter jusqu'à ce que vous ayez gagné la confiance des autres committeurs Confirmer votre désir de devenir committeur et de respecter les règles d'engagement À ce moment une motion sera faite au comité de direction du projet qui passera au vote afin de vous attribuer le titre de committeur Comment gagner la confiance des autres committeurs? Bonne compréhension de l'architecture, des outils et méthodes de fonctionnement du projet Code de qualité Aptitudes de communication Intention de rester actif à moyen-long terme
Gestion des changements (RFC)
Gestion des changements Processus de RFC: Discussions préliminaires sur la liste -dev Production d'un document RFC (qui, quand, quoi, pourquoi, comment, incompatibilités, etc) Discussion du RFC Vote du comité de direction Implémentation, documentation, etc. Liste des RFCs disponible sur le site Web
Gestion des révisions
Gestion des révisions Exemple de MapServer, voir RFC-34 http://mapserver.org/development/rfc/ms-rfc-34.html Dépot d'un Release plan Rôle de release manager Cycle de révisions Cycle de +/- 6 mois entre les révisions Dév. -> Rel. Plan -> Feature freeze -> betas -> RC -> release
Gestion des révisions Numérotage des révisions (MapServer) Version = x.y.z (majeur.mineur.patch) Mineur paire = stable (ex: 5.4, 5.6) Mineur impaire = développement (ex: 5.5) Patch = résolutions bogues seul. = 5.4.1, 5.4.2, etc. Voir aussi semantic versioning http://semver.org/
Branchement du code source Multiples stratégies possibles Exemple: http://www.liquibase.org/development/branches.html
Règles d'engagement du committeur
Entente de contribution Vise à protéger l'intégrité du code source du logiciel contre les contributions illégitimes, accidentelles ou non, et leurs conséquences Engagement légal du committeur envers le projet, confirmant qu'il a le droit de contribuer sa PI au projet Doit être signée par tous les committeurs ou contributeurs réguliers Peut ou non inclure un transfert de droit d'auteur Selon les cas, une entente individuelle et corporative peuvent être requises (si l'employeur possède les droits sur le travail de l'employé) Voir: http://wiki.osgeo.org/wiki/contributor_agreement
Convention de codage et Committer guidelines Visent l'uniformité du code et des méthodes de travail À respecter par le committeur Voir MapServer RFC 7.1 http://mapserver.org/development/rfc/ms-rfc-7.1.html
Exemples d'application des processus
Mise en place d'un comité de direction
Mise en place d'un comité de direction Nombre de membres idéal au démarrage: 5 ou 7 membres Identifier une liste de candidats potentiels: Le premier candidat est le fondateur du projet, évidemment Regarder parmi les power users et les contributeurs actuels ou contributeurs potentiels à court terme En provenance de multiples organismes et entreprises Représentation diversifiée de tous les acteurs du milieu (instutitionnel, privé, éducation, usagers, développeurs, rédacteurs de docs, multiples régions géographiques, etc.) Pas besoin d'être programmeur, mais un minimum de connaissances techniques et/ou du domaine d'affaires est requise Les candidats doivent avoir le projet à coeur (les raisons peuvent varier) et la volonté d'y mettre un peu de temps
Mise en place d'un comité de direction Communiquer avec chacun des candidats pour Partager vos intentions de publier votre projet en LLO Sonder et confirmer leur intérêt de participer au comité de direction Les inviter à une rencontre de pré-démarrage
Mise en place d'un comité de direction Planifier la rencontre de pré-démarrage Se préparer à expliquer les principes de gestion LLO si les candidats ne les connaissent pas déjà Préparer une ébauche de règles d'opération du comité pour base de discussion (s'inspirer d'un autre projet mature, ex: MapServer) Infrastructure LLO: on peut préparer une ébauche, mais se rappeler que ce sera une des premières tâches du comité de direction de régler ces détails Se préparer mentalement au fait qu'à partir du début de cette rencontre on n'est plus le seul maître et on doit viser des consensus forts si on veut former un comité fort. Bref, rien dans votre ébauche de comité n'est coulé dans le béton, tous les points sont à discuter avec les candidats invités
Mise en place d'un comité de direction Rencontre de pré-démarrage ordre du jour Mot de bienvenue, mise en situation Tour de table, présentation des candidats invités Présentation du projet LLO et de vos intentions Rappeler l'intention de passer les pouvoirs au comité de direction Rappeler que tout est sujet à discussion et consensus Présentation des principes de gestion LLO (s'il y a lieu) Présentation et discussion de l'ébauche de règles d'opération Formation officielle du comité Tous les candidats ont l'option d'embarquer ou non La formation officielle pourrait être reportée à une autre rencontre si du travail reste à faire ou des candidats veulent une période de réflexion Élire un président parmi les membres Convenir de la date de début des activités / passation des pouvoirs
Mise en place d'un comité de direction Rencontres de pré-démarrages multiples si nécessaire Exécution des décisions Compiler la version finale des règles d'opération du comité de direction Compiler la liste finale des membres du comité Partager le tout avec les membres pour approbation Planifier le début des activités du comité selon ce qui a été convenu lors de la rencontre
Mise en place d'un comité de direction Première réunion du comité Démarrage officiel Passation des pouvoirs du fondateur vers le comité Décisions face à l'infrastructure de projet LLO Publication des minutes des réunions sur le site Web si elles ont lieu face à face Confirmer/diffuser les décisions du comité sur la liste de discussions pour le bénéfice de la communauté
Mise en place d'un comité de direction Et voilà! Longue vie au projet et à son comité! Dans les premiers temps le comité devra mettre en place tous les éléments requis par le projet LLO Défi d'adaptation à un environnement distribué: éviter les réunions face à face puisqu'elles sont en contradiction du principe d'implication active de la communauté dans le projet favoriser les échanges par courriel sur la liste de discussions du projet ou les réunions virtuelles permettant à tous les membres du comité de participer facilement et aux intéressés dans la communauté de participer en tant qu'observateur Les réunions IRC fonctionnent bien pour OSGeo
Ajout d'une fonctionnalité au logiciel
Ajout d'une fonctionnalité au logiciel Un usager exprime un besoin Un développeur accepte de le prendre en charge (pour des raisons $$, altruistes ou autre) Le besoin et les solutions possibles sont discutés sur la liste de discussion -dev afin de valider les solutions potentielles et la réceptivité des autres développeurs à cet ajout Le développeur écrit un RFC (1 à 3 pages) décrivant le besoin, la nouvelle fonctionnalité, la solution proposée et les détails d'implémentation, les impacts potentiels, des exemples d'utilisation, etc
Ajout d'une fonctionnalité au logiciel Le RFC est soumis pour discussion au comité de direction pour une période de 2 à 5 jours ouvrables Des ajustements sont faits en fonction des commentaires Le comité de direction passe au vote pour adoption du RFC Si le RFC est adopté, le développeur peut procéder, sinon il retourne à la table à dessin (ou choisit d'abandonner le projet)
Ajout d'une fonctionnalité au logiciel Le développeur implémente la nouvelle fonctionnalité tel que décrit dans le RFC Code source Tests Documentation S'il est committeur, il peut faire le commit une fois terminé Sinon il doit soumettre une patch via le bug tracker (ou un pull request avec Github) et espérer qu'un committeur veuille bien réviser/endosser son code et le committer pour lui La nouvelle fonctionnalité est maintenant dans le dépôt de code source, en attente de la prochaine révision officielle du logiciel
Production d'une révision de logiciel
Production d'une révision de logiciel Le temps est venu de publier une nouvelle release du logiciel Un Release Plan est publié Un Release manager est nommé pour cette révision Date de Feature Freeze Date de release prévue Liste des fonctionnalités majeures incluses Le comité de direction vote pour accepter le release plan Le processus de release est enclanché
Production d'une révision de logiciel Release Manager Responsable de l'exécution du release plan Coordination et respect des échéanciers Rappel et respect du feature freeze Paquetage et annonce des beta et révisions finales Autorité ultime en cas de doute/conflit sur l'admissibilité de certains changements dans la révision Responsable des patch release pour les mois suivant la révision finale
Production d'une révision de logiciel Feature Freeze Date à partir de laquelle aucun changement majeur au code source n'est permis On tombe en mode stabilisation du code source Résolution de bogues seulement Marque le début des betas menant à la révision finale
Production d'une révision de logiciel Multiples betas De multiples betas sont publiés espacés de 1-2 semaines afin de permettre aux usagers de tester 4-5 betas habituellement sur une période de 6 a 8 semaines Lorsque le niveau de stabilité voulu est atteint on produit un Release Candidate Si aucun bogue majeur dans le Release Candidate il devient la révision finale officielle Sinon on produit un nouveau RC jusqu'à ce qu'on ait el bon
Production d'une révision de logiciel Révision finale (tâches du Release manager ): Paquetage du code source Publication du code source sur le site de téléchargements Publication d'une annonce à la communauté Mise à jour du site Web pour refléter la nouvelle révision Création d'une branche stable dans le dépot de code source. Le Feature Freeze est levé, les développements peuvent reprendre dans le tronc principal du dépôt de code source En parallèle, les producteurs de distributions binaires s'activent et publient des exécutables de la nouvelle révision
Autres considérations
Convertir un projet interne en LLO? Une décision importante Avantages Attirer de nouveaux usagers et surtout contributeurs pour une croissance accrue du logiciel (coopérer avec d'autres experts à travers le monde au lieu de compétitionner avec eux) Bénéficier du retour de la communauté (nouvelles fonctionnalités, bug fix, tests, docs, etc.) Augmenter la viabilité long terme du logiciel ( bus number, survie au départ du créateur original) Désavantages Perte de contrôle partielle du créateur original sur le projet (le comité de direction prend le contrôle) Perte potentielle d'un avantage compétitif?
Convertir un projet interne en LLO? Une décision importante Questions importantes A-t-on la capacité d'attirer une communauté suffisamment grande pour générer un retour significatif? Comment financer nos activités de support du projet LLO? Est-on prêts à jouer le jeu et accepter la perte de contrôle partielle sur la vision et direction du projet? Est-on prêts à travailler en mode distribué (pourrait demander une adaptation si l'équipe était 100% locale auparavant) Choix de licence stratégique Réciproque (GPL, etc.): assure que le code demeure libre mais risque de faire reculer certains utilisateurs / contributeurs potentiels (ex: revendeurs de produit à valeur ajoutée) Non-réciproque (MIT, BSD, Apache) moins contraignant, plus propice à l'usage commercial ou par des revendeurs propriétaires
Autres considérations Possibilité d'un Fork Gestion par comité vs benevolent dictator Révisions de sécurité Fournisseurs de services ($) Support technique professionnel Formation Développement de fonctionnalités
Incubateur de LLO
Incubateur Voir incubateur OSGeo: http://www.osgeo.org/incubator/ Objectif: Vérifier l'intégrité et la viabilité long terme d'un projet LLO avant son admission dans la fondation Règles d'admission dans l'incubateur Formulaire d'application Mentor Licence ouverte approuvée par l'osi Potentiel de graduation Règles de graduation de l'incubateur (voir checklist ) Aspect légal Communauté active et équilibrée Gestion ouverte Développement ouvert
Incubateur Critères de graduation ( Checklist ) Aspect légal: Licence ouverte approuvée par l'osi (opensource.org) Validation de la provenance du code source Ententes de contribution, signée par tous les committeurs Communauté active et équilibrée Communauté active et équilibrée d'usagers et contributeurs (subjectif, signe de viabilité long terme) Mécanismes de communication ouverts en utilisation (site Web, listes, forums) Gestion ouverte Mécanisme de gestion et de décision ouverts et documentés Comité de direction Statut de comitteur Mécanisme ouvert d'ajout de membres au comité de direction et committeurs Développement ouvert Méthodes de développement ouvertes et documentées Infrastructure LLO minimale (Dépot code source, site Web, bug tracker, liste discussion) Gestion des changements (RFC) Processus de révision Convention de codage / committer guidelines
Comité d'incubation (ex: OSGeo) Gestion de l'incubateur: Responsable de l'admission des projets dans l'incubateur Responsable de l'évaluation avant graduation Responsable de la mise à jour et évolution des règles de graduation lorsque nécessaire Règles d'opérations du comité simiaires au comité de direction d'un projet LLO Les membres du comité sont des anciens mentors ou mentors potentiels (expérience requise)
Comité d'incubation (ex: OSGeo) Processus d'incubation type: Un projet applique auprès de l'incubateur (formulaire d'application) Comité incubation évalue la demande et vote Si admis, alors le mentor assiste le projet pour évaluer et faire les ajustements nécessaires pour rencontrer tous les critères de graduation (le mentor ne fait pas le travail, il est seulement un guide, ce sont les membres du projet qui font le travail) Un rapoort d'avancement est tenu à jour pour suivre le progrès (wiki) Lorsque le mentor juge que le projet a rempli tous les critères, il soumet une motion au comité incubation pour proposer la graduation du projet Les membres du comité incubation ont une semaine pour réviser le rapport de progrès Des ajustements sont habituellements proposés pendant la période d'évaluation Une fois tous les commentaires adressés, le comité passe au vote Si le vote est positif, le projet est gradué t. Une recommandation d'admission officielle est transmise au CA ( board ) de la fondation Si le vote est négatif, alors le projet doit faire les correctifs nécessaires et revenir pour une nouvelle demande de graduation plus tard
Liens utiles
Liens utiles Producing Open Source Software http://producingoss.com/ How to maintain a successful open source project https://medium.com/p/aaa2a5437d3a Règles d'opération du comité de direction MapServer (RFC 23): http://mapserver.org/development/rfc/ms-rfc-23.html Règles d'engagement des committeurs MapServer (RFC 7.1): http://mapserver.org/development/rfc/ms-rfc-7.1.html Processus de gestion de révisions de MapServer (RFC 34) http://mapserver.org/development/rfc/ms-rfc-34.html Semantic Versioning http://semver.org/ Ententes de contribution OSGeo: http://wiki.osgeo.org/wiki/contributor_agreement Incubateur OSGeo http://www.osgeo.org/incubator/ http://www.osgeo.org/incubator/process/project_graduation_checklist.html