De lire ce post: "Why People Don't Contribute to OS Projects, and What We Can Do About It", j'ai eu envie de republier ce post qui a 4 ans. (d'où les commentaires plus vieux que le post)

Tobias avait publié une liste de règles à destination des candidats à l'intégration d'un projet open-source (à lire aussi par ceux en sont déjà, pour se faire un état des lieux)

Cet article vient d'être traduit par la Framalang.

A propos du karma de la règle 1 je dirais pour aller plus loin qu'on a plein de karma dans un projet.

On a un karma global, qui est une moyenne pondérée du karma que l'on a aux yeux de chaque autres contributeurs. La pondération étant le karma respectif de chacun de ces autres contributeurs

Un détail qui n'est pas repris c'est la nature des contributions, un point sur lequel j'aime insister.

Vous installez un programme open source, vous avez la chance de pouvoir l'essayer sans aucune contrainte. Et sachant que s'il vous plait vous pourrez l'installer partout où vous en aurez besoin. C'est quand même déjà en soit un cadeau, même si le programme ne vous convient pas.

S'il vous convient c'est encore mieux.

Quoi qu'il en soit, racontez chacune de ces expériences.

Faites l'exercice, choisissez un soft open source installé ces derniers mois et écrivez quelque chose qui ressemble à ce qui suit.

"Aujourd'hui j'ai installé, ce soft, au départ je cherchais à faire ceci et j'avais telles contraintes, la description trouvée là, me laissant croire que l'appli pouvait répondre à mes besoins je l'ai téléchargée.

Je l'ai installé sur mon ordinateur, un ordi de tel type, avec tel OS (Door XP, Litux, Mac Bones). D'ailleurs j'ai consaté que ..."

Franchement l'install s'est plutot bien passée, quoi que je ne savais pas trop quoi répondre à ... )

Une fois installé, ...

Coté utilisation j'ai cherché l'option .. je ne la trouvais pas dans .. normal elle était dans ... . Si je la cherchais dans ... c'est parce que ....

Par rapport à mes besoins j'ai trouvé ca et ca qui m'ont permis de faire ca, mais il me manque encore ca. Heureusement tel programme m'a permis de prendre le relai.

En conclusion j'ai désinstallé ce programme parce que ... et ...

Dommage car j'aimais vraiment bien le fait que ... et ....

Alors j'ai trouvé cet autre programme ... ERte Après 2 mois je l'utilise toujours, je vous raconterai pourquoi demain".

Bloguez ca si vous êtes blogueur, ou ajoutez le en commentaire de ce blog , ou directement sur le forum du produit. (dans tous les cas signalez le à l'équipe de développement)

L'important c'est que n'importe qui puisse avoir accès à votre feedback "généraliste"

Vous vous sentez "agressif", reformulez ou confrontez le texte a des amis qui ont aussi utilisé le produit.

Vous vous sentez "très négatif", transformez toutes les attaques "aux membres du projet" en "critiques du produit". Mais surtout mettez en corrélation chaque reproche, à une attente personnelle et un peu d'explication de celle ci.

Pensez à bien indiquer la version du produit.

Si par contre vous appréciez particulièrement l'application, faites le savoir. Mais essayez d'être aussi bavard que possible.

Aller plus loin ?

Ok tout ça c'est "chez vous". Si vous voulez aller plus loin, vous pouvez proposer de la documentation. écrire un tutoriel, un cas d'école, ...

Quand on écrit une recette de cuisine, on n'explique pas comment allumer la cuisinière. C'est pareil pour une documentation. Un mode d'emploi peut expliquer comment allumer la cuisinière.

Un mode d'emploi sert à 2 choses.

1. palier à des imperfections de l'outil. (s'il est bien fait on a pas besoin de mode d'emploi pour comprendre)
2. pour les cons (qui n'arrivent pas a comprendre un outil bien fait) (lisez la réplique de Laurent en premier commentaire de ce post)

Vous pouvez aussi contribuer par une participation active sur le forum. Comme le raconte Tobias, c'est barbant en tant que développeur de répondre aux questions qui ont déjà trouvé réponse plusieurs fois. C'est une tâche ingrate mais utile que de faire tampon.

Prendre le temps de rediriger les nouveaux, poser les premières questions pour recadrer le problème réel.

Coder

Finalement, contribuer avec du code.

Votre code réponds avant tout à votre besoin. Si c'est un correctif, regardez si un "bugtracker" ou une catégorie bug existe dans le forum. Si c'est une amélioration. Pensez à prendre contact avec les développeurs pour raconter vos intentions.

"Il me manque ca, je vais solutionner mon besoin comme ca." Expliquez bien cela, les développeurs vont peut-être avoir une sympathique réponse vous annonçant qu'un autre à le même besoin et a commencé le travail, ou que des éléments existants du produit peut vous servir de fondation. Et demandez éventuellement ce qu'il faudrait pour que votre amélioration puisse les intéresser.