Re: [Qsos-french] Forges

[Raphael Semeteys]

Le problème c'est qu'avec une domaine comme les forges logicielles, intégrer 
les grilles de chacun des composants risque d'amener à une grille finale de 
300 à 400 critères, impossible à évaluer rapisement et simplement.

Si on part de l'exemple du wiki :
- une grille wiki très détaillée existe en tant que telle et permet d'évaluer 
des solution de wiki à part entière comme Mediawiki
- un include wiki existe en parallèle mais reste d'assez haut niveau avec un  
plus faible nombre de critères pour pouvoir être intégré à une grille plus 
grande. Ce type d'include nécessite pratiquement toujours un niveau de détail 
moins fin.

La notion d'includedomain me gêne car on perd la section générique qui est 
très liée à un projet en particulier.

On Wednesday 21 February 2007 13:56, Goneri Le Bouder wrote:
> Le 21/2/2007, "Nicolas Vérité" <address@hidden> a écrit:
> >Salut,
>
> Bonjour Nicolas,
>
> >J'ai un peu bossé sur la structuration de 1er et 2nd niveau
> >de l'arbe des critères fonctionnels des forges :
> >http://qsos.org/wiki/index.php/Forges
> >J'ai tenté de bien ventiler/répartir les critères.
> >
> >==
> >
> >Services trans-projets
> >    * Mécanisme d'authentification et de gestion des droits
> >          o Rôles (« RBAC »)
> >          o LDAP (User/Group/...)
> >          o Base de données
>
> c'est générique, ça devrait être un .qin
>
> >    * Personnalisation
> >          o Globale
> >          o Par projet
> >          o Par utilisateur (« My Forge »)
> >    * Notifications (intégration avec la messagerie)
> >          o E-mail
> >          o Jabber
> >          o Web
>
> idem
>
> >    * Intégration des différents modules
> >          o Intégration avec outils clients
>
> Tu penses a quoi comme outils ?
>
> >          o Références croisées
> >    * Aspects techniques
> >          o Export et import de données
> >          o Sauvegarde et restauration
> >          o Respect des standards, protocoles et formats ouverts
> >          o Haute disponibilité et montée en charge
>
> Je pense que la haute dispo ne devrait pas être là et il faudrait
> renommer la section en 'Accès aux données'
>
> >    * Méta-données
> >          o Arbre de projets (« Trove Map »)
> >          o Fonctions de recherche
> >          o Statistiques globales et rapports
> >          o Syndication RSS/Atom
>
> Pourquoi pas faire un .qin spécifique aux notifications (mail, jabber,
> pubsub, rss/atom)
>
> >          o Résumé du projet
> >    * Chiffrement
> >
> >Gestion de code source
> >    * Gestion des versions (« Source Code Management »)
> >          o Accès anonyme
> >          o Atomicité
> >          o Branches
> >    * Visualisation des différences (« diff »)
>
>        - coloration syntaxique
>        - restauration du fichier depuis une version ancienne
>        - possibilité de faire un diff entre deux versions du fichier
>
> >    * Gestion de patches
>
> Tu penses a quoi précisement ? A mon avis, ça devrait d'avantage être
> dans le domaine revision-control-system.
>
> >    * Outils de test et de contrôle de la qualité du code (type «
> >Checkstyle », « Jalopy », etc.)
>
> oui, mais il faut juste évaluer si la connexion est possible. Ces outils
> doivent faire l'objet d'un template particulier.
>
> >    * Réplication et synchronisation
>
>         - référenciels
>         - base de données
>         - miroirs
>
> >Gestion Projet
> >    * Statistiques et rapports
> >    * Gestion de tâches
> >    * Suivi temporel
> >    * Diagrammes de Gantt
>
> Je suis un peu perplexe car cela devrait être dans une fiche 'gestion de
> projet'. Il faudrait juste évaluer le degré d'intégration.
>
> >Mise à disposition de paquets (« File Release System »)
> >    * Téléchargement
> >    * Versionning
> >    * Dépendances
> >
> >Gestion de documents
> >    * Mise à disposition simple
> >    * Avec flux d'approbation (gestion du cycle de vie)
> >    * Formats ouverts
> >    * Classification (tag, arbre, etc.)
> >    * Gestion de versions
> >    * Workflow
>
> Là tu devrais regarder du côté 'cms' et pareil évaluer l'intégration.
>
> >Gestion d'anomalies et de demandes
> >    * Personnalisation des états
> >    * Personnalisation des champs
> >    * Workflow
> >    * Assignation et changement de propriétaire
> >    * Liaisons entre tickets
> >    * Historisation
> >    * Pièces jointes
> >    * Liaisons entre tickets
>
> Là c'est le domaine 'ticketing' :).
>
> >Outils collaboratifs
> >    * Forums
> >          o Multiples
> >          o Fils de discussions
> >          o Intégration avec la messagerie (liste de discussion, adresse
> > email) * Listes de discussion
> >          o Archives
> >    * Wiki
> >          o Syntaxe
> >          o Éditeur WYSIWYG
> >          o Historisation
> >          o Annulations et gestion des collisions
> >    * Annonces (« News »)
> >          o Édition collaborative
> >          o Commentaires
> >    * FAQ
>
> Il y a déjà un domaine groupware et wiki. Il faudrait aussi évaluer
> l'intégration.
>
> >Qu'en pensez-vous ?
>
> Du bien, le problème concerne la difficulité d'évaluer une distribution
> de logiciels différents et la multiplication des domaines fonctionnels.
> Grossièrement, je pense que l'on arrive une situation proche des suites
> bureautiques et cela n'est pas encore correctement géré par le format
> QSOS.
>
> Il faudrait a mon avis un mecanisme de ce style dans le header de la
> fiche :
>
> <includedomain>
>   <domain>
>     <qsosfamilyname>revision-control-system</qsosfamilyname>
>     <qsosappname>subversion</qsosappname>
>     <release>1.4.2</release>
>   </domain>
>   <domain>
>     <qsosfamilyname>cms</qsosfamilyname>
>     <qsosappname>Alfresco</qsosappname>
>     <release>XXX</release>
>   </domain>
>   <domain>
>     <qsosfamilyname>groupware</qsosfamilyname>
>     <qsosappname>kolab</qsosappname>
>     <release>2.0</release>
>   </domain>
> </includedomain>
>
> Dans le cas ou, par exemple le wiki est propre a là forge, il faudrait
> faire une fiche QSOS du wiki et l'intégrer.
> Ainsi dans le corp du template 'forge' il n'y aurait plus qu'a
> évaluer le niveau d'intégration de l'ensemble.
>
>       Gonéri
>
>
> _______________________________________________
> Qsos-french mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qsos-french

-- 
Raphaël Semeteys
Atos Origin
Open Source Center
+33 1 55 91 23 35