Bonsoir a tous > > > > Commencer peut-être par lire : > > http://www.debian.org/intro/help > > ou > > http://www.debian.org/devel/ > > > > Bonne lecture ;)
j'ai lu aussi :-). N'ayant pas encore contribué a Debian (hormis quelques bugreport de temps autres) je me sens concerné aussi, du haut de ma petite expérience dans un petit projet open source. Le 04/03/2009 à 21:48, Laurent Guignard a écrit : > > Bonsoir Christophe, > > J'ai bien lu ces documents et d'autres comme le Debian Maintainer Guide, > Developer Guide,... > Simplement, le principe c'est de donner une première idée de ce que le > futur contributeur sera amené à passer comme temps, à s'investir dans le > projet. Une réponse du type 1/2 heure à 1 heure par jour semble un bon > début pour prendre connaissance du projet me semble plus opportun que "le > temps que tu peux y passer..." Personnellement je préfère "le temps que tu peux/veux y passer", car je ne peux pas garantir un investissement horaire régulier. > Dans mon exemple du package MUTT (ce n'est pas le seul en cause), > je trouve que l'organisation du travail autour d'un package reste souvent > un peu obscure. On se retrouve avec des petits jeunes (don je fais parti) > qui refont du travail (en plusieurs heures, voir jours) que des anciens ont > réalisés en 30 minutes. En dehors du fait que le jeune a beaucoup appris et > que les anciens ont perdu un peu de temps à examiner le patch fourni, je > trouve que cela fait beaucoup de temps de perdu ! Est ce du temps perdu ? La phase d'apprentissage et d'intégration peuvent paraître stériles, mais il n'en est rien, il est inévitable de passer par là. Il ne faut pas que ca dure trop longtemps :) Mon expérience (unique et petite mais ...) a débuté par un bug qui m'énervait, j'ai bloqué quelques jours et j'ai envoyé un patch de 3 lignes. Maintenant il me faudrait 10 minutes pour le refaire. Puis j'en ai corrigé un autre, complété la traduction etc ... > Je crois me souvenir que dans mes cours d'informatique (il y a déjà > quelques temps), cela s'appelait de la gestion de projet. J'ai tendance a penser qu'on t'a (nous a) enseigné le modèle hiérarchisé (la cathédrale), alors que Debian c'est plutot auto-organisé collaborativement, le bazar qui marche fort bien. A lire aussi le système de vote Condorcet+ de debian, qui est très interessant (et très en avance sur nos vielles institutions). > Peut-être qu'un système permettant de laisser certains bugs aux newbies > (moi) pour se faire la main, et d'autres bugs (peut-être plus bloquant pour > le projet) seraient traités en priorité pas les "anciens" du projet. On ne sait pas toujours à l'avance si c'est un bug facile ou difficile ! Et apparemment c'est un problème universel. Sur lwn.net ou planet.debian.org, Ted Tso, developpeur de ext4 dit que les patch qu'il reçoit lui servent a localiser le bug, mais qu'il les réécris souvent entièrement ! > Enfin bon, je crois bien avoir déjà vu passer sur cette liste une > discussion à propos de l'attribution de la résolution de bugs avec le pour > et le contre ! Je vote pour ... l'autodetermination. Erre dans le bugtracker, dans les sources et envoie un/des patch et des questions (ou réponses) sur la mailing liste, et ca se fera tout seul ... > > Librement Patience et longueur de temps font plus que force ni que rage. :-) Alain. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to debian-user-french-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org