.NET-Grundlagen – mitwirken an Microsoft Open Source-Softwareprojekte.

Durch Mark Michaelis | Oktober 2018

Hier ist eine Tatsache: Microsoft hostet ca. 2.000 open-Source-Software (OSS)-Repositorys auf GitHub an, einschließlich einige recht groß wie das .NET Compiler Platform, auch bekannt als "Roslyn" mit bis zu 4 Millionen Codezeilen erforderlich. Für viele Entwickler möglicherweise der Interessenten der Übermittlung von codeänderungen, um ein Projekt, das auf Millionen von Computern ausgeführt wird, könnte entmutigend erscheinen. Glücklicherweise benötigen Sie keinen pH.d. in Programmiersprachen und -Compiler die Markierung auf Projekte (OSS) Microsoft vornehmen. Es gibt Möglichkeiten zum mitwirken, die ein breites Spektrum von schwierigkeiten und Erlebnis, das vom Anfänger bis Fortgeschrittene umfassen.

Ich erhalten Meine Start im März 2018 arbeiten mit dem .NET Core-Team, um einen neuen Satz von APIs hinzuzufügen. Ich war an Bord Dank meiner Verbindungen bei Microsoft und insbesondere mit der Programm-Manager Kathleen Dollard wechseln. Zum Zeitpunkt ich gefragt, "wie schwer es für eine Person, die nicht bei Microsoft daran teilhaben schnellen war wäre?" Mit dieser Frage Denken Sie daran entschied ich mich ein wenig Recherche und erfahren Sie. In diesem Artikel untersuche ich im Rahmen der Mitwirkung an Microsoft OSS und was für Einsteiger in motivieren erforderlich ist.

Erste Schritte: Dokumentation und Pull Request-Überprüfung

Vielleicht ist der beste Ort zum beginnen mit der Dokumentation. Wenn Sie auf die Dokumentationsseiten .NET navigieren (z. B. bit.ly/2LAv7hA) sehen Sie am unteren Rand jeder Seite, eine Fußzeile Gemeinschaftsprojekten, vorhanden ist, siehe Abbildung1.

Abbildung 1 übermitteln, Vorschläge und Änderungen in der Dokumentation

Hier übermitteln Sie ein neues Problem, klicken können, "Produkt-Feedback", oder Durchsuchen Sie und Durchsuchen Sie vorhandenen Probleme. Noch besser ist, die zweite Schaltfläche gelangen direkt in die Liste der GitHub-Problem für Sie durchsuchen wurden, so können Sie ein GitHub-Problem erstellen und navigieren Sie zu der Dokumentation Quellcode selbst speziellen Seite (z. B. github.com/dotnet/docs) und direkt, das Problem zu beheben. Häufig erstellen lassen können nur die Dokumentation wird aktualisiert, und Senden eines Pull Request (PR) ist einfacher als der Arbeitsaufwand, um das Problem zu dokumentieren.

Ich habe gesprochen mit Teammitgliedern direkt aus, und sie betonen Sie, dass alle Übermittlungen Willkommen, sogar Rechtschreibung und Grammatikkorrekturen. Diese Änderungen möglicherweise nicht in der aufregende können, sie jedoch des Unterschied zwischen einer erfolgreichen-API und eine nicht erfolgreich.

Darüber hinaus ist die Dokumentationsteam eines der am schnellsten auf ausgelöste Probleme und die PRs mit Mitarbeitern zugewiesen werden, zu den verschiedenen Bereichen für Adresse Beiträge, unabhängig davon, wie klein zu reagieren. Ein Grund Dokumentation bearbeiten, ist einfach: Es müssen nicht in der Regel Sie Klonen des Repositorys zum Übermitteln von Änderungen. Stattdessen können Sie die GitHub-Web-basierte bearbeitungs-UI, die automatisch verzweigt und sendet den PR für Sie.

PR-Überprüfung ist auch eine wichtige Möglichkeit zum mitwirken an. Jedes Projekt benötigt PR Feedback und das Microsoft-Team für Pull Request überprüfen Beiträge dankbar. Ich kenne ich geschätzt haben – und gelernten aus – Überprüfung des funktioniert, habe ich die .NET an. Die wichtigste Lektion für mich ist, dass ich kann nicht springen und liefert einen wesentlichen Beitrag gelegentliche oder in der Splitter zwischen andere Dinge erledigen. Code auf dieser Ebene erfordert sorgfältig, um herauszufinden, eine sorgfältige Implementierung und erhebliche Zusammenarbeit. Schließlich bin ich für PRs zurückgewiesen, und die PRs akzeptiert dankbar. Pull Request-Überprüfungen sind ein idealer Ausgangspunkt, und helfen mit der open-Source-Entwicklung.

Erstmalige intuitiv Probleme

Für diejenigen, die für die auf mehr als Dokumentation bereit bietet Microsoft einige Anleitungen. Probleme, die mit Deskriptoren wie "zunächst" gekennzeichnet sind, und "einfach" eignen sich gut für Entwickler gedacht, die das Spiel. Microsoft fordert auch active Projektmitglieder erstmaligen intuitiv Probleme erst am Ende einer Version von löschen nach steuern, daher einfacher Probleme verfügbar für Entwickler, die neu auf das Projekt zu halten und verringern die Komplexität Leiste für die ersten Schritte. Darüber hinaus intuitiv erstmalige Probleme häufig Dokument enthält Links, die beschreiben, wo Sie für das Problem zu suchen, um keine neue Entwickler flailing Versuch, einen bestimmten Fehler im Heuhaufen zu finden, die ein großes Repository. Für das Roslyn-Team müssen Sie z. B. eine gute erste Problem einschließen:

Links zu der Datei, in dem das Problem wahrscheinlich erforderlich sein wird.
Identifizierung, in dem die Tests müssen
Anweisungen zur Einrichtung für die ersten Schritte mit Roslyn
Allgemeine Beitrag-Richtlinie

Das Engagement für neue Beiträge bevorzugen erstreckt sich auf wie PRs akzeptiert werden. Für PRs, die als "gute erste Problem" gekennzeichnet bevorzugt Microsoft neue Mitwirkende, ihre PRs über die vorhandenen Mitwirkende akzeptieren. Wird der Microsoft Konzertvideo anzubieten, die ein Problem als "gute erste Problem"-tags direkt von Personen, die zum Beheben des Problems arbeiten Fragen. Dies alles Betreuung kann in den ersten Phasen der Beteiligung wichtig sein.

Eine Methode zum Abrufen der ersten Mitwirkende beteiligt natürlich verlässt Microsoft. Roslyn ist z. B. eine kompliziert, 4 Millionen Inline Codebasis, die nicht für schwache Nerven verwendet wird. Durch neue Mitwirkende ansprechender kann Microsoft eine aktive Community von externen Entwickler die OSS-Teams.

Reguläre Beiträge

Nachdem Sie Ihre erste Pull Request akzeptiert haben, werden Sie wahrscheinlich bei komplexeren Problemen und Features zu ergreifen. Sind Problem Tags wie "Help wollten" und "Aufdruck", die angeben, dass ein Problem wahrscheinlich eine gute Ziel für die Community ist vorhanden, jedoch nicht notwendigerweise ideal für Einsteiger. (Finden Sie unter nach-oben-für-grabs.net Durchsuchen der Liste der Projekte und die entsprechenden Probleme z. B. tags für intuitiv erstmalige oder Hilfe wollte.) Probleme mit der Bezeichnung dieser Tags wahrscheinlich umfassen mehrere Geschäfts-, Schul- oder mehr Kenntnisse des Projekts als ein unbeteiligten Entwicklers bereitgestellt werden kann; Allerdings sind klar definiert und benötigen keine umfassende Zusammenarbeit mit dem Team. Andererseits, besteht ein definiertes Workflows, die Sie befolgen sollte:

Beiträge, die keiner Fehlerkorrektur sollte mit dem Team und innerhalb des Bereichs der Roadmap zu vermeiden, wird abgelehnt, erläutert:
Beiträge muss für Master – nicht für ein experimentelles Feature-Branch
Pull Requests müssen einfach mit der Spitze des master-Branch zusammenführen.
Mitwirkende sollten Sie sicher, dass sich die lizenzveREINBARUNG für Mitwirkende, (siehe cla2.dotnetfoundation.org)

Als Entwickler, die mit Git ist zu erwarten ist, achten Sie darauf, dass Sie in eine lokale Verzweigung funktionieren (auf Ihrem Computer geklont haben), und senden dann Code berücksichtigen sollten, über einen PR ein. Natürlich können Sie eine Verzweigung lokal erstellen, aber wenn Sie Ihr PR einreichen müssen Sie zum Master senden werden.

Es gibt einige Richtlinien für Programmierung und Workflow zu berücksichtigen. Es gibt zunächst dem Codierungsstil zu berücksichtigen. Während Sie den C#-Programmierung Stil am ermitteln können bit.ly/2woQv3u, die allgemeine Zusammenfassung ist, auf dem Standard der vorhandenen Datei entsprechen. Dies gilt auch, wenn die vorhandene Datei aus dem dokumentierten Standard unterscheidet sich. Dies bedeutet, dass die Richtlinie, bis Sie ganze Dateien Codierung (oder Hinzufügen von Elementen, die für die es keine Rangfolge bereits in der Datei gibt), einfach ist, führen Sie das Beispiel für den Rest der Datei. Auch ohne Vorrang es gibt jedoch nur 16 Elemente in der C#-Programmierung Stil Dokument aufgeführt, die besonders überrascht werden. Diese Elemente enthalten:

Geschweifte Klammern in einer eigenen Zeile
Statt vier Leerzeichen für Einzüge (nicht "Registerkarten")
_camelCase für interne private Felder und PascalCasing für Konstante lokale Variablen und Felder
Vermeiden Sie dies. es sei denn, die erforderlich sind
Geben Sie die Sichtbarkeit (d. h. verwenden privat sogar, wenn der Member privat standardmäßig) immer an.
Vermeiden von mehr als eine leere Zeile, die den Code aufteilen
Var nur verwenden, wenn der zugewiesene Typ offensichtlich ist (siehe itl.tc/UsingVar), mit Ausnahme von Roslyn-Projekte, die Var überall verwenden
Geben Sie Felder oben in einer Typdeklaration

Im Allgemeinen finden Sie eine editorconfig (finden Sie unter editorconfig.org) Einstellungsdatei für jedes Verzeichnis, und die Durchsetzung dieser Standards. Achten Sie darauf, dass Sie die Datei zu verwenden, um sicherzustellen, dass Sie die Richtlinien und vermeiden, dass Ihr PR blockiert.

Führen Sie für diejenigen, die Codierung in Visual Basic Sinn und Zweck der C#-Richtlinien aus.

Obwohl nicht in der Liste bereits erwähnt, sind Komponententests entscheidend für das erforderliche Servicelevel Qualität erzeugt.

Design-Hilfe

Einige Repositorys wie Sprache, CoreFX und Dotnet-CLI benötigen deutlich mehr Erfahrung und-Kompetenz und verwenden daher einen anderen Prozess. Mit diesen Bibliotheken ist der Eintrag an der Diskussion-Ebene anstatt auf Ebene der. Direkte Übermittlung einen Pull Request-Code auf diese Bibliotheken mit einem neuen Feature oder Programmiersprachen-Schlüsselwort ist wahrscheinlich nicht erfolgreich ist.

Während des Entwurfsprozesses in der Regel angezeigt wird, ist es nicht über eine jeder gegen jeden. In der Tat beginnen nicht Übermittlungen für diese Repositorys selbst mit Vorschlägen. (Sehen Sie sich die C#-Sprache Vorschläge Ordner bit.ly/2BVUbjf für sich gut an die wichtigsten Funktionen derzeit in Betracht gezogen.) Wenn Sie ein Feature vorschlagen möchten, starten Sie stattdessen ein Problem und kennzeichnen Sie es mit der Bezeichnung "Discussion". Wenn Diskussionsbeiträge gewisse Konsens zu erreichen, dass weitere Auswertung berücksichtigt werden sollten, sind sie sich an den Language Design-Besprechungen, übernommen, die wiederum von weiteren erläuterungen, Experimente und offline datenbankentwurfsarbeit unterrichtet werden. Vorschläge selbst – nicht finalisiert Features – klicken Sie dann von einem Mitglied der sprachentwicklungsteams ins Leben gerufene.

Während des Prozesses auf Feedback geöffnet werden soll, kann nicht jeder nur Änderungen vornehmen, aber sie auswählen. Die Menge der Verteilung und die Auswirkungen der Änderung ist zu hoch, um nicht eng (sehr ähnlich wie das Steuerelement mit Linus Torvalds mit Linux) gesteuert werden. Letzten Endes ist das Projekt noch open-Source. Wenn Sie möchten die Freiheit gibt, den Code auf beliebige Weise ändern, Ihrem Geschmack wünscht, einfach das Repository zu verzweigen, und beginnen zu können.

Dieser Ansatz ist eine wichtige Möglichkeit für die Zusammenarbeit, auch vor dem Beginn der codeimplementierung. Änderungen sind auch dann wahrscheinlich in eine separate Verzweigung für einen längeren Zeitraum, während sie programmiert (und immer wieder neu programmiert) und ausgewertet. Die Community ist bei der Entscheidung, was die Form eines Elements werden als wichtig. Öffnen ein Problem Diskussion, Kommentare, und die Bereitstellung von Feedback mit vorhandenen Angebote direkter Zugriff auf das Team möglich.

Sie werden bemerken, beitragen das gesamte Spektrum von einfach auf nur sehr schwer ausgeführt werden kann. Ist eine Methode oder Klasse eine API hinzufügen, z. B. eine Sache, aber das Hinzufügen eines neuen Programmiersprachen-Schlüsselworts etwas anderes vollständig ist.

Was geschieht nach dem Senden eines Pull Requests

Im April 2018 realisiert das Roslyn-Team an, dass sie selbst wieder aufgeholt mussten für die Verarbeitung aller PRs, die eingereicht haben. Mit allen Änderungen, die nach PRs vorgenommen hatte, war es wahrscheinlich, dass einige davon nicht mehr relevant wäre. Um das Problem zu beheben, stellt Microsoft verstärkt und Mitarbeiter, die jedes Projekt zugewiesen. Es war ihre Arbeit auf alle zukünftigen Pull Requests, um sicherzustellen, dass die investiert eher zum Erfolg führen konnte. Für diese bestrebungen sollten Sie sie die folgende Kategorisierung von Pull Requests:

Vom Projektleiter genehmigt: Genehmigte PRs werden einer Buddy oder Coach zugewiesen, vom Projektteam, verbessern die Wahrscheinlichkeit für erfolgreiche Übernahme und der Pull Request in der Codebasis zu integrieren. Die Coach wird sichergestellt, dass es sich bei Mitgliedern der Community beschäftigt sind, befolgen Sie mit Mitwirkenden innerhalb von drei Werktagen Wenn der Pull Request aus irgendeinem Grund abgelehnt wird.
Ausstehende Besprechung: Manchmal wichtige Fragen auftauchen, Komponententests sind nicht vorhanden, der Zweck ist unklar, oder der Code kann nicht wesentlich, um die Richtlinien zu erfüllen. In diesen Fällen löst der projektleitung die Aspekte, die den Community-Contributor identifizieren, was geschehen muss. Es bleibt dem Contributor, nachverfolgung innerhalb von zwei Wochen. Darüber hinaus müssen Pull Requests in dieser Gruppe durch den Code Basis während dieses Zeitraums zu halten.
Abgelehnt: Der Pull Request ist nicht mit der Zielsetzung des Projekts, umfasst zu viele Risiken oder eine Priorität nicht erfolgreich bewältigen. In diesem Fall lehnt der potenziellen Kunden die PR Abschließt, das Problem eindeutig zu identifizieren. Während der Pull Request erneut übermittelt werden kann, wird es müssen signifikante Änderung oder überarbeiten.

Zusammenfassung

Gelegentlich können Sie beobachten, Verhalten in Source-Projekte, die weit von den Standards der anständigkeit "öffnet". Dies kann Teilnehmer einschließen, die grobe, ärgerliche oder wiederholt hören Sie sich widersprechende Ansichten nicht. Darüber hinaus Mitwirkende, die nicht akzeptieren die Rolle von Microsoft als die letzte kompatibilitätsprüfung Microsoft OSS-Projekte, spam wiederholt ein Repository oder anderweitig unterbricht den Prozess der Zusammenarbeit. Jeder Benutzer, die die Regeln für allgemeine Civility folgen kann nicht sich selbst blockiert, die aus einem Repository finden (und Zurückgeben von unter einer Pseudonym mit dem gleichen Verhalten nicht erhalten Sie eine weitere). Microsoft ist bestrebt, wodurch Beteiligung eine positive Erfahrung für alle, und erzwingen den Verhaltenskodex ist der Kern dieser Verpflichtung.

Sollten Sie überprüfen das Microsoft Open Source Verhaltenskodex am bit.ly/2wmAYlB. Überprüfen Sie auch die zugehörigen häufig gestellten Fragen unter bit.ly/2NwNNRa.

Nach meiner Erfahrung hängt wie Ansatz vornehmen von Änderungen an den Microsoft-OSS größtenteils wie Ihr Interesse an möchte eine Änderung generiert. Ich erwarte, dass für die meisten von Ihnen des Katalysators dabei sein ein Problem in Form eines Fehlers oder eines fehlenden Features handelt. Der Trigger möglicherweise zunächst ein Fehler oder ein Problem in der Dokumentation und den Wunsch, die sie für andere Leser zu beheben. Alternativ vielleicht Sie in der Xamarin-Codebasis arbeiten und ermitteln, dass eine Methode, die Sie außer Kraft setzen möchten nicht virtuell, ist, damit Sie einen Pull Request, um solche erleichtern übermitteln.

Einige von Ihnen wird eine noch größere Herausforderung übernehmen möchten. Mit .NET Core habe ich durch die Tatsache astounded wurde, die nicht vorhanden (noch) eine Befehlszeilenparser ist, die problemlos akzeptieren die Befehlszeilenargumente und analysieren Sie sie in ein stark typisiertes Objekt von dem ich die Werte in meinem Programm zugreifen kann. Es war dieses wissen, die veranlasste mich, starten die Zusammenarbeit mit Microsoft Jon Sequeira (die Befehlszeilenparser für Dotnet CLI geschrieben habe), um solche einen Parser zu erstellen. Leider der Code ist immer noch zu instabil und unsere Teilnahme zu gelegentlichen für das Projekt werden open Source. Hoffentlich wird nicht er zu lang sein, bevor dieses Projekt ist, die wir für die Öffentlichkeit öffnen können, damit sie zu die Einbindung der OSS-Community profitieren kann. In der Zwischenzeit, wenn Sie viel Zeit zu reservieren und Interesse an der unser Parser-Projekt, eine E-mail an Kathleen senden oder mich, und wir können eine Möglichkeit, erhalten Sie beim Ausarbeiten. Und, Ja, habe ich nur noch eine andere Möglichkeit zur Mitwirkung eingeführt – anzubieten, bevor der Code auf öffentlich festgelegt ist.

Mark Michaelis ist der Gründer von IntelliTect und arbeitet als leitender technischer Architekt und Trainer. Er ist Microsoft MVP für fast zwei Jahrzehnten und Microsoft Regional Director seit 2007. Michaelis arbeitet in verschiedenen Microsoft-Softwareentwicklungs-Reviewteams mit, einschließlich C#, Microsoft Azure, SharePoint und Visual Studio ALM. Er hält Vorträge auf Entwicklerkonferenzen und hat viele Bücher, einschließlich seines letzten geschrieben "Essential c# 7.0 (6th Edition)" (ITL.TC/essentialcsharp). Sie können ihn auf Facebook unter facebook.com/Mark.Michaelis, über seinen Blog unter IntelliTect.com/Mark, auf Twitter: @markmichaelis oder per E-Mail unter mark@IntelliTect.com erreichen.

Unser Dank gilt den folgenden technischen Experten von Microsoft für ihre Hilfe, Zusammenarbeit und die Durchsicht dieses Artikels: Kevin Bost (IntelliTect), Kathleen Dollard, Neal Gafter, Sam Harwell, Immo Landwerth, Jared Parsons, Jon Sequeira, Abrechnung Wagner, Maira Wenzel

Diesen Artikel im MSDN Magazine-Forum diskutieren

Freigeben über