Comment proposer un changement de code au projet open source?

Question

Je suis en train de lire le code d'un projet open source. Je vois que dans un des endroits le code n'est pas bien écrit et pourrait être changé un peu pour augmenter la lisibilité/design/tout ce qui améliore le code et facilite le travail avec ce code.

Existe-t-il un moyen courant de signaler de tels changements? Je sais que vous pouvez devenir un contributeur, faire un patch, suggérer quelque chose. Mais si vous ne voulez pas consacrer trop de votre temps à ce projet, vous venez de télécharger, lire, penser à un changement, l'a écrit, posté quelque part comme une suggestion.

En fait, je préférerais pouvoir poster des suggestions pour que tout le monde puisse les voir et c'est comme apprendre avec la communauté, mais juste faire preuve de souplesse.

Answer 1

Vous pouvez poster des extraits avec des commentaires sur le forum du projet, le suivi des bugs ou la liste de diffusion. Chaque projet gère les communications et les rapports de manière différente. Exemple: J'ai entendu dire que les devs de Mozilla ont tendance à ignorer les commentaires sur Bugzilla, donc ce n'est peut-être pas un bon endroit pour commenter les changements de Firefox.

Si vous voulez écrire une très longue pièce, il vaudrait peut-être mieux en faire un blog, puis un lien vers celui-ci. Je ferais attention au ton de tes mots. Les choses peuvent être ainsi pour de bonnes raisons. Essayez de comprendre où ils vont avec le projet et leur calendrier. Demandez peut-être pourquoi les choses sont ainsi, et indiquez clairement quel pourrait être le problème et qui pourrait être touché.

Faire des correctifs pour les changements est considéré comme une bonne pratique et encourage les gens à accepter vos contributions. Si vous n'êtes pas en train de créer des correctifs pour des projets, il est souvent moins rapide de créer un correctif pour quelque chose comme ça, mais cela peut vous donner plus d'influence influence. Mon opinion personnelle est que c'est une bonne chose. Il sépare le blé de l'ivraie en termes de soumissions et les gens doivent être persistants.

Answer 2

À moins que vos efforts pour résoudre un projet particulier satisfassent une sorte de requeriment minimal, sera-t-il seulement possible d'y contribuer. Il faut un certain temps pour adapter votre changement, regarder votre patch, vérifier, intégrer, etc. Et si vous passez trop peu de temps, il est plus probable que votre patch soit de mauvaise qualité, aborde un problème déjà discuté ou soit un simple malentendu des concepts. Ainsi, les développeurs, qui travaillent pour la plupart gratuitement, risquent de perdre un temps précieux à regarder votre patch avec la probabilité de le réécrire complètement et de perdre du temps qu'ils allaient consacrer à des problèmes plus importants. Mais si vous passez plus de temps à travailler, ce serait moins risqué pour eux. Comment déterminer vous avez travaillé beaucoup? Eh bien, alors l'effort requis pour contacter les développeurs serait une fraction plus petite de votre effort total, donc vous ne trouverez pas problématique de surmonter une sorte de bureaucratie dans les problèmes de reporting.

Les moyens les plus rapides sont les suivantes:

• Poster le patch à la liste de diffusion avec une brève description.
• Allez sur le canal IRC du projet et collez le patch, en vous assurant que quelqu'un d'éligible en prendra soin.
• Lancez un bug dans leur bug tracker, décrivez brièvement un bug ou une amélioration et attachez-y votre patch.

Trop complexe? Ha! Pour contribuer au projet OpenJDK, vous devez signer un accord et l'envoyer à Sun (par courrier ordinaire ou par fax). Eh bien, c'est ce que «complexe» signifie!Et inscrivez-vous dans bugzilla, activez votre compte et ouvrez un problème avec un correctif est pas complexe.

Answer 3

Pour commencer, aux Pays-Bas il y a un dicton qui dit quelque chose comme ceci:

« conseils que personne n'a demandé est rarement apprécié »

Si vous voulez aider, alors assurez-vous que vous êtes utile. N'essayez pas d'avoir l'air intelligent en signalant simplement les erreurs des autres sans plus vous aider. Cela ne va pas profiter au projet, cela démotive les développeurs, et ça va vous faire mal paraître. En outre, le rédacteur du logiciel est probablement plus conscient des problèmes qui menacent le projet que vous.

Bon exemple:

«.? J'ai vu que j'ai une bonne expérience avec z Avez-vous déjà pensé que dans le code que vous utilisez la technique x et y en utilisant cette »

Bon exemple:.

« Hé, j'utilise ce logiciel tous les jours avec un grand plaisir que j'ai remarqué que le chargement des fichiers est un peu lent j'ai vérifié le code et je suggère. mettre en cache le résultat de x et y entre les itérations Malheureusement, je n'ai pas le temps de faire un patch, donc j'ai signalé le problème avec ma suggestion dans votre bugtracker. "

Bad exemple:..

« Mec, je cherche juste dans votre code Man, quel gâchis Tout Noob sait que vous devez utiliser des noms utiles pour les variables Pas étonnant que le logiciel est. tous instables. "

Pour être bref, assurez-vous que vos commentaires sont positifs.