14 Möglichkeiten, zu Solr beizutragen, ohne ein Programmiergenie oder ein Rockstar zu sein

Letzte Woche hat der ehrwürdige Andy Lester seine„14 Wege, zu Open Source beizutragen, ohne ein Programmiergenie oder ein Rockstar zu…

Letzte Woche hat der ehrwürdige Andy Lester seine„14 Wege, zu Open Source beizutragen, ohne ein Programmiergenie oder ein Rockstar zu sein“ veröffentlicht. Es ist eine großartige Liste, und ich empfehle jedem, der sich für Open Source interessiert, sie zu lesen – aber ich dachte, es könnte für die Leser dieses Blogs besonders hilfreich sein, zu erwähnen, wie jeder dieser Punkte auf Solr zutrifft.

Mit dem Zuhören beginnen

• Treten Sie einer Mailingliste bei: solr-user@lucene ist die Hauptliste für benutzerbezogene Fragen und Diskussionen über die Funktionsweise von Solr – sie ist definitiv der richtige Ort, um den Puls der Gemeinschaft zu fühlen. Wenn Sie sich mehr für die Entwicklung von Solr interessieren, sollten Sie sich bei dev@lucene anmelden.
• Folgen Sie einem Blog: Wenn Sie dies lesen, dann kennen Sie vermutlich bereits den Lucid Imagination Blog, aber einige andere Blogs (und Blog-Aggregatoren), die ich persönlich jeden Tag besuche, sind Search Workings, die Solr-Lucene Zone @ DZone und Planet Apache. (Planet Apache ist ein Aggregator von Blogs aller Apache-Committer, so dass viele der Beiträge, die Sie dort finden, nichts mit Solr zu tun haben, aber es ist trotzdem eine großartige Quelle).
• Treten Sie einem IRC-Kanal bei: Der Kanal #solr auf freenode ist in der Regel rund um die Uhr gut besucht. Die meisten Leute helfen sich gegenseitig bei kleinen Fragen und verweisen auf die Dokumentation. Es gibt auch einen (protokollierten) #lucene-dev-Kanal, in dem sich einige der Lucene/Solr-Entwickler aufhalten, um in Echtzeit über die Entwicklung der Interna zu diskutieren.

Mit Tickets arbeiten

Solr verwendet issues.apache.org für die Verfolgung von Problemen (d.h. Bugs und Feature Requests). Jeder kann ein Jira-Konto anlegen, um neue Probleme zu erstellen, bestehende Probleme zu kommentieren oder Patches hochzuladen.

• Diagnostizieren Sie einen Fehler: Es kommt recht häufig vor, dass Benutzer Fehlerberichte einreichen, die nicht detailliert genug sind, damit ein Entwickler schnell erkennen kann, wo das Problem liegt. Eine Möglichkeit, Ihnen zu helfen, besteht darin, neue Bugs zu überprüfen und zu versuchen, das Problem zu reproduzieren – entweder anhand der angegebenen Schritte, wenn diese detailliert genug sind, oder indem Sie versuchen, anhand von Beispielen wie den Solr-Beispielkonfigurationen und -daten herauszufinden, welche Schritte erforderlich sein könnten. Selbst wenn Sie nicht herausfinden können, wo im Code das Problem liegt, kann es sehr hilfreich sein, wenn Sie einen Kommentar abgeben, der bestätigt, dass das Problem reproduzierbar ist, oder den Berichterstatter darauf hinweist, welche Informationen Sie bei der Reproduktion vermisst haben, oder bestimmte Schritte dokumentiert, die andere Personen befolgen können, um das Problem zu reproduzieren.
• Behobene Bugs schließen: Die Standardprozedur, die bei Solr befolgt wird, besteht darin, Probleme zu „lösen“, sobald sie behoben sind, und sie zu „schließen“, sobald sie veröffentlicht wurden. Streng genommen ist das „Schließen“ von behobenen Fehlern also nichts, was Mitglieder der Gemeinschaft tun sollten. Der Sinn dieses Vorschlags bleibt jedoch bestehen: Wenn Sie ein Problem sehen, von dem Sie bestätigen können, dass es bereits behoben wurde, sei es aufgrund von Doppelmeldungen oder als Nebeneffekt einer anderen Änderung, kommentieren Sie bitte das Problem mit den Details, damit ein Committer weiß, dass es sicher behoben werden kann.

Arbeiten mit Code

Wer sich für die Arbeit an der Lucene/Solr-Codebasis interessiert, sollte zunächst die Seite How To Contribute im Solr-Wiki lesen. Dort finden Sie alle Informationen, die Sie für den Einstieg benötigen.

• Testen Sie eine Beta-Version oder einen Release Candidate: Auch wenn Sie Java-Code nicht verstehen oder nicht wissen, wie man ihn kompiliert, können Sie uns jederzeit dabei helfen, unveröffentlichte Versionen zu testen, bevor sie offiziell werden. Nightly Builds sind auf unserem Continuous Integration Server jederzeit verfügbar, und Release Candidates werden mindestens 72 Stunden lang auf der Mailingliste dev@lucene angekündigt und diskutiert, bevor sie zu offiziellen Versionen werden. Testen Sie eine dieser Versionen und melden Sie uns alle Fehler, die Ihnen auffallen, oder alle Merkwürdigkeiten, die Sie bei der Verpackung oder dem Verhalten des Codes feststellen, sind sehr hilfreich.
• Beheben Sie einen Fehler: Scheuen Sie sich nicht, einen Patch einzureichen, der einen Fehler behebt. Denken Sie immer an Yoniks Gesetz der Patches…
  

  Ein halbfertiger Patch in Jira, ohne Dokumentation, ohne Tests und ohne Abwärtskompatibilität ist besser als gar kein Patch.

• Schreiben Sie einen Test: Selbst wenn Sie nicht verstehen, wie Sie einen Fehler beheben können, kann das Schreiben eines Unit-Tests, der die Existenz eines Fehlers demonstriert, anderen Entwicklern helfen, das Problem zu verstehen und der Community insgesamt Arbeit ersparen. Ebenso hilft das Schreiben von Tests für bestehende Funktionen, die zeigen, dass sie funktionieren, uns davor zu schützen, dass in Zukunft Fehler eingeführt werden, und kann als Beispiel für die Funktionalität dienen. Wenn Sie nach vorhandenem Code suchen, der mehr Tests gebrauchen könnte, finden Sie in den nächtlichen Builds Berichte über die Testabdeckung von Clover, damit Sie sehen können, welcher Code von den Tests beansprucht wird (und welcher nicht).
• Eine Compiler-Warnung ausschalten: Solr hat mehr als seinen gerechten Anteil an Compiler-Warnungen, meist aufgrund der Verwendung von Rohtypen gegenüber Java Generics. Wir können immer etwas Hilfe gebrauchen, um die Liste zu verkleinern, indem wir einige dieser Warnungen überprüfen, um festzustellen, ob sie durch eine Optimierung der Typsignaturen behoben werden können oder ob sie mit einer Annotation unterdrückt werden sollten.
• Fügen Sie einen Kommentar hinzu: Wenn Sie einen Code lesen, der Sie zunächst verwirrt, der aber, wenn Sie etwas tiefer graben, einen Sinn ergibt, können Sie einen Patch mit einem vorgeschlagenen Kommentar einreichen, in dem Sie erklären, was Sie gefunden haben, damit der Code in Zukunft für andere leichter zu verstehen ist.

Beiträge von Benutzern, die einen der oben genannten Punkte erfüllen, sind immer willkommen. Der beste Weg, diese Art von Beiträgen zu leisten, ist, den Stamm-Quellcode auszuchecken, Ihre Änderungen vorzunehmen und dann eine Patch-Datei zu erstellen. Erstellen Sie dann eine neue Meldung (sofern noch keine vorhanden ist) und hängen Sie Ihren Patch an.

Mit Dokumentation arbeiten

Die meiste Solr-Dokumentation für „Endbenutzer“ (d.h. Nicht-Entwickler) finden Sie im Solr-Wiki, das von jedem, der ein Konto erstellt, öffentlich bearbeitet werden kann. Frische Augen sind absolut hilfreich, wenn es darum geht, Mängel in der Dokumentation zu erkennen. Verbesserungen durch neue Benutzer, die sich beteiligen möchten, sind also immer willkommen.

• Erstellen Sie ein Beispiel: Das kanonische Solr-Beispiel ist in den Solr-Versionen enthalten, zusammen mit einem Tutorial, das neue Benutzer durch einige der grundlegenden Funktionen führt – aber dieses Tutorial kratzt kaum an der Oberfläche dessen, was Solr tun kann. Patches, die das bestehende Tutorial um neue Informationen ergänzen, sind immer willkommen, aber ebenso wertvoll ist es, wenn Menschen ihre eigenen Beispiele für die Verwendung von Solr veröffentlichen. Blogbeiträge sind großartig, aber öffentlich verfügbarer Code/Konfigurationen auf Websites wie SourceForge oder github sind noch besser.

Arbeit in der Gemeinde

Ein inoffizielles Motto der Apache Software Foundation lautet „Community Over Code“ – die wichtigste Art und Weise, wie Sie bei Solr mithelfen können, ist die Teilnahme an der Community.

• Beantworten Sie eine Frage: Hilfe bei der Beantwortung von Fragen auf der Mailingliste solr-user und im IRC-Kanal #solr ist immer willkommen. Viele Leute brauchen einfach nur Hilfe beim Verständnis der Terminologie und freundliche Hinweise auf die vorhandene Dokumentation.
• Schreiben Sie einen Blogbeitrag: Blogs, Artikel, WebCasts und Konferenzpräsentationen über Solr sind immer willkommen und werden gefördert.
• Verbessern Sie eine Website: Die gesamte Lucene-Website wurde kürzlich auf das MarkDown-basierte Apache CMS umgestellt. Jeder kann die Quelldateien der Website auschecken, Änderungsvorschläge zu den Vorlagen oder Inhalten machen und einen Patch mit Ihren Vorschlägen einreichen. Personen mit guten CSS-, JavaScript- und UI-Usability-Kenntnissen sind ebenfalls aufgerufen, Verbesserungen an der Solr Admin UI vorzuschlagen.

Ich überlasse es Andy, das besser zusammenzufassen, als ich es könnte…

Es gibt so viele Möglichkeiten, zu Open Source beizutragen, wenn wir über die offensichtlichen Schritte des Schreibens einer neuen Produktfunktion hinausblicken. Jeder, der Open Source nutzt, kann seine Fähigkeiten in die Gemeinschaft einbringen und dazu beitragen, dass Open Source ein wichtiger Teil der Computerwelt bleibt.