Erfahren Sie, wie Sie an den Repositorys der .NET-Dokumentation mitwirken können.

Vielen Dank, dass Sie an der .NET-Dokumentation mitwirken möchten.

In diesem Artikel erfahren Sie, wie Sie an Artikeln und Codebeispielen der .NET-Dokumentation mitwirken können. Bei Änderungen kann es sich nur um das Korrigieren von Tippfehlern oder sogar um das Hinzufügen neuer Artikel handeln.

Die .NET-Dokumentation besteht aus mehreren Repositorys:

Issues zu allen diesen Repositorys werden im Repository dotnet/docs erfasst.

Richtlinien für Beiträge

Wir schätzen Beiträge zur Dokumentation, die aus der Community kommen. Im Folgenden sind einige Leitlinien aufgelistet, die Sie beachten sollten, wenn Sie an der .NET-Dokumentation mitwirken:

  • Keine unvermittelten großen Pull Requests. Eröffnen Sie stattdessen ein Issue, und beginnen Sie eine Diskussion, sodass sich die Teilnehmer auf eine Richtung einigen können, bevor Sie viel Zeit investieren.
  • Befolgen Sie diese Anweisungen und die Richtlinien für Sprache und Stil.
  • Verwenden Sie die Vorlage als Ausgangspunkt für Ihre Arbeit.
  • Erstellen Sie einen separaten Branch in Ihrer Fork, bevor Sie an einem Artikel arbeiten.
  • Befolgen Sie den Workflow für GitHub Flow.
  • Bloggen oder twittern Sie über Ihre Beiträge.

Durch diese Richtlinien wird der Ablauf für Sie und für uns erleichtert.

So tragen Sie zur .NET-Dokumentation bei

Schritt 1: Wenn Sie neue Inhalte erstellen oder bestehenden Inhalt überprüfen, öffnen Sie ein Issue, in dem Sie beschreiben, was Sie vorhaben. Der Inhalt im Ordner docs ist in Abschnitte unterteilt, die im Inhaltsverzeichnis erfasst werden. Definieren Sie, wo im Inhaltsverzeichnis sich das Thema befinden soll. Holen Sie Feedback zu Ihrem Vorschlag ein.

Alternative:

Wählen Sie ein vorhandenes Issue aus, und beheben Sie es. Sie können ebenfalls die Liste open issues (Offene Issues) ansehen und an einem Issue mitwirken, der Sie interessiert.

  • Filtern Sie nach der Bezeichnung good-first-issue, um nach guten ersten Issues zu suchen.
  • Filtern Sie nach der Bezeichnung up-for-grabs, um nach Issues zu suchen, die für einen Communitybeitrag geeignet sind. Diese Issues erfordern in der Regel nur minimalen Kontext.
  • Erfahrene Mitwirkende können beliebige relevante Issues lösen.

Wenn Sie ein entsprechendes Issue finden, fügen Sie einen Kommentar hinzu, um zu fragen, ob es noch offen ist.

Sobald Sie eine Aufgabe ausgewählt haben, an der Sie arbeiten möchten, befolgen Sie den Leitfaden für die ersten Schritte, um ein GitHub-Konto zu erstellen und Ihre Umgebung einzurichten.

Schritt 2: Forken Sie nach Bedarf die Repositorys /dotnet/docs, dotnet/samples, dotnet/dotnet-api-docs, dotnet/roslyn-api-docs oder dotnet/ml-api-docs, und erstellen Sie einen Branch für Ihre Änderungen.

Wenn Sie nur kleine Änderungen vornehmen müssen, finden Sie die entsprechenden Anweisungen für das Bearbeiten in GitHub auf der Startseite des Leitfadens für Mitwirkende.

Schritt 3: Nehmen Sie Änderungen an diesem neuen Branch vor.

Wenn es sich um einen neuen Artikel handelt, können Sie diese Vorlage als Ausgangspunkt verwenden. Diese enthält die Richtlinien für das Schreiben und erläutert die Metadaten, die für jeden Artikel erforderlich sind, z.B. Informationen zum Autor. Weitere Informationen zur Markdownsyntax, die auf der docs.microsoft.com-Website verwendet wird, finden Sie in der Markdownreferenz.

Navigieren Sie zu dem Ordner, der der Position im Inhaltsverzeichnis entspricht, die Sie in Schritt 1 für Ihren Artikel festgelegt haben. Dieser Ordner enthält die Markdowndateien für alle Artikel in diesem Abschnitt. Erstellen Sie bei Bedarf einen neuen Ordner, in dem Sie die Dateien speichern können, aus denen Ihr Inhalt besteht. Der Hauptartikel für diesen Abschnitt heißt index.md.

Erstellen Sie für Bilder und andere statische Ressourcen einen Unterordner namens media in dem Ordner, der Ihren Artikel enthält (falls noch nicht vorhanden). Erstellen Sie im Ordner media einen Unterordner mit dem Namen des Artikels (außer für die Indexdatei). Weitere Informationen zum Speicherort Ihrer Dateien finden Sie im Abschnitt Beispielordnerstruktur.

Erstellen Sie für Codeausschnitte einen Unterordner namens snippets (Codeausschnitte) in dem Ordner, der Ihren Artikel enthält (falls noch nicht vorhanden). Erstellen Sie im Ordner snippets einen Unterordner mit dem Artikelnamen. In den meisten Fällen haben Sie Codeausschnitte für die wichtigsten drei .NET-Hauptsprachen C#, F# und Visual Basic. Erstellen Sie in diesem Fall Unterordner namens csharp, fsharp und vb für jedes der drei Projekte. Wenn Sie einen Codeausschnitt für einen Artikel unter den Ordnern docs/csharp, docs/fsharp oder docs/visual-basic erstellen, wird der Ausschnitt nur in einer Sprache angezeigt, sodass Sie den Sprachordner weglassen können. Weitere Informationen zum Speicherort Ihrer Dateien finden Sie im Abschnitt Beispielordnerstruktur.

Codeausschnitte sind kleine fokussierte Codebeispiele, die die in diesem Artikel behandelten Konzepte veranschaulichen. Größere Programme, die für den Download und die Durchsuchung vorgesehen sind, sollten sich im dotnet/samples-Repository befinden. Vollständige Beispiele werden im Abschnitt zum Beitrag zu Beispielen behandelt.

Schritt 4: Senden Sie einen Pull Request (PR) von Ihrem Branch zum Standardbranch.

Wichtig

Die Kommentarautomatisierung ist derzeit nicht für die Repositorys für die .NET-Dokumentation verfügbar. Die Mitglieder des Teams für die .NET-Dokumentation überprüfen und mergen Ihren Pull Request.

Jeder PR sollte in der Regel jeweils ein Issue behandeln, es sei denn, mehrere Issues beziehen sich auf den gleiche PR-Fix. Mit einem Pull Request können eine oder mehrere Dateien geändert werden. Wenn Sie mehrere Probleme in verschiedenen Dateien beheben, sollten Sie mehrere Pull Requests erstellen.

Wenn Ihr Pull Request ein vorhandenes Problem behebt, fügen Sie das Schlüsselwort Fixes #Issue_Number zur Beschreibung des Pull Requests hinzu. Dadurch wird das Issue automatisch geschlossen, wenn der Pull Request gemerget wurde. Weitere Informationen finden Sie unter Verknüpfen eines Pull Requests mit einem Problem mithilfe eines Schlüsselworts.

Das .NET-Team überprüft Ihren Pull Request anschließend und teilt Ihnen mit, ob weitere Änderungen nötig sind, um diesen zu genehmigen.

Schritt 5: Nehmen Sie gemäß der Absprache mit dem Team die erforderlichen Änderungen an Ihrem Branch vor.

Die Verwalter mergen Ihren Pull Request in den Standardbranch, sobald das Feedback umgesetzt und die Änderung genehmigt wurde.

Alle Commits werden mithilfe von Push regelmäßig vom Standardbranch in den Livebranch übertragen. Dann können Sie Ihren Beitrag unter https://docs.microsoft.com/dotnet/ ansehen. Diese Veröffentlichungen finden werktags in der Regel täglich statt.

Beispiel für die Paketordnerstruktur

docs
  /about
  /core
    /porting
      porting-overview.md
      /media
        /porting-overview
          portability_report.png
        /shared ...
      /snippets
        /porting-overview
          /csharp
            porting.csproj
            porting-overview.cs
            Program.cs
          /fsharp
            porting.fsproj
            porting-overview.fs
            Program.fs
          /vb
            porting.vbproj
            porting-overview.vb
            Program.vb
        /shared
          /csharp ...
          /fsharp ...
          /vb ...

Hinweis

Die Sprachordner unter „snippets“ werden im Sprachleitfaden nicht benötigt. Dort wird nur eine Sprache angenommen. Im C#-Leitfaden wird beispielsweise davon ausgegangen, dass alle Codeausschnitte in der Sprache C# sind.

In der oben dargestellten Struktur ist ein Image enthalten (portability_report.png) sowie drei Codeprojekte, die Codeausschnitte enthalten. Diese Codeausschnitte sind wiederum im Artikel porting-overview.md zu finden.

Der Ordner snippets/shared wird für Codeausschnitte verwendet, die mehrere Artikel innerhalb desselben übergeordneten Ordners umfassen, zum Beispiel den Portierungsordner im vorherigen Beispiel. Verwenden Sie nur den Ordner shared, wenn Sie dafür einen Grund haben, wie etwa XAML-Code, auf den von mehreren Artikeln verwiesen wird und der im artikelspezifischen Ordner nicht kompiliert werden kann.

Medien können auch artikelübergreifend freigegeben werden, wenn sich diese Artikel im selben übergeordneten Ordner befinden, zum Beispiel der Portierungsordner im vorherigen Beispiel. Dieser freigegebene Ordner (shared) sollte nach Möglichkeit vermieden werden, wenn es sinnvoll ist. Es kann beispielsweise sinnvoll sein, einen gemeinsamen Ladebildschirm für die zu demonstrierende App freizugeben oder Visual Studio-Dialoge, die in mehreren Artikeln wiederverwendet werden.

Wichtig

Aus historischen Gründen werden viele der enthaltenen Ausschnitte im Ordner /samples des dotnet/docs-Repositorys gespeichert. Wenn Sie wesentliche Änderungen an einem Artikel vornehmen, sollten diese Ausschnitte in die neue Struktur verschoben werden. Machen Sie sich jedoch keine Gedanken über die Verschiebung von Codeausschnitten für kleinere Änderungen.

Beispiele für die Mitwirkung

Für Code, der unsere Inhalte unterstützt, wird Folgendes unterschieden:

  • Samples (Beispiele): Leser können die Beispiele herunterladen und ausführen. Bei den Beispielen sollte es sich immer um vollständige Anwendungen oder Bibliotheken handeln. Wenn ein Beispiel eine Bibliothek erstellt, sollte dieses Komponententests oder eine Anwendung enthalten, mit denen der Leser den Code ausführen kann. Häufig werden mehrere Technologien, Features oder Toolkits verwendet. Die Datei „readme.md“ für jedes Beispiel verweist auf den Artikel, sodass Sie sich über die Konzepte informieren können, mit denen sich die Beispiele befassen.
  • Snippets (Codeausschnitte): Diese stellen weniger umfangreiche Konzepte oder Tasks dar. Sie können zwar kompiliert werden, sind jedoch keine vollständigen Anwendungen. Sie sollten ordnungsgemäß ausgeführt werden können, sind jedoch keine Beispielanwendungen für ein bestimmtes Szenario. Codeausschnitte sollen so klein wie möglich sein, um ein einzelnes Konzept oder Feature zu veranschaulichen. Dabei sollte nicht mehr Code enthalten sein, als auf einen üblichen Bildschirm passt.

Beispiele befinden sich im Repository dotnet/samples. Wir arbeiten an einer Lösung, damit die Struktur des Ordners „samples“ zukünftig der Struktur des Ordners „docs“ entspricht. Es gibt folgende Standards zu beachten:

  • Die Ordner auf oberster Ebene entsprechen den Ordnern, die sich im Repository docs auf oberster Ebene befinden. Das Repository „docs“ enthält beispielsweise den Ordner machine-learning/tutorials, und die Beispiele für diese Tutorials für das maschinelle Lernen befinden sich im Ordner samples/machine-learning/tutorials.

Außerdem sollten alle Beispiele, die sich in den Ordnern core und standard befinden, auf allen Plattformen, die .NET Core unterstützt, erstellt und ausgeführt werden können. Dies wird durch unser CI-Buildsystem erzwungen. Der Ordner framework auf oberster Ebene enthält Beispiele, die nur unter Windows erstellt und überprüft werden.

Beispielprojekte sollten dem Szenario entsprechend auf so vielen Plattformen wie möglich ausgeführt können. In der Praxis bedeutet das, dass Sie nach Möglichkeit auf .NET Core basierende Konsolenanwendungen erstellen sollten. Beispielen, die für Web- oder Benutzeroberflächenframeworks gelten, sollten diese Tools bei Bedarf hinzugefügt werden. Dazu zählen unter anderem Webanwendungen, mobile Apps und WPF- oder WinForms-Apps.

Wir arbeiten an einem CI-System für jeden Code. Wenn Sie Beispiele aktualisieren, sollten Sie sicherstellen, dass jedes Update Teil eines erstellbaren Projekts ist. Fügen Sie den Beispielen im Idealfall auch Tests auf Richtigkeit hinzu.

Jedes vollständige Beispiel sollte die Datei readme.md enthalten. In dieser Datei sollte eine kurze Beschreibung des Beispiels enthalten sein (ein bis zwei Absätze). Die Datei readme.md soll den Lesern vermitteln, was sie durch dieses Beispiel lernen können. Die Datei readme.md sollte ebenfalls einen Link zur Dokumentation auf der Website der .NET-Dokumentation enthalten. Wenn Sie festlegen möchten, wo eine bestimmte Datei im Repository dieser Website zugeordnet wird, ersetzen Sie /docs im Repositorypfad durch https://docs.microsoft.com/dotnet.

Ihr Artikel sollte zudem Links zum Beispiel enthalten. Der Link sollte direkt zu dem Ordner auf GitHub führen, in dem sich das Beispiel befindet.

Schreiben eines neuen Beispiels

Beispiele sind vollständige Programme und Bibliotheken, die zum Download bereit stehen. Sie sind möglicherweise sehr klein, aber sie veranschaulichen Konzepte auf eine Weise, die es den Benutzern ermöglicht, selbst zu forschen und zu experimentieren. Die Richtlinien für diese Beispiele stellen sicher, dass Leser diese herunterladen und erkunden können. Sehen Sie sich die Beispiele zu Paralleles LINQ (PLINQ) als Beispiel für jede Richtlinie an.

  1. Ihr Beispiel muss Teil eines erstellbaren Projekts sein. Die Projekte sollten nach Möglichkeit auf allen Plattformen erstellt werden können, die von .NET Core unterstützt werden. Davon ausgenommen sind Beispiele, die plattformspezifische Features oder Tools veranschaulichen.

  2. Ihr Beispiel sollte aus Gründen der Konsistenz dem Runtimeprogrammierstil entsprechen.

    Zudem sollten Sie static-Methoden anstelle von Instanzmethoden verwenden, wenn Sie etwas veranschaulichen möchten, für das die Instanziierung von Objekten nicht erforderlich ist.

  3. Ihre Beispiele sollten eine angemessene Ausnahmebehandlung umfassen. Diese sollte alle Ausnahmen behandeln, die im Kontext des Beispiels wahrscheinlich ausgelöst werden. In ein Beispiel, in dem die Methode Console.ReadLine aufgerufen wird, um die Benutzereingabe abzurufen, sollte beispielsweise eine angemessene Ausnahmebehandlung eingefügt werden, die verwendet werden kann, wenn die Eingabezeichenfolge als Argument an eine Methode übergeben wird. Wenn ihr Beispiel erwartet, dass ein Methodenaufruf fehlschlägt, muss ebenfalls die Ausnahme behandelt werden, die ausgelöst wird. Sie sollten immer die Ausnahmen behandeln, die von der Methode ausgelöst werden, nicht die Ausnahmen der Basisklassen wie Exception oder SystemException.

So erstellen Sie ein Beispiel:

  1. Eröffnen Sie ein Issue, oder fügen Sie einen Kommentar zu einem vorhandenen Issue hinzu, der aussagt, dass Sie an diesem arbeiten.

  2. Schreiben Sie einen Artikel, der die Konzepte erläutert, die in Ihrem Beispiel veranschaulicht werden (z.B. docs/standard/linq/where-clause.md).

  3. Schreiben Sie Ihr Beispiel (z.B. WhereClause-Sample1.cs).

  4. Erstellen Sie die Datei „Program.cs“ mit einem Haupteinstiegspunkt, der Ihr Beispiel aufruft. Wenn diese bereits vorhanden ist, fügen Sie den Aufruf zum Beispiel hinzu:

    public class Program
    {
        public void Main(string[] args)
        {
            WhereClause1.QuerySyntaxExample();
    
            // Add the method syntax as an example.
            WhereClause1.MethodSyntaxExample();
        }
    }
    

Codeausschnitte oder Beispiele für .NET Core werden mithilfe der .NET Core-CLI erstellt, die mit dem .NET Core SDK installiert werden kann. So können Sie ein Beispiel erstellen und ausführen:

  1. Navigieren Sie zum Ordner des Beispiels, und führen Sie „dotnet build“ aus, um diesen auf Fehler zu überprüfen:

    dotnet build
    
  2. Führen Sie Ihr Beispiel aus:

    dotnet run
    
  3. Fügen Sie die Datei „readme.md“ zum Stammverzeichnis Ihres Beispiels hinzu.

    Diese sollte eine kurze Beschreibung des Codes und einen Verweis auf den Artikel enthalten, zu dem das Beispiel gehört. Der obere Bereich der readme.md-Datei muss über die erforderlichen Metadaten für den Beispielbrowser verfügen. Der Headerblock muss folgende Felder enthalten:

    ---
    name: "really cool sample"
    description: "Learn everything about this really cool sample."
    page_type: sample
    languages:
      - csharp
      - fsharp
      - vbnet
    products:
      - dotnet-core
      - dotnet
      - dotnet-standard
      - aspnet
      - aspnet-core
      - ef-core
    ---
    
    • Die languages-Sammlung sollte nur die Sprachen enthalten, die für Ihr Beispiel verfügbar sind.
    • Die products-Sammlung sollte nur die für Ihr Beispiel relevanten Produkte enthalten.

Wenn es nicht anders angegeben ist, werden alle Beispiele auf von .NET Core unterstützten Plattformen über die Befehlszeile erstellt. Es gibt einige Beispiele, die speziell für Visual Studio erstellt wurden. Für diese ist Visual Studio 2017 oder höher erforderlich. Außerdem behandeln einige Beispiele plattformspezifische Features. Für diese ist eine bestimmte Plattform erforderlich. Andere Beispiele und Codeausschnitte werden unter Windows ausgeführt und benötigen .NET Framework sowie das Developer Pack für die Zielversion des Frameworks.

Die interaktive C#-Benutzeroberfläche

Für alle Codeausschnitte, die in einem Artikel enthalten sind, wird ein Sprachtag verwendet, um die Quellsprache anzugeben. Für kurze Codeausschnitte in C# kann das Sprachtag csharp-interactive verwendet werden, um einen C#-Codeausschnitt anzugeben, der im Browser ausgeführt wird. (Für Inlinecodeausschnitte wird das Tag csharp-interactive verwendet und für Codeausschnitte, die über die Quelle hinzugefügt werden, das Tag code-csharp-interactive.) Diese Codeausschnitte stellen im Artikel ein Codefenster und ein Ausgabefenster dar. Das Ausgabefenster zeigt die Ausgabe an, die aus dem interaktiven Code entsteht, sobald der Benutzer den Codeausschnitt ausgeführt hat.

Durch die interaktive C#-Benutzeroberfläche wird das Arbeiten mit Ausschnitten verändert und verbessert. Leser können den Codeausschnitt ausführen, um die Ergebnisse anzuzeigen. Es gibt einige Faktoren, anhand derer Sie entscheiden können, ob der Codeausschnitt oder der zugehörige Text Informationen zur Ausgabe enthalten sollte.

Wann die erwartete Ausgabe ohne Ausführung des Codeausschnitts erkennbar sein sollte

  • In Artikeln für Einsteiger sollte die Ausgabe enthalten sein, sodass die Leser die Ausgabe Ihres Codes mit der erwarteten Ausgabe vergleichen können.
  • In Codeausschnitten, bei denen die Ausgabe eine wichtige Rolle für den Artikel spielt, sollte diese enthalten sein. Bei Artikeln über formatierten Text sollte das Textformat ersichtlich sein, ohne den Codeausschnitt auszuführen.
  • Wenn der Codeausschnitt und die erwartete Ausgabe kurz sind, sollten Sie die Ausgabe ebenfalls einfügen. Das spart dem Leser etwas Zeit.
  • In Artikeln, die thematisieren, wie die aktuelle Kultur oder invariante Kultur sich auf die Ausgabe auswirken, sollte die erwartete Ausgabe erläutert werden. Die interaktive REPL (read–eval–print-Loop) wird auf einem Linux-basierten Host ausgeführt. Die Standardkultur und die invariante Kultur erzeugen auf unterschiedlichen Betriebssystemen und Computern verschiedene Ausgaben. Die Ausgabe sollte in solchen Artikeln für Windows-, Linux- und Mac-Systeme erläutert werden.

Wann die erwartete Ausgabe nicht im Codeausschnitt enthalten sein sollte

  • Bei Artikeln mit einem Codeausschnitt, der eine große Ausgabe generiert, sollte diese nicht in den Kommentaren enthalten sein. Der Code wird dadurch unübersichtlich, sobald der Codeausschnitt ausgeführt wurde.
  • Bei Artikeln mit einem Codeausschnitt, der ein Thema veranschaulicht, bei dem die Ausgabe für das Verständnis nicht relevant ist. Wenn beispielsweise Code enthalten ist, der eine LINQ-Abfrage ausführt, um die Syntax von Abfragen zu veranschaulichen, muss nicht jedes in der Ausgabe vorhandene Element aufgeführt werden.

Hinweis

Sie werden feststellen, dass einige Artikel den hier ausgeführten Richtlinien nicht entsprechen. Wir arbeiten an der Konsistenz der Website. Hier finden Sie die Liste der offenen Issues, die derzeit auf diesen Punkt überprüft werden.

Mitwirken an internationalen Inhalten

Beiträge für maschinell übersetzte (MT) Inhalte werden zurzeit nicht akzeptiert. Um die Qualität der maschinell übersetzten Inhalte zu verbessern, haben wir eine Umstellung auf eine neuronale MT-Engine durchgesetzt. Wir akzeptieren und ermutigen Beiträge für die von Menschen übersetzte Inhalte (Human Translation, HT), die zum Trainieren der neuronalen MT-Engine verwendet werden. Im Laufe der Zeit verbessern Beiträge zu HT-Inhalten die Qualität der menschlichen als auch der maschinellen Übersetzung. In maschinell übersetzten Themen wird ein Haftungsausschluss angezeigt, der besagt, dass ein Teil des Themas maschinell übersetzt ist, und die Schaltfläche Bearbeiten wird nicht angezeigt, da die Bearbeitung deaktiviert ist.

Hinweis

Für die meisten lokalisierten Dokumentationen ist es nicht möglich, diese über GitHub zu bearbeiten oder Feedback über GitHub abzugeben. Verwenden Sie die unter aka.ms/DocSiteLocFeedback verfügbare E-Mail-Vorlage, um Feedback zu lokalisierten Inhalten abzugeben. Lediglich die Azure-Dokumentation stellt eine Ausnahme dar. Für azure-docs gibt es öffentliche und lokalisierte GitHub-Repositorys, in denen Communitybeiträge für sechs Sprachen zulässig sind: Chinesisch, Französisch, Deutsch, Japanisch, Koreanisch und Spanisch. Für alle anderen Sprachen und Inhalte müssen Sie die E-Mail-Vorlage verwenden, die für alle Sprachen vorgesehen ist, um Übersetzungsfehler oder technisches Feedback anzumerken.

Lizenzvereinbarung für Mitwirkende

Sie müssen die Lizenzvereinbarung der .NET Foundation für Mitwirkende (Contribution License Agreement, CLA) unterschreiben, bevor Ihr Pull Request gemergt wird. Für Projekte der .NET Foundation ist dies nur einmalig nötig. Weitere Informationen zu Lizenzvereinbarungen für Mitwirkende (Contribution License Agreement, CLA) finden Sie auf Wikipedia.

Hier finden Sie die Lizenzvereinbarung: .NET Foundation Contributor License Agreement (CLA)

Sie müssen diese nicht im Voraus unterschreiben. Sie können Ihren Pull Request wie gewohnt klonen, forken und senden. Wenn Ihr Pull Request erstellt wird, wird dieser von einem CLA-Bot klassifiziert. Wenn es sich nur um eine geringfügige Änderung handelt (z.B. das Korrigieren eines Tippfehlers), wird der Pull Request mit cla-not-required gekennzeichnet. Andernfalls wird er als cla-required klassifiziert. Sobald Sie die Lizenzvereinbarung für Mitwirkende (CLA) unterschrieben haben, werden alle aktuellen und zukünftigen Pull Requests als cla-signed gekennzeichnet.