Führung¶
Die fleißigen Bienen des Core Teams haben eine Reihe von Aufgaben, um den Bienenstock namens BeeWare am Laufen zu halten. Da es sich um ein sich ständig weiterentwickelndes Projekt handelt, kann sich der Inhalt dieser Seite ändern.
Dazu gehören unter anderem das Reagieren auf Probleme, das Überprüfen und Zusammenführen von Code, die Betreuung neuer Mitwirkender und die Architektur des BeeWare-Projekts als Ganzes.
Es gibt Menschen, denen wir vertrauen, dass sie Entscheidungen über den Code treffen; es gibt Menschen, denen wir Code und organisatorische Entscheidungen zu treffen; und es gibt eine Person die die Vision der gesamten Organisation lenkt und damit betraut ist, eine eine endgültige Entscheidung zu treffen, wenn die Gemeinschaft nicht zu einem Konsens kommt.
Team-Dienstalter¶
Die verschiedenen Senioritätsstufen im BeeWare-Projekt sind:
Biene oder Arbeitsbiene¶
Jedes Mitglied der BeeWare-Community. Da wir offen auf GitHub arbeiten, kann jeder Änderungen am Code vorschlagen und seinen Code einbinden lassen. Die einzige Einschränkung für Ihre Mitwirkungsmöglichkeiten besteht darin, dass Ihre Arbeit von einem Teammitglied mit den entsprechenden Rechten eingebunden werden muss.
Imker¶
Eine Biene, die als vertrauenswürdiger Mitwirkender anerkannt ist. Diese Bienen haben über einen bestimmten Zeitraum hinweg ihre Fähigkeiten in Bezug auf einen bestimmten Teil des BeeWare-Projekts unter Beweis gestellt. Dies kann auf technischer Ebene (JavaScript-, Python-, Objective-C-Kenntnisse; GTK+-, macOS-Kenntnisse) oder auf einer anderen Ebene (Community-Management, Code-Review) sein. Imker können auch das Commit-Bit für das Projekt haben, in dem ihre Fachkenntnisse anerkannt sind.
Erfahrene Imker¶
Imker mit erhöhtem Zugriff auf GitHub und einer zusätzlichen Verantwortung für die Überwachung des gesamten Projekts. Sie können architektonische Entscheidungen treffen, sind aber letztendlich dem BDFN gegenüber rechenschaftspflichtig.
Bienenfreundlicher Diktator für den Moment (BDFN)¶
In Anlehnung an Benevolent Dictator for Life liegt die Verantwortung für die Ausrichtung und Entscheidungen des Projekts letztendlich beim BDFN. Die Verwendung von „For Now” (vorläufig) anstelle von „For Life” (auf Lebenszeit) ist ein Verweis auf das Django-Prinzip, die Verantwortung eines Core-Maintainers nicht auf das gesamte Leben einer Person zu beschränken. Das Leben existiert auch außerhalb von Open Source, und die Balance zwischen Code und Leben sowie das allgemeine Wohlbefinden sind sehr wichtige Aspekte, die es zu berücksichtigen gilt.
Der BDFN von BeeWare ist Russell Keith-Magee.
Gründungsimker¶
Der Mann, der als Erster auf einem Hügel stand und ein Yak entdeckte, das geschoren werden musste. Diese Rolle ändert sich nie und besteht unendlich fort; sie ist jedoch nicht mit zusätzlichen Befugnissen innerhalb der Organisation verbunden. Derzeit ist der Gründungsimker auch der BDFN, aber das kann sich im Laufe der Zeit ändern.
Richtlinien (keine verbindlichen Vorschriften)¶
Wie bei jedem Projekt mit mehr als einer Person mit Commit-Rechten gibt es gibt es eine Reihe von allgemeinen Richtlinien, die das Team befolgen sollte:
- Seien Sie ein guter Vertreter des Projekts gegenüber der breiteren Öffentlichkeit.
- Behandeln Sie jede Anfrage und jeden Beitrag zu einem BeeWare-Projekt mit Respekt.
- Gehen Sie davon aus, dass jeder gute Absichten hat, auch wenn er seine Worte nicht gut gewählt hat.
- Angenommen, jemand hat etwas „falsch” gemacht, dann liegt das daran, dass wir es versäumt haben, den Prozess zu kommunizieren.
- Gehen Sie davon aus, dass jeder Ausdruck von Ärger oder Frustration aus dem ehrlichen Wunsch heraus entsteht, ein BeeWare-Tool/eine BeeWare-Bibliothek zu verwenden.
- Ermutigen Sie andere Mitglieder der Community, diese Ideale in ihrer eigenen Kommunikation sowohl innerhalb als auch außerhalb der BeeWare-Community widerzuspiegeln.
- Kein Imker sollte seinen eigenen Code festlegen.
- Ausnahme: „Etwas ist sehr kaputt und muss sofort repariert werden.“
- Ausnahme: BDFN (dies kann sich in Zukunft ändern)
- Der gesamte Code, der von einem Kernteammitglied zur Überprüfung eingereicht wird, sollte von einem anderen Teammitglied überprüft werden.
- Ausnahme: BDFN (dies kann sich in Zukunft ändern)
- Der gesamte Code sollte vor dem Zusammenführen die Tests zur kontinuierlichen Integration bestehen.
- Ausnahme: Code, der bekanntermaßen fehlerhaft ist und aus anderen Gründen committet werden muss.
- Ausnahme: Code in einem Repository mit unzureichenden CI-Tests
- Ausnahme: Fleißig und engagiert ist besser als perfekt und untätig.
- Akzeptanzprozesse sollten nach Möglichkeit automatisiert werden.
- Das bedeutet Tests, Linting, Rechtschreibprüfung, Abdeckung und mehr.
Imker werden¶
Die Aufnahme eines neuen Imkers in das Team liegt im alleinigen Ermessen des bestehenden Kernteams. Zwar gibt es derzeit keine festen Regeln Regeln gibt, wird im Allgemeinen jemand als Imker in ein BeeWare-Projekt eingeladen BeeWare-Projekt eingeladen, wenn er solide Beiträge zu dem Projekt. Dies kann auch auf jemanden mit spezifischem Fachwissen ausgeweitet werden Fachwissen (z.B. iOS/macOS), das im bestehenden Team fehlen könnte bestehenden Team fehlt. Es muss auch nicht auf Commits beruhen. Jeder, der in der Lage ist, ein Interesse an dem Projekt im Allgemeinen zu zeigen, kann um die Erlaubnis bitten, an dem Projekt mitzuarbeiten.
Alle neuen Imker werden (mangels eines besseren Wortes) in die Grundwerte und Richtlinien des Projekts „eingeweiht“. Eine Zusammenfassung der Grundwerte finden Sie auf der Seite „Über uns“. Von jedem, der dem Team beitritt, wird erwartet, dass er diese Werte hochhält und sich an Diskussionen über die Weiterentwicklung dieser Werte im Laufe der Zeit beteiligt.
Von einem Imker, ob neu oder alt, wird nicht erwartet, dass er sich allein um eine Sache kümmert. einer Sache zu sein. Es gibt viele Imker, und noch viel mehr, die Hilfe, Rat und die Hilfe, Rat und Betreuung anbieten können.
„Commit-Bit“?¶
In Unix-Systemen wird ein einzelnes Bit in einer Datei verwendet, um die Erlaubnis zur eine Datei auszuführen. In Versionskontrollsystemen gibt es ein ähnliches Bit, um die Fähigkeit zu kennzeichnen, Code zusammenzuführen. Wenn man sagt, dass jemand das "Commit-Bit" hat bedeutet, dass er Schreibzugriff auf eine Codebasis hat. In Bezug auf GitHub bedeutet dies dass er die Fähigkeit hat, Pull Requests zusammenzuführen und Code direkt an das das Projekt zu übertragen.