** Le contenu de cet article peut ne pas être "tout cela". Lisez l'air de la communauté avant de vous engager **
Je voulais m'engager dans CRuby, mais malheureusement les informations sont éparses et un peu difficiles à faire. J'ai senti que c'était un article pour ceux qui veulent s'engager le plus possible dans CRuby.
CONTRIBUTING.md inclus dans la source est le suivant.
Please see the official issue tracker and wiki HowToContribute.
Le suivi des problèmes est un Redmine normal, et de nouveaux tickets sont ajoutés après l'enregistrement d'un compte. Le contenu de HowToContribute est très simple, et une fois traduit ... (Il peut devenir ancien à l'avenir. ** Veuillez lire le contenu de CONTRIBUTING.md directement avant de publier le patch! **)
- Avant d'envoyer le patch --Seul Ruby 2.2 peut ajouter de nouvelles fonctionnalités. 1.9 / 2.0 / 2.1 n'acceptera pas les ajouts de nouvelles fonctionnalités, et les branches de maintenance comme 2.1 ne fusionneront pas les nouvelles fonctionnalités. --Recherchez les discussions précédentes dans ruby-core.
- Assurez-vous d'accepter que votre code sera distribué ou modifié sous une licence Ruby. La licence peut changer à l'avenir, mais si vous n'êtes pas d'accord avec le changement de licence, assurez-vous de participer à la discussion.
- Ce qui est demandé par le patch
- La plupart du temps, vous devez l'envoyer au coffre Ruby 2.2. (Sinon, uniquement lors de l'envoi de correctifs de correction de bogues pour les bogues qui existent au moment de la branche de maintenance) --Veuillez vous assurer d'envoyer au format diff unifié. (diff -pu est préférable. git ou svn diff est également bon.)
- Veillez à ne pas modifier l'apparence de votre code. (Suivez le style de codage du code d'origine) --Ne pas inclure plusieurs changements dans un même commit
- Comment envoyer --Créez un ticket Redmine en tant que bogue ou fonctionnalité. Ensuite, il sera transféré vers ruby-core (et ruby-dev)
- Les demandes d'extraction sur Github sont également acceptées pour les corrections mineures. Cependant, les demandes d'extraction contenant un contenu controversé sont simplement ignorées.
- Après l'envoi
- Les billets peuvent être ignorés en cas d'accident. (Par exemple, le réviseur est occupé, donc.) Dans ce cas, veuillez envoyer un ping avec un ticket.
- Licence
- Assurez-vous d'accepter que votre patch sera géré sous une licence Ruby. De plus, lorsque vous modifiez la licence, à moins que vous ne vous y opposiez, nous considérerons que vous avez accepté le changement de licence.
Cependant, ces informations ne sont pas les seules. Suivons le contenu de ruby-dev et d'autres discussions sur les billets Redmine Par exemple, https://bugs.ruby-lang.org/issues/10032 Il y a une telle discussion (bien que ce soit un ticket légèrement encadré ...), ici
Etc. peut être lu.
Il y a un problème que le travail soit débordé, c'est aussi pour avoir la dernière ambiance de la communauté, et je pense qu'il est bon de lire d'abord les tickets des autres patchs.
Je souhaite apporter des corrections pour ne pas changer le style de codage, Il peut être détruit si le style de codage d'origine n'est pas bien lu. J'ai envoyé un correctif à iseq.c l'autre jour (non accepté), mais j'ai marché dessus.
À ce moment-là, il me semblait que le code d'origine était un mélange de tabulations et d'espaces, l'indentation if n'était pas indentée et la portée de la fonction était indentée. Et j'ai essayé de faire correspondre autant que possible, mais il n'y avait pas de bon sens. Correctement, l'onglet ressemble à 8 onglets, en retrait tous les 4 espaces, mais lorsqu'il atteint 8 espaces, remplacez-le par une tabulation. C'était le style.
Faites preuve de bon sens et lisez correctement le code. Je pense que cela peut être évité si vous pensez à quelque chose de mieux et agissez plutôt que d'obéir étrangement aux règles et aux formats. (C'est un rubisiste.)
L'important est probablement l'hospitalité. N'oubliez pas que tout le monde est bénévole.
Recommended Posts