Dinge, die Sie beachten sollten, wenn Sie sich für CRuby entscheiden

Vorsichtsmaßnahmen

** Der Inhalt dieses Artikels lautet möglicherweise nicht "das ist alles". Lesen Sie die Community Air, bevor Sie sich verpflichten **

Motivation

Ich wollte mich für CRuby engagieren, aber leider sind die Informationen verstreut und etwas schwierig zu tun. Ich hatte das Gefühl, dass dies ein Artikel für diejenigen ist, die sich so weit wie möglich für CRuby engagieren möchten.

Grundlegende offizielle Informationen

CONTRIBUTING.md in der Quelle ist wie folgt.

Please see the official issue tracker and wiki HowToContribute.

Issue Tracker ist eine normale Redmine und neue Tickets werden nach der Registrierung eines Kontos hinzugefügt. Der Inhalt von HowToContribute ist sehr einfach und übersetzt ... (Er kann in Zukunft alt werden. ** Bitte lesen Sie den Inhalt von CONTRIBUTING.md direkt vor dem Posten des Patches! **)

Vor dem Senden des Patches

Nur Ruby 2.2 kann neue Funktionen hinzufügen. 1.9 / 2.0 / 2.1 akzeptiert keine neuen Funktionserweiterungen, und Wartungszweige wie 2.1 führen keine neuen Funktionserweiterungen zusammen. --Suchen Sie nach früheren Diskussionen in Ruby-Core.

Stellen Sie sicher, dass Ihr Code unter einer Ruby-Lizenz verteilt oder geändert wird. Die Lizenz kann sich in Zukunft ändern. Wenn Sie mit der Lizenzänderung nicht einverstanden sind, nehmen Sie unbedingt an der Diskussion teil.

Was wird vom Patch angefordert?

Meistens sollten Sie es an den Ruby 2.2-Trunk senden. (Andernfalls nur beim Senden von Bugfix-Patches für Fehler, die zum Zeitpunkt des Wartungszweigs vorhanden waren.) --Bitte stellen Sie sicher, dass Sie im einheitlichen Diff-Format senden. (diff-pu ist vorzuziehen. git oder svn diff ist auch gut.)

Achten Sie darauf, keine Änderungen am Erscheinungsbild Ihres Codes vorzunehmen. (Folgen Sie dem Codierungsstil des Originalcodes.)

Schließen Sie nicht mehrere Änderungen in ein Commit ein

So senden Sie --Erstellen Sie ein Redmine-Ticket als Fehler oder Feature. Dann wird es auf Ruby-Core (und Ruby-Dev) übertragen. --Pull-Anfragen für Github werden auch für kleinere Korrekturen akzeptiert. Pull-Anfragen, die kontroversen Inhalt enthalten, werden jedoch einfach ignoriert.

Nach dem Senden

Tickets können bei einem Unfall ignoriert werden. (Der Prüfer ist beispielsweise beschäftigt.) In diesem Fall senden Sie bitte einen Ping mit einem Ticket.

Lizenz

Stellen Sie sicher, dass Ihr Patch unter einer Ruby-Lizenz behandelt wird. Wenn Sie die Lizenz ändern, werden wir der Änderung der Lizenz zustimmen, sofern Sie nichts dagegen haben.

Diskussion auf dem Ticket

Diese Informationen sind jedoch nicht die einzigen Informationen. Verfolgen wir den Inhalt von Ruby-Dev und andere Diskussionen über Redmine-Tickets Zum Beispiel https://bugs.ruby-lang.org/issues/10032 Hier gibt es eine solche Diskussion (obwohl es sich um ein leicht gerahmtes Ticket handelt ...)

Github ist ein Nebeneffekt

Für diejenigen, die eine Überprüfung benötigen, wird empfohlen, den Patch zuerst an Redmine, den offiziellen Issue Tracker, zu senden.
(Dies selbst ist auch in HowToContribute geschrieben, aber das Lesen zeigt deutlich, dass Github ein Hilfsmittel ist.)

Der Betreuer jeder Bibliothek ist für die Wartung der standardmäßigen angehängten Ruby-Bibliothek verantwortlich.

Es liegt beim Betreuer, was mit dem Patch zu tun ist ――So was mit dem Patch zu tun ist, sollte mit dem Betreuer ausgehandelt werden ――Es ist auch eine gute Idee, zuerst einen Edelstein zu erstellen, um das Sprechen zu erleichtern. ――Wenn der Betreuer beschäftigt ist, kann sich die Annahme verzögern (bei diesem Ticket handelt es sich um eine Einheit von mehreren Monaten oder mehr). ――Aber in diesem Fall senden Sie bitte einen Ping, ohne sich auf dem Ticket darum zu kümmern.

Ich möchte, dass Sie einen Beitrag leisten und nicht nur kritisieren ――Jeder tut es als Freiwilliger, deshalb möchte ich, dass Sie dazu beitragen und es kritisieren.

(Es ist wünschenswert, die "Gastfreundschaft" zu erhöhen.)

Usw. kann gelesen werden.

Es gibt ein Problem, dass die Arbeit überfordert ist, es geht auch darum, die neueste Atmosphäre der Community zu erhalten, und ich denke, dass es gut ist, zuerst die Tickets anderer Patches zu lesen.

Das Aussehen nicht verändern

Ich möchte Korrekturen vornehmen, um den Codierungsstil nicht zu ändern. Es kann zerstört werden, wenn der ursprüngliche Codierungsstil nicht gut gelesen wird. Ich habe neulich einen Patch an iseq.c gesendet (nicht akzeptiert), bin aber darauf getreten.

Zu dieser Zeit schien es mir, dass der ursprüngliche Code eine Mischung aus Tabulatoren und Leerzeichen war, der Einzug nicht eingerückt war und der Funktionsumfang eingerückt war. Und ich habe versucht, es so gut wie möglich zusammenzubringen, aber es gab keinen gesunden Menschenverstand. Richtig, die Registerkarten sehen aus wie 8 Registerkarten, die alle 4 Leerzeichen eingerückt werden. Wenn jedoch 8 Leerzeichen erreicht sind, ersetzen Sie sie durch Registerkarten. Es war der Stil.

Verwenden Sie den gesunden Menschenverstand und lesen Sie den Code richtig. Ich denke, es kann vermieden werden, wenn Sie über etwas Besseres nachdenken und handeln, anstatt die Regeln und Formate seltsam zu befolgen. (Es ist ein Rubyist.)

Weitere Hinweise

Das Wichtigste ist wahrscheinlich die Gastfreundschaft. Denken Sie daran, dass jeder ein Freiwilliger ist.