Journal Pourquoi je n’arrive pas à contribuer au logiciel libre.

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
53
3
nov.
2012

J’écris ce journal afin de mettre sur la table une question qui m’intéresse fort : Comment fait‐on pour contribuer ?
En effet, j’ai essayé, je n’arrive pas ! :(

C’est pourtant un sujet que j’estime connaître assez bien. En tant qu’utilisateur de logiciel libre, il m’est déjà arrivé de soumettre quelques patches ou rapports de bogues.
Si vous utilisez KDE, vous trouverez même une vingtaine de lignes de code de ma conception dans Kate (pour un bouton dans la configuration, sur lequel vous ne cliquerez probablement jamais !). \o/

Sauf que moi, j’aimerais bien dépasser le stade du patch anecdotique, et m’impliquer dans un projet.

Malheureusement, je n’ai jamais réussi, car j’ai rencontré plusieurs obstacles.

Déjà, il faut trouver un projet qui m’intéresse : il y en a plein, dont certains que j’utilise couramment.
Mais ensuite, il s’agit d’avoir des idées de contributions, de fonctionnalité… Et là, c’est déjà plus dur : si je prends KDE, ou encore Django (qui sont deux projets que j’aime particulièrement), ils sont déjà bien aboutis, et en les regardant je n’ai pas la moindre idée d’amélioration possible.

Même si j’arrive à avoir des idées, je suis quasi‐systématiquement découragé : en discutant avec les développeurs, il s’avère que mon idée toute simple est beaucoup plus difficile à implémenter que je ne le pensais ; ou alors en commençant à lire le code pour pouvoir le modifier, je me rends compte qu’il est extrêmement gros ou complexe, et je bute sur des notions que je ne connais pas. Du coup, j’abandonne.

Il y a aussi le problème de la motivation : je n’ai jamais été extrêmement motivé par la contribution à un projet libre, car j’ai l’impression que je ne vais pas coder de choses vraiment intéressantes en soi.
En fait, je préfère m’amuser tout seul, sur plein de petits projets que je trouve intéressants, et pour lesquels je suis bien plus motivé.

Pourtant, je trouve ça dommage de ne pas mettre mes compétences à contribution… Surtout que ça pourrait m’apporter beaucoup.

Voilà. Avez‐vous des conseils, retours d’expérience, etc., là‐dessus ?
Si vous contribuez à un projet, comment l’avez‐vous découvert ? Est‐ce que vous êtes vraiment motivé par ce que vous faites, et pourquoi ?

  • # Si t'as du temps, j'en ai des idées pour KDE !

    Posté par  (site web personnel) . Évalué à 9.

    https://bugs.kde.org/show_bug.cgi?id=288179
    https://bugs.kde.org/show_bug.cgi?id=295982

    Sinon Akonadi plus PostgreSQL intégré à tendance pas trop marcher. Il me semble que Host: n'est pas réglé comme il faut.. à creuser.

    Aussi, avec Akonadi, quand $HOME est dans un truc assez long, genre /usr/local/pouet/bidule/user/ et que le hostname est trop grand, la socket de la DB (pgsql ou mysql) dépasse les 107 char, et ça pète. Utiliser /var/run/${USER} à la place pourrais être cool.

    Hop, au boulot !

    • [^] # Re: Si t'as du temps, j'en ai des idées pour KDE !

      Posté par  (site web personnel) . Évalué à 5.

      Intéressant :)

      Akonadi m'intéresse moins (disons que j'ai des préjugés négatifs envers ce logiciel, pour ne pas partir dans le troll), mais l'illumination du clavier pourrait être sympa et utile.
      Je vais essayer de m'y plonger un de ces jours. J'espère juste que je ne vais pas être rebuté par la complexité de ce qu'il va falloir assimiler pour pouvoir m'y mettre. Courage !

      • [^] # Re: Si t'as du temps, j'en ai des idées pour KDE !

        Posté par  (site web personnel) . Évalué à 8.

        Si tu veux un conseil, il faut y aller en plusieurs étapes…

        https://git.reviewboard.kde.org/r/105810/

        • J'ai regardé le code, j'ai essayé vite fait un truc, ca n'a pas fonctionné, ca ma gonflé, j'ai laissé tombé
        • J'ai recommencé 1 semaine plus tard, j'ai fini par avoir quelque chose de fonctionnel même si je voyais que la méthode n'était pas la bonne
        • J'ai repris mon patch plus tard afin de corriger ce qui me semblait mauvais
        • Je l'ai envoyé sur la "reviewboard" afin de le finaliser.

        Voilà, c'est pour les petits ajouts…

        Pour les gros patch, c'est beaucoup plus compliqué, surtout si tu cumules patch et ajout de module… Je sais de quoi je parle … :-(

    • [^] # Re: Si t'as du temps, j'en ai des idées pour KDE !

      Posté par  . Évalué à 2. Dernière modification le 04 novembre 2012 à 17:39.

      Mais quel est l'intéret de mettre un monstre comme postgresql pour pouvoir faire fonctionner akonadi ?

      Après on s'étonne que les environnements de bureau, ou le démarrage d'une machine se trainent comme une tortue asthmatique au millieu d'un champ de fleurs, mais là c'est un peu le chercher aussi non ? En plus de ça toutes ces horeurs sont lachées dans la nature sans être complètement stable et après on s'étone que les utilisateurs ralent. Et ensuite on a des guignols qui vont se plaindre du système de démarrage Linux etpondre un truc imbitable pour soi-disant combler les faiblesses du système de démarrage actuel.

      Mais oui, c'est vrai, les développeurs ne peuvent pas se tromper, tout comme nos chers personnalités politiques. En fait si je veux l'ouvrir, je dois faire partie de l'élite des devs, et avoir participé à un truc que je ne cautionne pas …

      Il faudrait penser un jour à virer toutes ces conneries pour retrouver un bureau utilisable, et éventuellement les proposer comme add-on.

      • [^] # Re: Si t'as du temps, j'en ai des idées pour KDE !

        Posté par  . Évalué à 7.

        C'est très certainement le courant inverse de NIH: Don't Want To Reinvent Here.

        « Tiens, il nous faut une base de donnée dans lequel l'utilisateur peut chercher dans n'importe quel champ. Et il faut pouvoir supporter les mecs trop sociaux qui ont 2000 contacts et 20000 rendezvous sans que ça rame trop. C'est qui va coder ça ? Moi j'ai pas envie. Et puis zut, y a qu'a utiliser une base de donnée relationnelle en sql avec plusieurs backend, dont pgql, mysql et sqlite. En plus ça permet de déporter ça ailleurs, et c'est pas de notre faute si les utilisateurs perdent leur données. »

  • # Un peu comme toi

    Posté par  . Évalué à 9.

    Je suis dans le même cas que toi. Mais comme tu le dit je m'éclate plus à faire des projets perso (Solveur de sudoku, Eternity 2, Gtk, …) ou des sites webs. Je pense qu'il ne faut pas chercher plus loin, si sa ne te plait pas plus que ça, ne te force pas. Si la programmation devient une chose barbante, sa n'a plus d'intérêt.

    Aussi peut-être que beaucoup de développeurs contribuent plus ou moins dans un cadre professionnel (ou universitaire), ce qui peut être une source de motivation suffisante. Cela dit, ce n'est pas mon cas donc je ne m'avancerais pas plus.

    En tout cas je pense que le principal est que tu te fasse plaisir lorsque tu programme, même si cela ne profite finalement qu'à toi !

    • [^] # Re: Un peu comme toi

      Posté par  (site web personnel) . Évalué à 2.

      Pareil pour moi, autant j'arrive à me motiver pour des projets persos (même si je finis en général par abandonner au bout de quelques temps parce que ça sert à rien, faut être honnête), autant j'ai beaucoup de mal à contribuer à des projets existants…

      Je pense que c'est une histoire de barrière à l'entrée à passer, et qu'une fois inscrite sur les bonnes mailings lists, à suivre les bons canaux IRC et à connaître à peu près le code, ça serait plus facile, mais j'ai jamais vraiment passé le cap du «je regarde le bugzilla en espérant sans trop y croire trouver un truc à ma hauteur ET qui ne date pas de 2003».

      • [^] # Re: Un peu comme toi

        Posté par  (site web personnel) . Évalué à 3.

        Voilà, je suis vraiment comme vous deux. (sauf qu'en plus je m'amuse tellement avec mes projets persos que j'abandonne très rarement en cours de route… Bon, une fois terminés ils ne servent à rien…)

        • [^] # Re: Un peu comme toi

          Posté par  . Évalué à 10.

          Faire des petits projets perso qui servent à rien, c'est flatteur pour l'égo, et probablement un peu formateur. Mais quand même, les gars, il faudrait prendre conscience de votre valeur et qu'il y a une histoire à écrire, et cette histoire, elle est communautaire.

  • # La cathédrale et le bazar

    Posté par  (site web personnel) . Évalué à 10.

    Règle numéro 1: Every good work of software starts by scratching a developer's personal itch

    ( http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar )

    Sinon, le projet GNOME par exemple a un tag "GNOME love" sur certains de ses bugs, justement pour signaler ceux qui sont (sensé être) faciles d'accès. Il est possible que d'autres projets aient un concept similaire.

    • [^] # Re: La cathédrale et le bazar

      Posté par  . Évalué à 5.

      Règle numéro 1: Every good work of software starts by scratching a developer's personal itch

      J'approuve. Contribue à un projet que tu utilises souvent et pour lequel tu as des idées d'améliorations ou de problèmes à corriger. Que ce soit KDE, Django ou autre chose.

      Et si jamais tu aimes et utilises Python, nous avons un guide à l'attention des développeurs :-)

      • [^] # Re: La cathédrale et le bazar

        Posté par  (site web personnel) . Évalué à 3.

        Intéressant. Après, comme je l'ai dit, je n'ai pas vraiment d'idées d'améliorations (ou alors je vais aller contribuer à Hurd).

        Puisque tu parles de Python : J'adooore Python !
        Mais justement, je n'ai pas la moindre idée de chose à ajouter. Il n'y a pas de bug, il y a tout ce qu'il me faut…

  • # Commentaire supprimé

    Posté par  . Évalué à -10.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Zino

      Posté par  . Évalué à 10.

      Oh merde. Je peux pas encadrer les nazis. Mais laisse tomber.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à -10.

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Zino

        Posté par  . Évalué à 2.

        Précise ta pensée ?

        • [^] # Re: Zino

          Posté par  . Évalué à 1.

          Si tu n'as pas compris, n'essaye pas.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à -10.

            Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Zino

            Posté par  . Évalué à 10.

            En ce qui concerne Zino et SamWang, je décrirais plutôt ça en reprenant Groland:

            Si vous y avez compris quelque chose, ne prenez pas le volant!!

        • [^] # Re: Zino

          Posté par  . Évalué à 10.

          Pour être tout à fait exact… Je pense que c'est un ouf, lui. Un ouf malade.

    • [^] # Re: Zino

      Posté par  . Évalué à -1.

      C'est marrant, dans l'exemple d'application que Palkeo a écrit il a y un "détecteur" d'auteur pour lequel il a écrit un journal et dont le premier commentaire t'es destiné. :p

      Si Samwang est un théoricien du complot, il nourri parfaitement le cliché! Un peu trop à mon goût, je dirais même plus, un peu trop pour être sincèrement idiot.
      Voilà que je me met à conspirer également. :/

      ps: Je viens de découvrir que DLFP avait introduit une fonction qui semble avoir été confectionnée pour toi, en voulant te répondre, on peut apercevoir au dessus de l'espace de rédaction une case disant "Do not feed the troll!". :)

      pps: dommage que je ne comprenne pas l'anglais.

  • # We are many and We need you

    Posté par  (site web personnel) . Évalué à 6. Dernière modification le 03 novembre 2012 à 19:58.

    J'ai créé la page http://linuxfr.org/wiki/projets_libres_linuxfr pour recenser les créations libres des membres de linuxfr. Tu y trouveras peut être un projet qui te plaît.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Mauvaise approche, changer d'approche.

    Posté par  . Évalué à 10.

    Sauf que moi, j'aimerais bien dépasser le stade du patch anecdotique, et m'impliquer dans un projet.

    Le "stade" du patch anecdotique c'est la contribution à un projet.
    Même sur des très gros projets libres tu peux finir par avoir une quantité non négligeable de code qui ne sont qu'une série de patch anecdotique. Le kernel Linux a commencé comme ça (et dans une certaine mesure il doit encore y avoir 30 à 40% du code qui sont des patchs anecdotiques)

    Déjà, il faut trouver un projet qui m'intéresse

    Mauvaise approche.
    Pour commencer il faut que tu trouves un truc qui te casse les pieds. Un truc qui te manque. Code la fonctionnalité dont tu as besoin et dont tu vas te servir. Ensuite une fois ce problème réglé tu verras de toi même si ça serait intéressant de remonter le code dans un projet ou un autre.

    • [^] # Re: Mauvaise approche, changer d'approche.

      Posté par  . Évalué à 4.

      C'est ce que je conseille au futurs contributeurs d'un projet dont je m'occupe: pensez à votre shard, vos fonctionnalités, et en y pensant, faites en sorte que ca soit intégrable au projet source. Ca ne demande que peu de boulot, mais c'est formidable de le considérer avant :)

    • [^] # Re: Mauvaise approche, changer d'approche.

      Posté par  (site web personnel) . Évalué à 3.

      Pour commencer il faut que tu trouves un truc qui te casse les pieds. Un truc qui te manque. Code la fonctionnalité dont tu as besoin et dont tu vas te servir.

      Justement, en pratique il n'y a pas grand chose qui me casse les pieds, ou qui me manque.

      Ou alors, comme je l'ai dit, j'ai vite une grosse désillusion en me rendant compte que même si ça parait simple, ça sera très difficile à implémenter. Ou en voyant la montagne de code (parfois avec des notions inconnues) que j'aurais à comprendre et à modifier pour arriver à mon résultat.

      • [^] # Re: Mauvaise approche, changer d'approche.

        Posté par  . Évalué à 5.

        Ou alors, comme je l'ai dit, j'ai vite une grosse désillusion en me rendant compte que même si ça parait simple, ça sera très difficile à implémenter. Ou en voyant la montagne de code (parfois avec des notions inconnues) que j'aurais à comprendre et à modifier pour arriver à mon résultat.

        En même temps, comme tu vises des projets établis si c'était simple ca serait déjà fait ;)

        Tu dis que tu aimes le Python y'a des dizaines de modules ou d'applications qui ont clairement besoins d'amélioration, ou simplement d'un mainteneur.

      • [^] # Re: Mauvaise approche, changer d'approche.

        Posté par  . Évalué à 8.

        Justement, en pratique il n'y a pas grand chose qui me casse les pieds, ou qui me manque.

        Tu utilises Debian ? Non parce que là on a 1300 bugs ouverts sur KDE et les logiciels dérivés, et l'équipe Debian/KDE manque de bras pour tout trier/corriger…

        Mais sinon, au lieu de chercher à coder de nouvelles fonctionnalités, peut-être il vaut mieux essayer de corriger des bugs, d'abord des facile (il faut un peu de temps pour plonger dans un code), puis des plus difficile. ça permet de découvrir le code, la communauté autour avant de se lancer dans de "grands travaux".

      • [^] # Re: Mauvaise approche, changer d'approche.

        Posté par  (site web personnel) . Évalué à 3.

        en pratique il n'y a pas grand chose qui me casse les pieds

        Tu dis toi même que Akonadi te casse les pieds :)

        Dans mon exemple ci dessus, j'ai commencé à bosser la dessus alors que la complétion via nepomuk fonctionnait enfin… Mais j'en avait marre de dépenser du temps batterie à indexer des mails…

  • # Y a pas que le code dans la vie

    Posté par  . Évalué à 8.

    Il ne faut pas oublier non plus que tu peux contribuer au libre autrement qu'en codant : les traductions, par exemple, sont un vrai boulot qui demande de la culture, qui est semé d'embûches et qui reste très important pour avoir un système de qualité, tant aux yeux des décideurs que des utilisateurs lambdas. Tu peux aussi ajouter du contenu à une ressource existante, par exemple en créant des jeux d'icônes ou bien des C.S.S. pour le site, ce qui est également chronophage si tu veux faire quelque chose d'un minimum travaillé.

    Autrement, si tu en as les compétences et le courage, tu peux toujours t'adonner au reverse engineering et écrire pour Linux ou un autre noyau les pilotes des périphériques qui sortent en permanence dans le commerce. Là, pour le coup, il y aura toujours de quoi faire.

    • [^] # Re: Y a pas que le code dans la vie

      Posté par  (site web personnel) . Évalué à 4.

      Tu as totalement raison, mais dans mon cas, j'avoue être principalement intéressé par le code. Et c'est là-dessus que je pense pouvoir être le plus apte à contribuer.

      • [^] # Re: Y a pas que le code dans la vie

        Posté par  . Évalué à 10.

        Un autre moyen que j'ai trouvé efficace, c'est d'essayer de répondre aux questions techniques sur le forum d'un de tes projets préféré. Et ne pas hésiter à se plonger dans des sections de code inconnues au départ. Même si on ne trouve pas la solution, on a des chances de faire avancer le problème, ou de faire évoluer l'idée qu'on s'en faisait. Et si d'autres s'en occupent et proposent des patchs, les étudier aide en général à mieux comprendre comment ca marche, et être en mesure d'aider plus les fois suivantes.

        Depuis que je me suis investi dans Cairo-Dock, j'ai pu toucher à pas mal de sujets très divers, et hacké des sections de code que je n'aurais pas pensé possible, et dont je ne connaissais rien au départ: GTK, affichage cairo et OpenGL avec les jauges et graphes, DBus pour un binding golang…

        Le tout étant de trouver LE programme que tu utilises tout le temps et sur lequel tu te dis :

        • Il lui manque des trucs qui seraient vraiment intéressants, ou des problèmes à régler.
        • C'est une base sure que tu vas utiliser pour quelques années pour que l'investissement soit utile, ou au moins que tu le ressentes ainsi.
    • [^] # Re: Y a pas que le code dans la vie

      Posté par  (site web personnel) . Évalué à 5.

      Dans les jeux vidéos, le gros de la valeur ajouté est dans les graphismes, les sons, l'histoire et le level design. Ca permet de changer du code!

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Toujours la même chose

    Posté par  . Évalué à 9.

    La réponse est triviale.

    Quand au taff tu arrives sur un projet il te faut combien de temps avant ta première contribution seul et combien de temps avant d'être productif ? La barrière d'entrée c'est qu'il faut toujours beaucoup de temps; surtout que tu es dans l'environnement le plus hostile pour diffuser facilement le savoir. Et vu que ton temps dispo est 4 à 8x plus rare que ton temps pro…

    Bref rentrer sur un projet existant et mûre par la grande porte demande un gros investissement. Sur les projets plus jeunes ou périphérique il est par contre facile d'apporter une contribution, surtout que généralement tu n'as pas à chercher bien loin pour savoir quoi faire.

  • # temps de pénétration

    Posté par  . Évalué à 1.

    et oui, il est effectivement très long de commencer rentrer dans un projet deja existant, ton idée a sans doute déjà été abordé, ou pas du tout. En tout cas il y a tres rarement une liste sur le trac/bugzilla officielle de choses à faire avec une dose de "culture" projet faible (souvent, on commence par les traductions, typo, probleme d'alignement de widget, etc). Et c'est souvent aussi (pour moi) la difficulté de proposer un patch "comme il faut" qui repousse mes contributions. En tant qu'arrivant, personne me connait, je fourni un patch qui n'est pas dans les regles de l'art, il est rejeté comme un mal propre, et résultat je me casse.

    • [^] # Re: temps de pénétration

      Posté par  (site web personnel, Mastodon) . Évalué à 7.

      En tant qu'arrivant, personne me connait, je fourni un patch qui n'est pas dans les regles de l'art, il est rejeté comme un mal propre, et résultat je me casse.

      Parce que tu t'y prend mal.

      On n'arrive pas sur un projet avec ses gros sabots "tiendez, vla mon patch". C'est comme si tu étais un nouveau commis en cuisine dans un restaurant, que le chef te demande de faire le "gateau au chocolat" star du resto, et que tu en fasses un sans demander la recette (et qu'il y a donc de forte chance que ce ne soit pas le gateau attendu, parce que tu n'aura pas mis la crème qu'il faut, pas utiliser le bon chocolat etc).

      Bref, quand on arrive sur un projet, on essaye de se renseigner :

      • chercher le bon canal de communication pour les contributeurs : forum / IRC / mailing list etc…
      • se présenter : "bonjour, j'ai vu tel bug, je voudrais contribuer", suivi d'un "quel est la procédure à suivre s'il vous plait"

      Et là, il y a de forte chance qu'on te réponde, "va lire la doc ici" (quand elle existe :-) ), ou "faut faire comme-ci comme ça"..

      Ensuite tu peux commencer ton patch et le proposer en suivant la procédure, le coding style etc…

      Pour toi :
      - tu ne refais pas 15 fois ton patch pour que ça soit accepté
      - ta contribution est plus vite intégrée : ça flattera ton ego
      - tu seras mieux vu et plus vite accepté
      - les autres contributions n'en seront que plus facile

      N'oublie pas que ce sont des êtres humains. Il ne faut donc pas oublier les rêgles sociales traditionnelles :-)

  • # Exemple avec Mozilla

    Posté par  (site web personnel, Mastodon) . Évalué à 7.

    Si j'ai bien compris, c'est pas l'envie de contribuer qui te manque.

    Ne cherche pas à te dire tout seul "qu'est ce que je pourrais bien faire sur ce projet". Tu ne trouveras pas.

    Par contre, va voir les développeurs, et demande leur. Commence par leur demander des trucs qui sont faciles à faire. Cela a plusieurs avantages :

    • cela te fait découvrir l'intérieur du code source
    • cela fait avancer ENORMEMENT le projet. En effet, les trucs trop simple à corriger, il y en a des tonnes, parce que justement, c'est trop simple et que les développeurs déjà en place sont trop occupés à développer les trucs les plus compliqués.
    • cela rend le logiciel mieux fini, donc plus agréable pour l'utilisateur.

    Par exemple, corriger une faute d'orthographe dans un menu :
    - tu apprends où est le code des menus (ou alors comment et où sont stockées les chaînes de traduction)
    - tu libères 5 minutes de temps pour les développeurs (et 5 min + 5 min + 5 min +… ça leur en fait du temps de gagner pour dev les trucs les plus durs)
    - tu rends le logiciel moins agaçant pour les utilisateurs pour qui cette faute les choquent.

    Tu commences donc par ces trucs anodins, et au fur et à mesure des patchs, tu passes à des bug fix ou des fonctionnalités plus compliquées. Et au bout de quelques mois ou année, tu finis par devenir un core-developper, code reviewer etc :-)

    Une chose est sûre : tu ne pourras jamais arriver dans un projet et pouvoir proposer une grosse évolution tout de suite. C'est comme tout, il faut apprendre comment il fonctionne, de l'interieur et de l'exterieur. Bref, de la motivation, du courage, et de l'huile de coude.

    Pour prendre l'exemple de Mozilla, dans la liste des choses à faire, il y a les bugs marqués "good first bug". Facile à faire en principe pour un nouveau venu. Pioche ! ;-) (tu peux aussi affiner la recherche en fonction des composants ou applis qui correspondraient plus à tes compétences/envies, le projet Mozilla ne se résume pas à Firefox ;-) )

  • # Ma vie + proposition de projet :)

    Posté par  (site web personnel) . Évalué à 2.

    Bon, beaucoup de points ont déjà été abordé dans d'autres commentaires mais comme c'est ma vie, je les reprend en parti.

    Comme toi (et beaucoup d'autres, vu les commentaires), j'ai longtemps voulu contribuer à des projets libres.

    Au niveau code, j'ai trouvé ça très compliqué. La plupart du temps, quand j'aurai pu contribuer ça aurai été "seulement" pour des corrections de bugs. Et il faut être honnête: le temps nécessaire à investir (comprendre le code, le corriger, soumettre un patch, se faire jeter, soumettre un nouveau patch, …) est en général bien trop long pour ce que ça rapporte. Il faut vraiment être intéressé (comprendre: avoir besoin) pour le faire jusqu'au bout.

    Par contre, j'ai pas mal contribué au projet Fedora en tant qu'ambassadeur. C'est probablement dans ce genre de contribution qu'il est le plus facile de rentrer. La plupart des projets sont fait par des développeurs (qui le font en général pour eux). Tous les "à coté" des projets (doc, site web, com) manquent souvent de gens de bonne volonté.

    De manière générale, contribuer pour contribuer ne mène à rien : au début on est plein de bonne volonté, puis on se lasse et comme on ne le fait pas pour répondre à un besoin, on passe à autre chose. Et comme le temps d'entré dans un projet est relativement long, on se retrouve à (avoir l'impression de) rien faire.
    Ça déjà été dit mais c'est à mon sens le plus important : Il faut avoir un besoin, sinon tu ne continuera pas.

    J'ai eu pas mal d'idée de projet intéressant à démarrer. Mais ils étaient plus sur le mode "ça serait cool de faire ça" que "j'ai besoin de ça". Ça n'a donc jamais abouti. Ma planche de salut a été le projet devparrot (il est ici l'appel à contribution :) ). Pour faire rapide (c'est la première fois que j'en parle, soyez gentils):

    • Je l'utilise!! (et c'est probablement le seul point qui fait que je code encore dessus)
    • C'est un éditeur de texte (qui veut devenir un ide) écrit en python/tk.
    • Je travaille seul dessus depuis environ 1 an et demi.
    • Le code est encore jeune (certain diront trop) et pas trop gros (60 fichiers/4000 lignes) . Il devait pas trop être compliqué de rentrer dedans (j'espère)
    • Je suis le seul à l'utilisé et c'est la première fois que j'en parle. Il y a donc … aucune doc, des bugs que j'évite inconsciemment. C'est la grosse lacune du projet. J'y travaille, je suis en pleine stabilisation du code et j'ai récemment créé un compte chez tuxfamily qu'il faut que je le remplisse. Dans une semaine il devrait y avoir qqchose.
    • Il y a plein de chose à faire:
      • de la doc
      • du debug
      • de la petite fonctionnalité (dans le core ou sous forme de plugin)
      • de la grosse fonctionnalité
    • C'est du "eat your own dog food". Une fois qu'ont est dedans c'est extrêmement motivant de coder des fonctionnalités améliorant l'outil qui sert à coder.
    • Je suis sympa (oui, oui :)), c'est avec plaisir que je te mettrait le pied à l'étrier pour accepter tes contributions.

    Matthieu Gautier|irc:starmad

  • # Et contribuer dans un domaine scientifique que tu ne connais pas

    Posté par  (site web personnel) . Évalué à 2.

    Ca peut être motivant, il te faudrait non seulement comprendre et intégrer le code déjà écrit mais en plus comprendre les problématiques qui ne sont pas les tiennes. En plus, ta contribution pourrait constituer un tremplin…
    Réfléchis-y, et regarde notre projet médical: http://freemedforms.com

    Bonne réflexion

    http://www.freemedforms.com

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.