So pflegen Sie Open Source-Softwareprojekte

Einführung

Wenn Sie ein Open-Source-Software-Repository verwalten, übernehmen Sie eine Führungsrolle. Unabhängig davon, ob Sie der Gründer eines Projekts sind, das es der Öffentlichkeit zur Verwendung und für Beiträge zur Verfügung gestellt hat, oder in einem Team arbeiten und einen bestimmten Aspekt des Projekts pflegen, Sie werden einen wichtigen Service für die Allgemeinheit erbringen Entwickler-Community.

Während Open-Source-contributions through pull requestsaus der Entwicklergemeinde entscheidend dafür sind, dass Software für Endbenutzer so nützlich wie möglich ist, haben Betreuer einen echten Einfluss auf die Gestaltung des Gesamtprojekts. Repository-Betreuer sind stark in die von ihnen verwalteten Open-Source-Projekte eingebunden, von der täglichen Organisation und Entwicklung bis hin zur Kommunikation mit der Öffentlichkeit und der Bereitstellung von zeitnahem und effektivem Feedback für die Mitwirkenden.

Dieses Handbuch führt Sie durch einige Tipps zur Pflege öffentlicher Repositorys für Open-Source-Software. Als Leiter eines Open-Source-Projekts tragen Sie sowohl technische als auch nichttechnische Aufgaben, um eine Nutzerbasis und Community für Ihr Projekt zu schaffen. Die Übernahme der Rolle eines Betreuers ist eine Gelegenheit, von anderen zu lernen, Erfahrungen mit dem Projektmanagement zu sammeln und zu beobachten, wie Ihr Projekt wächst und sich ändert, wenn Ihre Benutzer zu investierten Mitwirkenden werden.

Nützliche Dokumentation schreiben

Eine gründliche, gut organisierte Dokumentation, die den beabsichtigten Communitys Ihres Projekts dient, trägt zur Erweiterung Ihrer Benutzerbasis bei. Mit der Zeit wird Ihre Benutzerbasis zu den Mitwirkenden Ihres Open-Source-Projekts.

Da Sie den Code, den Sie gerade erstellen, ohnehin durchdenken und möglicherweise sogar Notizen machen, kann es sich lohnen, die Dokumentation in Ihren Entwicklungsprozess einzubeziehen, solange Sie sich noch im Kopf befinden. Möglicherweise möchten Sie die Dokumentation sogar vor dem Code schreiben. Dabei sollten Sie der Philosophie eines dokumentationsgesteuerten Entwicklungsansatzes folgen, bei dem Features zuerst dokumentiert und diese Features nach dem Ausschreiben ihrer Funktion entwickelt werden.

Neben Ihrem Code gibt es einige Dokumentationsdateien, die Sie in Ihrem Hauptverzeichnis aufbewahren möchten:

Dokumentation kann in vielen Formen vorliegen und unterschiedliche Zielgruppen ansprechen. Je nach Umfang Ihrer Arbeit können Sie sich als Teil Ihrer Dokumentation für eine oder mehrere der folgenden Aktionen entscheiden:

  • Ageneral guide, um Benutzer in das Projekt einzuführen

  • Tutorials, um Menschen durch verschiedene Anwendungsfälle zu führen

  • FAQs, um häufig gestellte Fragen zu beantworten, die Benutzer möglicherweise haben

  • Troubleshooting guides, um Benutzern bei der Lösung von Problemen zu helfen

  • EinAPI reference bietet Benutzern eine schnelle Möglichkeit, API-Informationen nachzuschlagen

  • Release notes mit bekannten Fehlern, damit Benutzer wissen, was sie in jeder Version erwarten können

  • Planned features, um zu verfolgen und zu erklären, was in Zukunft auf uns zukommt

  • Video walkthroughs, um Benutzern einen multimedialen Ansatz für Ihre Software bereitzustellen

Ihr Projekt eignet sich möglicherweise besser für bestimmte Arten von Dokumentationen als andere. Wenn Sie jedoch mehr als einen Ansatz für die Software angeben, kann Ihre Benutzerbasis besser verstehen, wie Sie mit Ihrer Arbeit interagieren.

Beim Schreiben von Dokumentationen oder Aufzeichnen von Sprache für ein Video ist es wichtig, so klar wie möglich zu sein. Es ist am besten, keine Annahmen über die technischen Fähigkeiten Ihres Publikums zu treffen. Sie sollten Ihre Dokumentation auch von oben nach unten betrachten, dh erläutern, wie Ihre Software im Allgemeinen funktioniert (z. B. Serveraufgaben automatisieren, eine Website erstellen, Sprites für die Spieleentwicklung animieren), bevor Sie auf Details eingehen.

Obwohl Englisch eine universelle Sprache im Technologiebereich geworden ist, möchten Sie immer noch überlegen, wer Ihre erwarteten Benutzer sind und wie Sie sie erreichen können. Englisch ist vielleicht die beste Wahl, um Zugang zu einer breiten Anwenderbasis zu haben, aber Sie sollten bedenken, dass sich viele Leute Ihrer Dokumentation als nicht-englische Muttersprachler nähern. Arbeiten Sie also, um eine unkomplizierte Sprache zu bevorzugen, die nicht verwirrt Ihre Leser oder Zuschauer.

Versuchen Sie, die Dokumentation so zu verfassen, als würden Sie an einen Mitarbeiter schreiben, der über das aktuelle Projekt auf dem Laufenden gehalten werden muss. Schließlich möchten Sie potenzielle Mitwirkende ermutigen, Pull-Anforderungen an das Projekt zu richten.

Probleme organisieren

Issues sind normalerweise eine Möglichkeit, Fehler zu verfolgen oder zu melden oder neue Funktionen anzufordern, die der Codebasis hinzugefügt werden sollen. Open-Source-Repository-Hosting-Dienste wie GitHub, GitLab und Bitbucket bieten Ihnen eine Schnittstelle für sich und andere, über die Sie Probleme in Ihrem Repository nachverfolgen können. Wenn Sie Open-Source-Code für die Öffentlichkeit freigeben, sollten Sie damit rechnen, dass die Benutzergemeinschaft Probleme aufwirft. Durch das Organisieren und Priorisieren von Problemen erhalten Sie einen guten Fahrplan für die anstehenden Arbeiten an Ihrem Projekt.

Da jeder Benutzer ein Problem einreichen kann, werden nicht alle Probleme Fehler melden oder Feature-Anfragen sein. Sie erhalten möglicherweise Fragen über das Issue-Tracker-Tool, oder Sie erhalten beispielsweise Anfragen nach kleineren Verbesserungen der Benutzeroberfläche. Es ist am besten, diese Probleme so gut wie möglich zu organisieren und den Benutzern mitzuteilen, die diese Probleme erstellen.

Probleme sollten konkrete Aufgaben darstellen, die im Quellcode ausgeführt werden müssen, und Sie müssen sie entsprechend priorisieren. Sie und Ihr Team wissen, wie viel Zeit und Energie Sie oder Ihre Mitarbeiter für die Bearbeitung der eingereichten Fragen aufgewendet haben, und Sie können gemeinsam Entscheidungen treffen und einen umsetzbaren Plan erstellen. Wenn Sie wissen, dass Sie nicht in der Lage sind, innerhalb eines kurzen Zeitraums zu einem bestimmten Problem zu gelangen, können Sie das Problem dennoch kommentieren, um dem Benutzer mitzuteilen, dass Sie das Problem gelesen haben und dass Sie es nach Möglichkeit beheben können. und wenn Sie in der Lage sind, können Sie einen erwarteten Zeitplan angeben, in dem Sie das Problem erneut untersuchen können.

Bei Problemen, bei denen es sich um Funktionsanfragen oder -verbesserungen handelt, können Sie die Person, die das Problem eingereicht hat, fragen, ob sie selbst Code beisteuern kann. Sie können sie an die DateiCONTRIBUTORS.mdund jede andere relevante Dokumentation weiterleiten.

Da Fragen oft keine konkreten Aufgaben darstellen, kann es eine gute Option sein, das Problem zu kommentieren, um den Benutzer höflich auf die relevante Dokumentation aufmerksam zu machen, damit Ihre Interaktionen professionell und freundlich bleiben. Wenn für diese Frage keine Dokumentation vorhanden ist, ist jetzt ein guter Zeitpunkt, um die relevante Dokumentation hinzuzufügen und dem Benutzer für die Identifizierung dieser Übersicht zu danken. Wenn Sie aufgrund von Problemen viele Fragen haben, können Sie einen FAQ-Bereich in Ihrer Dokumentation oder ein Wiki oder Forum erstellen, damit andere an der Beantwortung von Fragen teilnehmen können.

Wenn ein Benutzer ein Problem meldet, versuchen Sie, so freundlich und zuvorkommend wie möglich zu sein. Probleme sind Anzeichen dafür, dass Benutzer Ihre Software mögen und sie verbessern möchten!

Wenn Sie versuchen, Probleme so gut wie möglich zu organisieren, bleibt Ihr Projekt auf dem neuesten Stand und für die Benutzergemeinschaft relevant. Entfernen Sie Probleme, die außerhalb des Bereichs Ihres Projekts liegen oder veraltet sind, und priorisieren Sie die anderen, damit Sie kontinuierliche Fortschritte erzielen können.

Spenden Sie eine Belohnung

Je mehr Sie Mitwirkende zu Ihrem Projekt begrüßen und ihre Bemühungen belohnen, desto wahrscheinlicher werden Sie mehr Beiträge ermutigen. Um den Einstieg zu erleichtern, sollten Sie eineCONTRIBUTING.md-Datei in die oberste Ebene Ihres Repositorys und einen Zeiger auf diese Datei in IhreREADME.md-Datei aufnehmen.

Eine gute Datei mit Beiträgen beschreibt, wie Sie als Entwickler mit der Arbeit am Projekt beginnen können. Möglicherweise möchten Sie eine schrittweise Anleitung oder eine Checkliste für Entwickler bereitstellen, in der erläutert wird, wie der Code über eine Pull-Anforderung erfolgreich in das Projekt eingefügt werden kann.

Vergessen Sie nicht, neben der Dokumentation, wie Sie einen Beitrag zum Projekt leisten können, den Code durchgehend konsistent und lesbar zu halten. Code, der durch Kommentare und eine klare und konsistente Verwendung leicht zu verstehen ist, gibt den Mitwirkenden das Gefühl, in das Projekt einsteigen zu können.

Führen Sie abschließend eine Liste der Mitwirkenden oder Autoren. Sie können Mitwirkende einladen, sich der Liste hinzuzufügen, unabhängig von ihrem Beitrag (auch das Beheben von Tippfehlern ist wertvoll und kann in Zukunft zu weiteren Beiträgen führen). Auf diese Weise können Mitwirkende für ihre Arbeit an dem Projekt in einer Art und Weise öffentlich anerkannt werden, auf die sie verweisen können, und andere können darüber informiert werden, wie gut Mitwirkende behandelt werden.

Bauen Sie Ihre Community auf

Indem Sie Benutzer durch Dokumentation befähigen, auf Probleme reagieren und sie zur Teilnahme anregen, sind Sie bereits auf einem guten Weg, die Community rund um Ihr Open-Source-Projekt auszubauen. Benutzer, die Sie glücklich machen und die Sie als Mitarbeiter behandeln, werden wiederum für Ihre Software werben.

Darüber hinaus können Sie Ihr Projekt auf verschiedenen Wegen bewerben:

  • Bloggen

  • Veröffentlichung von Übersichts- oder exemplarischen Videos

  • Pflege einer Mailingliste

  • Auf Social Media-Kanälen aktiv sein

  • Zusammenarbeit mit ähnlichen oder verwandten Projekten und gegenseitige Förderung

Sie möchten Ihre Werbung auf den Umfang Ihres Projekts und die Anzahl der aktiven Teammitglieder und Mitwirkenden abstimmen, mit denen Sie zusammenarbeiten.

Wenn Ihre Community wächst, können Sie mehr Räume für die Interaktion von Mitwirkenden, Benutzern und Betreuern bereitstellen. Einige Optionen, die Sie in Betracht ziehen könnten, sind:

  • Wikis, die Dokumentation bereitstellen können, die auf Community-Ebene verwaltet wird

  • Foren zur Diskussion möglicher Funktionen und Beantwortung von Fragen

  • Ein Listenserver für E-Mail-basiertes Community-Engagement

Berücksichtigen Sie Ihre Kernnutzerbasis und den Umfang Ihres Projekts, einschließlich der Anzahl der Personen, die das Projekt verwalten, und der verfügbaren Ressourcen, bevor Sie diese potenziellen Bereiche einführen, und holen Sie Feedback von Ihrer Community ein, was für sie funktioniert.

Vor allem ist es wichtig, freundlich zu sein und in all Ihren Interaktionen mit Ihrer Gemeinde etwas Liebe zu zeigen. Ein liebenswürdiger Projektbetreuer zu sein ist nicht immer einfach, aber es wird sich für Ihr Projekt auf der ganzen Linie auszahlen.

Fazit

Repository-Betreuer sind in der größeren Open-Source-Community unglaublich wichtig. Obwohl es erhebliche Investitionen und harte Arbeit erfordert, ist es oft eine lohnende Erfahrung, die es Ihnen ermöglicht, als Entwickler und Mitwirkender zu wachsen. Ein zugänglicher und freundlicher Betreuer zu sein, kann einen großen Beitrag zur Entwicklung eines Projekts leisten, das Ihnen am Herzen liegt.