2008-08-05 8 views

Répondre

18

Je passerais du temps à connaître les gens d'abord. Habituellement, ils ont un salon de discussion IRC où tout le monde tourne au ralenti. Passez du temps à apprendre à connaître les gens, à étudier le code, à consulter la documentation, puis si vous avez l'impression que vous correspondez bien au projet, commencez à contribuer aux correctifs de bogues. N'essayez pas d'ajouter de nouvelles fonctionnalités au début. Ils ne seront généralement pas acceptés.

Aussi regarder ce google tech parler sur How To Protect Your Open Source Project from Poisonous People. Cela t'apprendra quoi ne pas faire.

+0

Lien brisé (6 ans, pas étonnant). Fixé. –

+0

Voici comment je peux contribuer t open source: Faire un projet en utilisant cette source ouverte et, quand vous trouvez que sth else peut être ajouté dans cette source ouverte pour être utilisé par ceux qui l'utilisent. Vous créez cette fonctionnalité et c'est votre contribution à l'open source. –

0

Cela dépend du projet, comment et où il est hébergé. La meilleure chose est de trouver un contact et de les envoyer par courriel ou de voir s'il y a une liste de diffusion des développeurs.

1

La première chose à faire est de contacter les personnes principales qui exécutent le projet open source. Demandez-leur si vous pouvez contribuer au code et aller de l'avant. Il vous suffit d'écrire votre code amélioré et de le donner à votre code, ce qui peut entraîner le rejet de votre code.

4

Comme les affiches précédentes l'ont dit, c'est une question de projet. Vous constaterez que certains sont plus ouverts au changement que d'autres. D'un point de vue mécanique, vous aurez besoin de voir s'ils utilisent SVN (par exemple sur google code) ou CVS (par exemple sur sourceforge) et de déterminer s'ils utilisent un patch ou une autre méthode.

Un bon exemple du genre de procédure que vous pourriez avoir besoin d'employer peut être vu sur le site gimp: http://www.gimp.org/bugs/howtos/submit-patch.html Notez l'utilisation de Bugzilla, CVS patch et

3

Des choses comme cela était simple.

Il y avait une liste de diffusion pour les utilisateurs et une pour les développeurs. Si vous voyez un problème et que vous pouvez y remédier, corrigez-le, puis exécutez le correctif de Larry Wall et envoyez le correctif résultant à la liste de devs avec une explication rapide de ce qu'il fait. Généralement un dev avec un accès en écriture au CVS (ou au bon vieux temps dont le projet résidait sur la disquette;)) vérifierait les choses et si votre patch fait ce qu'il dit sur la boîte et ne casse rien d'autre l'arbre source proprement dit.

De nos jours, il y a beaucoup plus de projets utilisant le développement ouvert et beaucoup d'entre eux sont gérés par des personnes qui n'ont jamais exécuté de projet logiciel et encore moins de logiciels ouverts. En général, l'envoi d'un correctif à quelqu'un qui fait beaucoup de dev dans la bonne partie du projet fait que les bons yeux le regardent rapidement même aujourd'hui. Une consultation du référentiel en ligne vous dira les gens qui font le travail plutôt que ceux qui obtiennent leurs noms sur la première page du site Web, contactez ces gars d'abord :)

7

La meilleure façon de faire est de vous présenter comme ceci "Bonjour, Voici un bug/fonctionnalité et voici un patch qui corrige/implémente." Je fais partie de quelques projets open source, et il y a beaucoup de personnes avec les meilleures intentions pour aider mais qui ne font jamais rien, donc si vous vous présentez avec du code de travail, vous serez considéré comme beaucoup plus utile.

3

Un couple d'autres choses à garder à l'esprit:

  • Soyez certain que vous possédez réellement le code que vous voulez contribuer, et non votre employeur ou le client vous fait les modifications pour. Vérifiez votre contrat de travail ou contrat de service s'il y a une possibilité que vous soyez dans une telle situation.

  • Étudiez s'il existe un processus d'attribution de propriété intellectuelle que les développeurs préfèrent suivre. De nos jours, de nombreux projets Open Source ont de telles affectations, de sorte que tous les droits sur le code dans le projet peuvent être la propriété du projet lui-même et/ou de son sponsor.

Ces deux éléments sont importants en matière de vous protéger, le projet, et tous ceux qui veulent utiliser ou de construire sur le projet en aval des réclamations liées au code que vous avez écrit.

4

En tant que créateur de plusieurs projets open source, je suis de l'autre côté des choses en ce sens que j'essaye d'obtenir des contributeurs. Voici ce que je dirais:

  • Annoncez-vous de la manière qui convient pour le projet: email, mailing list, forum, etc
  • Voir si votre idée est déjà dans les œuvres. Si oui, essayez peut-être d'aider plutôt que de dupliquer les efforts.
  • Découvrez le moyen préféré de soumettre le code
  • Assurez-vous de suivre les styles de codage utilisés dans le projet. (Si vous décidez de convertir tous les onglets en espaces, ils ne pourront pas fusionner facilement vos modifications dans leur système de contrôle de version et ignoreront probablement votre soumission.)
0

Parlez en IRC ou parcourez les newsgroups s'ils en ont un. fais-toi connaître. Vous devrez peut-être envoyer des correctifs à un groupe de discussion avant de recevoir un compte pour vous soumettre.

Familiarisez-vous avec les normes de codage, les types de correctifs (par exemple, diff unifié) et extrayez une copie de leur CVS ou SVN s'ils autorisent un accès anonyme.

3

Si vous cherchez des façons de vous impliquer à plus petite échelle (peut-être de progresser) OpenHatch a une base de données consultable de bogues (classés par langue/cadre) ainsi qu'un excellent tutoriel pour commencer.

Une autre façon de commencer est CodeTriage qui a GitHub repos à la recherche d'aide pour résoudre les problèmes ouverts qui sont également organisés par langue.

+0

OpenTriage est en panne. –

+1

merci @ Jens-AndréKoch, ils ont changé pour CodeTriage. Réponse mise à jour en conséquence. – rouma7

Questions connexes