Comment évaluer un projet open source en s'associant?

En supposant que j'ai trouvé un projet open source qui m'intéresse, comment puis-je évaluer le projet (les membres, le niveau d'activité, etc.) pour déterminer si rejoindre le projet sera une bonne utilisation de mon temps et de mon énergie?

Regardez l'historique du contrôle de source.

À partir de cela, vous pouvez voir les enregistrements, réviser le code, évaluer le niveau d'activité et généralement voir la qualité des validations. Vous pouvez en apprendre le plus en regardant simplement l'activité du code source.

Vous pouvez faire plusieurs choses:

1. Regardez leurs archives de listes de diffusion, voyez comment la communauté se comporte en public
2. Regardez la fréquence de leurs sorties et la qualité des notes de sortie
3. Recherchez un énoncé de mission clair et une liste des fonctionnalités / exigences sur leur site
4. Vérifiez sa maturité - si vous cherchez à être encadré / facilité dans un projet, un projet mature est plus indulgent qu'un tout nouveau projet. L'inverse est également vrai.
5. Regardez la structure, est-ce un dictateur bienveillant ou une approche de conseil communautaire
6. Recherchez leurs instructions pour rejoindre, amical? clair?

C'est un début quand même :)

Testez d'abord les eaux. Sortez dans les listes de diffusion, les canaux irc, etc. et regardez comment les choses fonctionnent. Corrigez un bogue ou ajoutez vous-même une fonctionnalité demandée connue et soumettez un correctif. Voyez comment il est accepté ... travaillent-ils avec vous pour le faire éditer et l'inclure ou vous combattre?

Évaluez-vous également. Avez-vous vraiment le temps et l'intérêt de rester et vaut-il la peine que le projet investisse pour vous mettre au courant?

Regardez la couverture du test. Contribuer à un projet avec un historique / mandat d'accepter uniquement les demandes de tirage / correctifs avec des tests réussis sera un processus beaucoup plus réussi et agréable que d'essayer de collaborer sur quelque chose avec des développeurs qui ne peuvent pas / ne veulent pas écrire de tests unitaires.

J'ai dû travailler plusieurs fois sur la mise à jour des anciennes versions des bibliothèques abandonnées pour le travail. Normalement, je serais ravi d'être payé pour contribuer à des projets open source. Mais quand il n'y a pas de tests et une mauvaise documentation, c'est juste infernal.

Rejoignez-nous si vous apprécierez ¹ travailler sur le projet.

¹ : «profiter» pourrait signifier tout ce qui vous rend heureux.

Basez-le sur vos objectifs (pas sûr de ce qu'ils sont). Si vous essayez d'acquérir une expérience en programmation, vous n'avez vraiment pas grand-chose à perdre en l'essayant. Si quoi que ce soit, vous pouvez apprendre comment «ne pas» coder.

Si vous essayez de vous faire un nom en vous attachant à un grand projet, vous aurez peut-être plus de mal. Essayez de rechercher sur le net des blogs ou des commentaires d'autres développeurs et utilisateurs du logiciel (si c'est si loin.). Jetez un œil à la progression du codage. Se déplace-t-il à un rythme à votre convenance.

Essayer de savoir si les autres membres "jouent bien avec les autres" peut prendre une combinaison de certaines des pratiques que je viens de mentionner.

Essaye le. "Ça ne coûte rien" - John Belushi, Animal House.