Erläuterung der Bezeichnungen, Projekte und Meilensteine
Das .NET-Dokumentationsteam macht umfassend Gebrauch von GitHub-Bezeichnungen, um die Arbeit zu organisieren. Indem wir nach Bezeichnungen filtern, können wir uns schnell auf wichtige Bereiche auf der .NET-Dokumentationswebsite konzentrieren. Sie könnten beispielsweise mit der Abfrage is:issue is:open label:"dotnet-architecture/prod" nach allen offenen Issues für Architekturleitfäden filtern.
Wir verwenden GitHub-Projekte, um Sprints und andere zielorientierte Epics zu organisieren. Wir verwenden auch GitHub-Meilensteine, um die Arbeit nachzuverfolgen. Projekte dienen der Planung (Issues), Meilensteine der laufenden Arbeit (Pull Requests).
Diese Roadmap erläutert, wie wir diese Organisationstools verwenden und enthält Links zu praktischen Filtern, die wir verwenden, um relevante Bereiche zu finden.
Bezeichnungen
Wenn Sie zum ersten Mal etwas zu dotnet/docs beitragen, sollten Sie mit den up-for-grabs-Issues beginnen. Dabei handelt es sich um Issues, die sich stärker auf einen Bereich konzentrieren. Sie eignen sich besonders für Ihren ersten Beitrag. In der Ansicht „up-for-grabs“ können Sie basierend auf Bereich und Priorität nach Issues filtern. Mithilfe von good-first-issue konnten wir Issues identifizieren, die sich für Anfänger eignen und mit denen Sie Ihren ersten kleinen Beitrag leisten können.
Wir verwenden Bezeichnungen, um Issues auf verschiedene Art und Weise zu klassifizieren:
Sie können eine Bezeichnung aus jedem Bereich kombinieren (guide, release, priority), um genau die Issues zu finden, an denen Sie arbeiten möchten.
Ermitteln von Issues für einen .NET-Leitfaden
Wir verwenden Bezeichnungen für die einzelnen Architektur-E-Books und für jeden .NET-Leitfaden. Alle E-Books werden mit der Bezeichnung dotnet-architecture/prod versehen. Jedes E-Book verfügt über eine eindeutige Bezeichnung, die mit /tech endet.
.NET-Leitfäden erkennen Sie am Suffix /prod und einem blaugrauen Hintergrund. Hier werden aktuelle Issues für die einzelnen .NET-Leitfäden gefiltert.
-
.NET-Leitfaden:
dotnet/prod -
Leitfaden für .NET-Grundlagen (zuvor .NET Standard-Leitfaden):
dotnet-fundamentals/prod -
Leitfaden für .NET-Grundlagen (zuvor .NET Core-Leitfaden):
dotnet-core/prod -
.NET Framework-Leitfaden:
dotnet-framework/prod -
API-Referenz:
dotnet-api/prod -
C#-Leitfaden:
dotnet-csharp/prod -
F#-Leitfaden:
dotnet-fsharp/prod - Visual Basic-Leitfaden: `dotnet-visualbasic/prod
-
ML.NET-Leitfaden:
dotnet-ml/prod -
Azure .NET SDK:
azure-dotnet/prod -
.NET for Apache Spark-Leitfaden:
dotnet-spark/prod -
.NET Desktop-Leitfaden:
dotnet-desktop/prod
Andere Produktbezeichnungen werden für Bereiche definiert, die sich in mehreren Repositorys befinden.
Ermitteln von Issues für einen Abschnitt eines Leitfadens
Die .NET-Leitfäden sind groß, sodass diese Bezeichnungen den Bereich durch einen Abschnitt eines Leitfadens weiter einschränken. Unterbereiche eines .NET-Leitfadens erkennen Sie am Suffix /tech und einem hellblauen Hintergrund. Viele dieser Bezeichnungen gelten für mehrere Leitfäden, während andere in nur einem Leitfaden aufgeführt sind. Fügen Sie nach dem Filtern nach einem Bereich eine dieser Bezeichnungen hinzu, um den Umfang des Issues weiter einzuschränken.
Releases
Issues, die für ein bestimmtes Release gekennzeichnet sind, werden mit dem Präfix :checkered_flag: Release: versehen und weisen einen dunkelgelben Hintergrund auf.
Priorität
Bei Prioritätsbezeichnungen folgt auf Pri eine einzelne Ziffer. Niedrigere Zahlen stehen für eine höhere Priorität.
Pri0: kritische Priorität
Sicherheitsissue oder aus Compliancegründen gesetzlich vorgeschrieben. Wir kümmern uns mit oberster Priorität um eine Lösung.
Pri1: hohe Priorität
Essenziell für gängige Szenarien oder ein auffälliger Fehler in einem häufig aufgerufenen Artikel. Solche Issues korrigieren wir, bevor wir an P2- oder P3-Issues arbeiten.
Pri2: mittlere Priorität
Hilfreich für gängige Szenarien, aber kein Issue, das Prozesse blockiert. Wir korrigieren solche Issues entweder schnell zwischendurch oder während im gleichen Artikel ein P1-Issue behoben wird.
Pri3: niedrige Priorität
Hilfreich für Grenzfälle, einfache Korrekturen für gängige Szenarien, nicht sehr häufig aufgerufene Artikel oder veraltete Technologien. Solche Korrekturen überlassen wir Communitybeiträgen. Ein P3-Issue kann geschlossen werden, wenn nach zwei Monaten keine Reaktion erfolgt ist.
Weitere Bezeichnungen
Es gibt viele andere Bezeichnungen, die von den Inhaltsteams verwendet werden, um unterschiedliche Klassifizierungen von Issues zu verwalten. Wenn Sie nicht Teil des Inhaltsteams sind, können Sie diese anderen Bezeichnungen ignorieren.
Projekte
Projekte dienen Planungszwecken, und die priorisierten Arbeitsaufgaben sind dabei über ein Kanban-Board automatisiert. Projekte dürfen immer nur GitHub-Issues enthalten, niemals Pull Requests. In dieser Beziehung unterscheiden sich Projekte von Meilensteinen: Meilensteine enthalten nur Pull Requests.
Projekte werden auf diese beiden Arten verwendet:
- Projekte vom Typ
Month YYYY: Dies sind Kanban-Boards für den Arbeitsplan jedes einzelnen Monats.- Beispiele: July 2020, August 2020 usw.
- Epics mit langer Laufzeit: Diese werden verwendet, um Aufgaben für ein Ziel zu organisieren, wenn die Arbeit sich über mehrere Monate erstreckt.
- Beispiele: .NET 5 Wave - Reorganization, .NET Languages (.NET 5 wave) usw.
Meilensteine
Meilensteine folgen in der Regel derselben Namenskonvention wie Projekte (Month YYYY), unterscheiden sich aber von Projekten. Meilensteine dienen zum Nachverfolgen abgeschlossener Arbeitsaufgaben. Meilensteine dürfen keine Issues (potenzielle Arbeitsaufgaben) enthalten, sondern ausschließlich Pull Requests. Der aktuelle Meilenstein wird automatisch auf neue Pull Requests angewendet.