Teilen Sie:
){kind=small}
Lorna ist eine Software-Ingenieurin mit einer unheilbaren Blogging-Sucht. Sie versucht, Worte und Code gleichermaßen zu bändigen.
Das Hacktoberfest überleben: Ein Leitfaden für Maintainer
Lesedauer: 5 Minuten
Ein frohes Hacktoberfest für alle! Mitwirkende, ich hoffe, Sie haben eine wunderbare Zeit, um neue Fähigkeiten zu erlernen und Projekte zu entdecken, bei denen Sie etwas bewirken können. Maintainer, der heutige Beitrag ist nur für euch. Hoffentlich bedeuten die Regeländerungen eine bessere Qualität der Pull Requests für Ihre Projekte, aber es kann immer noch eine Menge zu tun sein. Ich bin ein langjähriger Maintainer und möchte Ihnen heute einige Tipps geben, die Ihnen hoffentlich weiterhelfen.
Vonage ist begeistert, ein Partner des Hacktoberfest 2020 zu sein. Wir sind sind keine Fremden in Sachen Open SourceUnsere Bibliotheken, Codeschnipsel und Demos befinden sich alle auf GitHub. Um voll und ganz in die Festivitäten einzutauchen, besuchen Sie bitte unsere Hacktoberfest-Seite für Details über alles, was wir geplant haben!
Die Betreuer von Open-Source-Projekten machen diese Arbeit meist in ihrer "Freizeit", und das ist eine Menge. Es ist nicht nur für Hacktober, und eine Menge der Arbeit kann ziemlich unsichtbar sein. Bei diesem Hacktoberfest, vor allem mit den globalen Ereignissen um uns herum, ist es wichtig, seine Prioritäten zu überdenken und sie im Auge zu behalten!
Ich würde vorschlagen, dass Sie, Ihr Projekt und dann seine Mitwirkenden, in dieser Reihenfolge, eine gute Reihenfolge der Prioritäten ist. Ein Projekt ist nichts ohne Betreuer, und viele sind Teams mit einem Betreuer. Die Ziele des Projekts sind eine wichtige Priorität; es gibt keinen Druck, den Umfang zu erweitern oder das Projekt umzukrempeln, nur weil ein Pull Request eingetroffen ist, um das zu tun. Das Schöne an Open Source ist, dass die Leute ihre eigenen Forks als Grundlage für ein neues Projekt verwenden können, wenn ihnen die Art und Weise, wie man die Dinge betreibt, nicht gefällt! Und schließlich die Mitwirkenden; das Hacktoberfest hat viele neue Mitwirkende, aber wir wollen sie zu Mitwirkenden erziehen, nicht zu verwöhnten Kindern. Wenn sie also die Projektrichtlinien lesen müssen, bevor sie einen Beitrag leisten, dann sagen Sie das, anstatt selbst eine Menge Nacharbeit zu leisten.
Hacktoberfest ist jetzt opt-in, aber wenn man "dabei" ist, fühlt man sich leicht überfordert, vor allem bei einem hochkarätigen oder bereits ausgelasteten Projekt. Der Schlüssel zur Bewältigung ist die Verwaltung der Benachrichtigungen. Und nein, eine E-Mail-Regel, die besagt, dass man alles, was den Namen des Projekts enthält, einfach ablegt oder löscht, ist keine Lösung!
Add a filter to file all incoming mail with the word GitHub in
Nehmen Sie sich etwas Zeit für die Einrichtung Ihrer GitHub-Benachrichtigungen, um sicherzustellen, dass Sie nur dann benachrichtigt werden, wenn Sie es wünschen, und dass Sie nicht zu viel Unwichtiges erfahren. Sie können auch verschiedene Benachrichtigungen für verschiedene Organisationen an verschiedene E-Mail-Adressen weiterleiten, was sehr nützlich sein kann.
GitHub verfügt über eine hervorragende Hilfedokumentation, daher werde ich deren Inhalt hier nicht wiederholen, sondern Sie auf die Stellen verweisen, die ich am nützlichsten finde!
Erstens können Sie mehrere E-Mail-Adressen mit einem GitHub Account verknüpfen, was nützlich ist, wenn Sie einige Arbeitsprojekte mit Ihrem GitHub Account durchführen oder eine andere E-Mail-Adresse für ein bestimmtes Open-Source-Projekt verwenden. Werfen Sie einen Blick in die Dokumentation zur Verifizierung zusätzlicher E-Mail-Adressen auf GitHub.
Als Nächstes müssen Sie dafür sorgen, dass die richtigen Benachrichtigungen an die richtige E-Mail-Adresse weitergeleitet werden. Dies geschieht unter "Custom Routing" in der Konfiguration der Benachrichtigungen, und natürlich gibt es ausgezeichnete Dokumentation über das Routing von E-Mails auf GitHub.
Die Möglichkeit, ein Projektarchiv zu "beobachten", ist sehr nützlich. Wenn es ein Projekt gibt, für das Sie alle Benachrichtigungen erhalten möchten, klicken Sie oben auf die Schaltfläche "Beobachten" und wählen Sie "Beobachten". Dies ist nützlich, wenn Sie die Aktivitäten in einem bestimmten Projektarchiv im Auge behalten wollen.
Vielleicht noch wertvoller ist die Möglichkeit, ein Projekt "unwatch" zu machen! Da ich bei der Arbeit einen Teil der GitHub-Wartung übernehme, habe ich Zugang zu vielen Repositories, und wenn man Zugang hat, ist man standardmäßig bei den Benachrichtigungen angemeldet! Das kann, wie Sie sich vorstellen können, ziemlich laut sein, also gibt es über die gleiche Schaltfläche "Beobachten" noch einige andere Optionen - die Standardeinstellung ist "Nicht beobachten", so dass Sie Benachrichtigungen über Ihre eigenen Probleme/PRs oder wenn Sie erwähnt werden, erhalten. Sie können auch "Ignorieren" einstellen, wenn Sie sich einmischen, obwohl Sie es nicht wollen.
Auf der Ebene der einzelnen Repos können Sie auch Benachrichtigungen erhalten, ohne die Diskussion kommentieren zu müssen, um sich als "teilnehmend" zu kennzeichnen. Achten Sie auf die Schaltfläche auf der rechten Seite mit der Aufschrift "Abonnieren" unter "Benachrichtigungen". Auch hier gibt es eine gegenteilige Option! Angenommen, Sie haben sich zu einem Thema geäußert, über das Sie nicht mehr benachrichtigt werden möchten. In diesem Fall können Sie sich nur von einem Problem oder einer Anfrage abmelden, ohne sich von einem ganzen Projektarchiv abmelden zu müssen.
Wenn eine Anfrage nicht nützlich ist oder nicht den Projektzielen entspricht, scheuen Sie sich nicht, sie abzulehnen. Die Hacktoberfest FAQ ist hier Ihr Freund. Seien Sie immer freundlich - aber schnelle Antworten sind wertvoll, wenn Sie die Möglichkeit haben, alle paar Tage mit den Dingen Schritt zu halten. Wenn ein Pull Request akzeptabel gemacht werden könnte, zum Beispiel, weil er den Build zum Scheitern bringt, aber korrigiert werden kann, bieten Sie Ihrem neuen Mitwirkenden ein Feedback an, das erklärt, was den Pull Request reif für die Zusammenführung machen würde. Wenn es eine Änderung ist, die Sie nicht wollen (Emoji zur Verzierung Ihres README scheint ein beliebter Beitrag zu sein), dann sagen Sie das und schließen Sie es.
Open Source ist nicht immer ein einladender Ort, und wir arbeiten in der Öffentlichkeit, so dass Umstehende einen guten Eindruck von unseren Projekten durch die Art und Weise bekommen, wie wir mit Menschen umgehen. Nehmen Sie sich die Zeit, den Leuten für ihren Beitrag zu danken! Selbst wenn die Anfrage nicht die Zeit wert ist, die Sie gebraucht haben, um sie zu lesen, ist ein einfaches "Das scheint für das Projekt nicht nützlich zu sein, warum schauen Sie nicht in der Problemliste nach Ideen?" viel einladender, als die Anfrage ohne weitere Mitteilung oder Erklärung zu schließen.
Nachdem ich mich bei den Mitwirkenden bedankt habe, möchte ich mich zum Schluss bei Ihnen, den Betreuern, bedanken. Es ist ein weit verbreiteter Irrglaube, dass Open-Source-Projekte von einer erstaunlichen, weit entfernten, heldenhaften Figur betreut werden. In Wirklichkeit sind diejenigen von uns, die ihre Zeit und Energie auf diese Weise zur Verfügung stellen, echte Menschen mit echten Leben.
Vielen Dank für alles, was Sie tun. Open Source verändert die Welt, und Sie tragen auf Ihre Weise dazu bei, dass dies geschieht.