Re: [fr-discuss] Évaluation des processus de LO par des étudiants

Bonjour Marc-Andre,

Il y a quelques points qui me chagrinnent dans ces documents et leur
realisation.

  1/ Je n'ai vu aucun etudiant s'impliquer reellement dans le projet
pour voir comment ca se passe (en tous cas, pas ceux mentionnes dans le
document). Avant de pouvoir modeliser des processus et faire des
recommandations dessus, il faut venir sur le terrain.

  2/ Dans leur modelisation les etudiants ont fait un enorme
contre-sens: personne ne decide d'une liste de fonctionnalites a
implementer. Dicter une volonte superieure a un contributeur est plus
difficile qu'a un employe. Ce processus fonctionne a l'inverse: les
releases sont a date fixe, chacun le sait et ne rentrent que les
fonctionnalites pretes a ce moment donne. C'est d'ailleurs l'interet du
Feature freeze longtemps avant la version. Il y a aussi besoin de 3
revues de developpeurs d'affiliation differente pour une fonctionnalite
qui arrive apres la date fatale.

  3/ "Assurer une révision du code soumis par les mainteneurs". Les
etudiants n'ont pas du voir les regles de commit de code en dehors de la
branche master.
     * Pour une branche comme libreoffice-4-0 (qui sera la base de
toutes les versions de 4.x) une approbation d'un autre developpeur est
necessaire.
     * Pour une branche comme libreoffice-4-0-0 (qui sera la base de la
version 4.0.0 uniquement) 3 relectures sont necessaires... et ce pour
tout le monde committeur ou contributeur occasionnel.

  4/ "Faire plus d'activités de tests". J'ai l'impression qu'ils n'ont
pas vu l'ensemble des activites du cote des tests. Dire que les
activites de tests sont peu detaillees me montre qu'ils ne sont pas
aller participer aux tests (sur les listes qa) ou l'on parle d'outils
pour structurer les tests comme moztrap ou litmus. Ils n'ont fait aucune
mention de l'effort de multiplier les tests unitaires (qui a meme fait
l'objet d'un Google Summer of Code en 2012).

Et enfin, faire plus de tests (surtout manuels) necessite aussi plus de
volontaires pour les faire... qu'ils n'hesitent pas a venir donner un
coup de main pour se rendre compte qu'il y a une activite de tests.

  5/ "Définition d'un style standard de code"... il y a bien d'autres
choses a nettoyer / uniformiser avant la presentation du code.

  6/ "Assurer une bonne couverture des tests de sécurité" Tu es bien
place pour savoir que ce n'est pas evident de detecter les problemes de
securite et que chaque CVE corrigee dispose maintenant d'un test
unitaire pour ne pas la reintroduire.

  7/ "Il ne semble y avoir que très peu de validation est faite auprès
des utilisateurs avant de soumettre une nouvelle version". Cette phrase
me montre que les eleves n'ont aucun sens de l'organisation du
developpement d'un logiciel libre. Ce n'est pas au developpeur de venir
demander une approbation aux utilisateurs (sinon on ne ferait plus
rien)... mais c'est aux utilisateurs de s'impliquer dans les activites
comme le design, les tests le plus tot possible (sur des daily builds),
la localisation ou meme le developpement.

De plus, je ne suis pas sur que les editeurs de logiciels proprietaire
consultent beaucoup les utilisateurs avant de publier une nouvelle
version... alors pour un logiciel libre, les utilisateurs ont l'avantage
de pouvoir s'impliquer pour donner leur avis.

  8/ "Faciliter l'intégration des nouveaux contributeurs". Ont ils
seulement vu que nous avions une serie de Easy Hacks pour commencer le
dev a peu pres facilement? Ont ils essayer de s'attaquer au
developpement LibreOffice? A mon avis non, parce que sinon ils auraient
vu qu'il y a une poignee de devs accueillants prets a donner des liens
vers du code, donner un coup de main, etc.

Nous sommes toujours preneurs d'idees nouvelles pour mieux integrer les
nouveaux developpeurs et pour mieux leur montrer que LibreOffice est un
projet Fun avec des gens sympas (et pas seulement un truc demode comme
une suite bureautique).

Et enfin, dans cette integration des nouveaux contributeurs, ils ne
parlent que des developpeurs... alors que certains ici te diront que des
gens qui testent, localisent, maintiennent les sites web / serveurs,
font la promotion, repondent aux questions des utilisateurs sont aussi
des contributeurs.


Bref, je ne voudrais pas me montrer completement negatif, mais
j'attendais une etude plus poussee du projet. Si tu veux faire
recommancer ce projet une prochaine fois a des etudiants, je te
conseillerais de les diviser en petits groupes (comme tu as fais) mais
de leur demander de s'impliquer reellement dans differentes taches du
projet (par exemple, un groupe sur du dev, un groupe sur des tests,
etc). Comme ca l'activite serait benefique pour tout le monde:
  * Les etudiants auraient vraiment mis un pied dans le monde du
Logiciel Libre (LibreOffice en particulier)
  * LibreOffice aurait retirer un petit coup de main toujours bienvenu
  * L'etude serait bien plus pertinente

Je tiens a te remercier de pousser les etudiants autour de toi vers
LibreOffice (meme si j'ai beaucoup critique avant).

--
Cedric

On Mon, 2013-01-28 at 19:45 -0500, Marc-André Laverdière wrote:
> Voici en version téléchargeable :)
>
> mlaverd.theunixplace.com/log3000_lab6_recommandations_mises_en_commun.pdf
> http://mlaverd.theunixplace.com/log3000_lab6_processus_mis_en_commun.png



-- 
Envoyez un mail à discuss+help@fr.libreoffice.org pour savoir comment vous désinscrire
Les archives de la liste sont disponibles à http://listarchives.libreoffice.org/fr/discuss/
Tous les messages envoyés sur cette liste seront archivés publiquement et ne pourront pas être 
supprimés