J’ouvre ce sujet car je ne me pose pas mal de questions sur comment aider toutes les idées qui émergent dans le cadre de Fédération pour leur donner la meilleure chance de devenir des projets collaboratifs concrets.
La première question sur laquelle je me casse les dents est « Qu’est-ce qu’un projet spatial Fédération ?».
Ce n’est pas le développement du projet avec ses résultats qui m’intéressent ici mais plutôt la phase de passage du stade d’idée à celui de projet (phase de démarrage projet ci-dessous)
L’enjeu est de structurer à minima les idées pour que ceux qui les portent puissent trouver de l’aide pour les développer.
Placer le couseur entre « incubation de l’idée » et « démarrage du projet » n’est pas facile dans le cadre de Fédération. D’une part, une technicité et une structuration initiale exacerbées pourraient exclure le plus grand nombre du passage de l’idée au projet, d’autre part un contenu trop flou et trop peu structuré empêcherait la collaboration et l’aide de la communauté.
Donc quel est le contenu minimal à publier qui marque le passage de la phase d’incubation de l’idée à celle de démarrage d’un projet collaboratif ?
Une première proposition pourrait être cela :
Description du projet ( pourquoi contribuer ? ) : présenter clairement le projet, ses motivations. Donner des premières spécifications.
Organigramme technique ou fonctionnel ( sur quelle partie je peux contribuer ?) : donner une décomposition du « système » et des « sous-systèmes » (pour chaque partie en développement des sous projets peuvent être créés)
Road-map avec les principaux jalons ( à quel moment je peux participer ?) : la notion de durée est d’autant plus importante dans un projet amateur. Les jalons pourraient être des dates auxquelles on publie la documentation open source.
A partir de ces éléments la collaboration devrait être plus simple et les équipes projet devraient pouvoir commencer à s’organiser pour mener le développement.
J’ajouterais dans la partie Description du projet une explication de ce qu’apporterait le projet par rapport à l’état de l’art, et au moins le résumé d’une recherche rapide sur ce qui existe déjà de similaire en open source.
Nous avons évoqué ce sujet lors de la conférence téléphonique de lundi dernier, et convenu qu’on se laissait 15 jours pour converger sur les éléments nécessaires pour passer d’une idée de projet à un projet (donc on valide cela lors du call du 15/4).
C’est en relation avec le sujet: « réinventer la roue en open-source » mais mois moi le but d’un projet Open-source n’est pas d’apporter quoi ce soit par rapport à l’Etat de l’art mais au contraire de rendre les choses plus simple et libre d’accès et de reproduction. De plus je reste persuadé que les motivations de la plupart d’entre-nous n’est pas de faire « mieux » ou « nouveau » mais d’essayer, comprendre voir si on peut faire différent
Lors de notre dernière confcall bi-hebdo des membres actifs, nous avons tranché en faveur de l’utilisation de la base proposée par Fabio très légèrement modifiée pour guider le passage de “l’idée de projet” (un thread sur le forum) au “pré-projet” (lancement d’un espace dédié dans la page projet).
Cela donne donc :
Description du projet (pourquoi contribuer ?) : présenter clairement le projet, ses motivations. Donner des premières spécifications. Résumer une recherche rapide sur ce qui existe déjà de similaire en open source
Organigramme technique ou fonctionnel (sur quelle partie je peux contribuer ?) : donner une décomposition du « système » et des « sous-systèmes » (pour chaque partie en développement des sous projets peuvent être créés)
Road-map avec les principaux jalons (à quel moment je peux participer ?) : la notion de durée est d’autant plus importante dans un projet amateur. Les jalons pourraient être des dates auxquelles on publie la documentation open source.
C’est maintenant ajouté sur la page “Démarrer”, je vais aussi l’ajouter dans le nouveau “tunnel de création de projet” apporté par la 1.1.0.
En pratique pour la mise en oeuvre pour la suite : d’un côté, nous allons indiquer ces éléments comme étant le minimum nécessaire à avoir figé et affiché sur la page vitrine d’un nouveau projet avant qu’il soit passé de “brouillon” à “publié” par les administrateurs.
Nous allons aussi revenir vers chacune des équipes projets actuelles en leur demandant de compléter le cas échéant leur page vitrine, et devrions laisser pour cela un délai de 1 à 2 mois avant de repasser ces projets au statut “brouillon”.
Tout cela dans l’objectif d’aider les projets à se structurer, tout en améliorant la qualité du contenu de la “vitrine” représentée par les différents projets en cours sur la plateforme.
