[ English | Indonesia | 한국어 (대한민국) | español (México) | English (United Kingdom) | Deutsch | 中文 (简体, 中国) ]

Beitragen zum Organisationleitfaden

Was ist das Beitragen zum Organisationsleitfaden?

Ein Leitfaden, der die grundlegenden Anforderungen und Empfehlungen für Mitarbeiter enthält, die einen Beitrag zu OpenStack leisten möchten.

Empfehlungen

Einbindung von Entwicklern

Warum müssen wir Techniker in die Community schicken?

Mit Technikern in der Community ist es einfacher, Entwicklungsaufgaben oder Diskussionen in der Community auszulösen, um die besten Chancen für die Integration in Ihren Geschäfts-/Produktplan zu erhalten.

Sie brauchen Leute, um Ihr Produkt zu pflegen, so wie die Community Leute braucht, die Projekte in jedem Release-Zyklus pflegen, um die Entwicklung am Laufen zu halten.

In jedem Release-Zyklus gibt es mehrere Möglichkeiten, Entwicklungsaufgaben in der Community auszulösen. Wenn Sie mehr technische Entscheidungen in die Community einbringen, erhalten Sie mehr Feedback und Richtlinien von Entwicklern und Betreibern weltweit. Auch helfen Sie ihnen, bessere Zyklusziele zu erreichen, die auch für Sie von Vorteil sind.

Wie viele Personen sollten Sie schicken?

Hängt von Ihrem eigenen Plan ab, aber versuchen Sie, die Bandbreite der Projektdienste abzudecken, die Sie für Ihre Dienste nutzen oder in Anspruch nehmen wollen.

Sich an diesen Projekten zu beteiligen, bedeutet, dass Sie es können:

  • Überwachen Sie den Zustand des Projekts.

  • Beteiligen Sie sich an der Gestaltung und Leitung des Projekts.

  • Beteiligung und Gestaltung von Umsetzungsgesprächen.

  • Vermeiden Sie Downsstream Patches.

Je mehr Leute Sie im Upstream arbeiten haben, desto mehr Aufmerksamkeit wird Ihr Feature erhalten. Die Bereitstellung von mehr Reviewern wird definitiv dazu beitragen, Ihre Implementierung in Projekte einzubinden. Code Review ist ein Engpass für Landing Patches, mehr gute Reviews, je schneller kann der Code.

Wie lange sollten sie dort sein?

Die ideale Antwort ist, den Technikern so viel Prozent ihrer Zeit wie möglich und so lange wie möglich zu geben.

Wenn Ihr Unternehmen groß genug ist, um die Wahl zu haben, ist es in der Regel effizienter, Ingenieuren mehr Zeit für die Spezialisierung zu geben und sich auf bestimmte Bereiche zu konzentrieren, als wenn Ingenieure ständig den Kontext wechseln, da sie mehrere Hüte tragen müssen.

Ingenieure, die mehr Zeit im Vorfeld verbringen, helfen jedem, indem sie kontinuierlich Input und Feedback zu Aufgaben geben, die Sie als hohe Priorität festlegen. Aber es ist mehr als das, OpenStack setzt auf Peer Review. Vom Landing Code über seine Governance bis hin zur Funktion benötigt das Projekt die Überprüfung durch Mitarbeiter in der Community.

Darüber hinaus wird es auch das Unternehmen vorantreiben, wenn Ingenieure langfristig in der Community tätig sind, da sie eingebettet und in der Community engagiert sind, anstatt ein- und auszusteigen.

Vereinfacht ausgedrückt: Je mehr ein Unternehmen in die Gemeinschaft investiert ist, desto wahrscheinlicher ist es, dass es einen Einflussbereich erhält.

Warum müssen Sie mit der technischen Community synchronisieren?

Die Community im Upstream ist gefüllt mit leidenschaftlichen und intelligenten Menschen, die alle das Beste für das Projekt wollen. Mitwirken bedeutet, dass Sie das Projekt mitgestalten und verbessern können.

Noch besser, anstatt Downstream-Patches in Ihren eigenen Produkten zu forken oder hinzuzufügen, die Sie dann tragen, unterstützen und warten müssten, was sehr kostspielig sein kann. Sie könnten es zu Upstream schieben und von einer ganzen Gemeinschaft von Entwicklern profitieren, die es mit Ihnen verbessern und pflegen. Effektive Beseitigung der meisten, wenn nicht sogar aller zusätzlichen Kosten und Risiken für die Instandhaltung nachgeschalteter Systeme.

Es wird auch besser getestet als alles, was intern entwickelt wird, weil es von der Community getestet und umfassender genutzt wird als nur Ihre Kunden.

All diese zusätzlichen Entwickler bedeuten mehr Augenmerk auf das Finden, Reparieren und Verbessern des Codes. Das bedeutet, dass Sie eine Gemeinschaft von Entwicklern haben, die Ihnen bei der Entwicklung und Verbesserung Ihrer eigenen Infrastruktur helfen.

Denken Sie daran, dass viele Hände leichte Arbeit machen.

Technisch

Code

Internet Relay Chat (IRC)

  • Access to chat.oftc.net port 6697/tcp (IRC communication)

    • Bei Verwendung eines IRC-Bouncer-Ports 443 kann der Bouncer verwendet werden.

    • Siehe IRC einrichten.

Vorschläge

Es gibt browserbasierte IRC-Dienste, wie irccloud, die die Benutzer in Verbindung halten und das Standard-HTTPS (443/tcp) verwenden.

Wenn die Verbindung zu bestimmten Ports gesperrt ist oder ein Problem darstellt, kann ein SOCKS-Server verwendet werden, um den Zugriff zu ermöglichen.

E-Mail-Betrachtung

  • Möglichkeit zum Empfangen von E-Mails und Senden von E-Mails an Adressen unter lists.openstack.org (Mailinglisten)

    • Die Mailingliste kann sehr stark frequentiert sein, erwägen Sie, die Verwendung externer Maildienste zu erlauben, um die Aufnahme aus den Community-Mailinglisten zu verwalten.

  • Betrachten Sie eine Ausnahme für Standard-E-Mail-Fußzeilen bei E-Mails, die an die Community-Mailinglisten gesendet werden

  • Siehe Mailinglisten (ML).

Überlegungen zum Betriebssystem (OS)

Es gibt viele Komponenten und Projekte im Zusammenhang mit dem Betrieb und der Entwicklung von OpenStack, die alle auf Linux laufen. Also wird ein Entwickler brauchen:

  • Erlaubnis, Linux zu betreiben und andere Open-Source-Software auf vom Arbeitgeber zur Verfügung gestellter Hardware zu installieren.

Technische Veranstaltungen

Es gibt eine Reihe von technischen Veranstaltungen, bei denen Community-, Projekt- und projektübergreifende Planung und Vernetzung persönlich stattfinden. Obwohl diese Planung und Vernetzung außerhalb dieser Veranstaltungen online stattfindet, sollten Sie in Betracht ziehen, Entwickler mitzunehmen.

Einige technische Ereignisse sind unter anderem:

  • Project Technical Gatherings (PTGs)

  • Summits und Forum

  • Operator meetups

Weitere Informationen zu solchen Veranstaltungen finden Sie unter: https://www.openstack.org/community/events/

Nicht technische

OpenStack ist eine globale Community. Interaktion mit der Community bedeutet, mit Menschen aus verschiedenen Zeitzonen und Kulturen zu arbeiten und zu interagieren, da es andere nicht-technische Empfehlungen gibt, die das Engagement in der OpenStack-Community erleichtern, diese lassen sich in drei Bereiche unterteilen: Kommunikation, Kultur und Erwartungen.

Kommunikation

Als globale Gemeinschaft mit Mitgliedern aus der ganzen Welt, die gelegentlich außerhalb der üblichen Bürozeiten arbeiten, reden oder sich treffen können, ist von größter Bedeutung.

Einige asynchrone Kommunikationsmedien, wie E-Mail und Gerrit, werden stark genutzt, aber manchmal können diese Diskussionen durch die Verwendung synchroner Medien wie:

  • IRC-Gespräche

    • Wenn Sie als Entwickler aus einem anderen Teil der Welt arbeiten, kann das bedeuten, dass Sie eine Zeit zum Chatten im IRC finden, wenn alle Parteien verfügbar sind.

    • Ebenso kann das Gespräch mit einem Patch-Autor im Channel bei der Überprüfung von Patches die Überprüfung insbesondere bei komplexeren Patches erheblich beschleunigen.

  • IRC-Meetings

    • Alle Projekte haben regelmäßige Treffen im IRC. Die meisten dieser Treffen wechseln zwischen zwei verschiedenen Zeitzonen. Manchmal ist es jedoch von Vorteil, wenn alle Entwickler, die an einem bestimmten Feature oder Projekt arbeiten, gleichzeitig an einem Ort sind.

  • Andere

    • Andere Projekte können je nach Entwickler andere Kommunikationswege wählen. Aber Transparenz ist wichtig. Alles, was besprochen wird, sollte protokolliert oder protokolliert werden, damit der Rest des OpenStack-Projekts und die Welt sehen kann.

Community-Kultur

  • Zeitzonen

    • Die OpenStack-Community ist auf die verschiedenen Zeitzonen verteilt, also versuchen Sie immer, für die größere Community transparent zu sein, und wenn Sie ein synchrones Kommunikationssystem verwenden, um Funktions-/Projektentscheidungen zu treffen, stellen Sie sicher, dass Sie asynchrone Eingaben von Mitgliedern in anderen Zeitzonen ermöglichen.

    • Unterschiedliche Zeitzonen bedeuten unterschiedliche Kulturen, also seien Sie sensibel für diese kulturellen Unterschiede. Ein Beispiel ist, Nicht-Muttersprachlern die Möglichkeit zu geben, zu denken und zu sprechen, und wenn Sie ein Sprachmedium verwenden, verlangsamen Sie bitte.

  • Titel, die von Community-Mitgliedern gehalten werden, sind temporär und Aktivitäten sind nicht wirklich mit Titeln verknüpft.

    • Alle sind gemeinsam dabei und arbeiten an einem besseren OpenStack.

    • Gewählt werden alle, die einen Titel wie PTL oder ein Teil des Technischen Komitees sind. Titel sind also temporär.

  • Forks sind schlecht, ein Beitrag upstream ist viel besser.

    • Zitieren von Artikeln darüber, wie die Pflege von Forks im Allgemeinen ein teurer und schmerzhafter Prozess ist (über Links zu weiterführenden Informationen über effektives Open-Source-Community-Engagement).

  • Die Community empfiehlt nicht offiziell den Dienst Stackalytics, der von Mirantis bereitgestellt wird und Statistiken zu den Contributions sammelt und bereitstellt. Die Community ermuntert nicht dazu, die eigenen Statistiken durch einer große Anzahl an kleinen Beiträgen zu beschönigen, oder für viele Vorschläge abzustimmen ohne tiefergehende Reviews beizusteuern. Solche Aktivitäten erzeugen anderen Community Mitgliedern gegenüber den Eindruck das System auszutricksen und Contributor, die dies praktizieren, verlieren selbst an Ansehen, so wie auch ihre Firmen/Arbeitgeber. Contributor sollten sich über ein ein oder wenige Projekte mit der entsprechenden Tiefe beteiligen, um die Funktionen der Software und Komponenten zu verstehen und Beziehungen zu den anderen Contributors aufzubauen.

  • Die Fokussierung der Mitarbeiter auf bestimmte Projektbereiche oder auf bestimmte Ziele ist effektiver, als sie zu bitten, die Aktivitäten über viele Projekte hinweg zu verfolgen.

Erwartungen

  • Erlaubnis zur Zustimmung zum OpenStack ICLA (erforderlich)

  • Erlaubnis, gelegentlich außerhalb der üblichen Bürozeiten zu arbeiten

  • Ein Prozess zur Klärung von Beiträgen aus IP-Sicht

  • Genehmigung und Budget für die Entsendung von Beitragenden zu Veranstaltungen

  • Erwartung der Reise zu mindestens einigen Veranstaltungen - muss nicht alles sein

    • Sollte bereit sein, ein Genehmigungsschreiben/Visumsschreiben/notwendige Schreiben für die Visabeschaffung zu schreiben

    • Die auf der Reise getroffenen Schreiben/Entscheidungen sollten idealerweise Wochen oder mehr im Voraus ausgehändigt werden

    • Permission to agree with terms of becoming an Open Infrastructure Foundation Individual Member

  • Erwägen Sie, sich als beitragendes Organisationsmitglied zu registrieren