Roadmap voor labels, projecten en mijlpalen

Het .NET docs-team maakt uitgebreid gebruik van GitHub-labels om ons werk te organiseren. Door te filteren op combinaties van labels, kunnen we ons snel richten op secties die van belang zijn op de website van .NET-documenten. We kunnen bijvoorbeeld filteren op alle geopende problemen in de architectuurhandleidingen met een query naar is:issue is:open label:"dotnet-architecture/svc".

We gebruiken GitHub-projecten om sprints en andere doelgeoriënteerde epics te organiseren. We gebruiken ook GitHub-mijlpalen om werk bij te houden. U kunt het beste projecten bedenken voor planning (problemen) en mijlpalen voor werk (pull-aanvragen).

In deze roadmap wordt uitgelegd hoe we deze organisatiehulpprogramma's gebruiken en koppelingen hebben naar handige filters die we gebruiken om nuttige gebieden te vinden.

Labels

Als dit uw eerste ervaring is met bijdragen aan dotnet/docs, begint u met de hulp gezocht issues. Dit zijn problemen met een meer gericht bereik. Ze zijn een geweldige manier om uw eerste bijdrage te leveren. Vanuit de beschikbare weergave kunt u problemen verder filteren op basis van domeinen en prioriteit. We hebben goede kwesties vastgesteld voor beginners met de goede eerste kwestie als u een kleinere eerste bijdrage wilt leveren.

We gebruiken labels om problemen op veel verschillende manieren te classificeren:

• .NET-handleidingen en secties van een handleiding.
• Doelversie

U kunt een label uit elke set (handleiding, release, prioriteit) combineren om een smalle focus te creëren om problemen te vinden waaraan u wilt werken.

Problemen vinden voor één .NET-handleiding

We gebruiken labels voor elk van de e-books van de architectuur en voor elke .NET-handleiding. Alle ebooks worden genoteerd met het dotnet-architecture/prod-label . Elk boek heeft een uniek label dat eindigt op /subsvc.

Elke .NET-handleiding wordt vermeld met het /svc achtervoegsel en heeft een blauwgrijze achtergrond. Hier volgen huidige problemen die worden gefilterd voor elk van de .NET-handleidingen.

• .NET-handleiding - dotnet/svc
• .NET Fundamentals Guide (voorheen .NET Standard Guide) - dotnet-fundamentals/svc
• .NET Fundamentals Guide (voorheen .NET Core Guide) - dotnet-core/svc
• .NET Framework Handleiding - dotnet-framework/svc
• API-verwijzing - dotnet-api/svc
• C#-handleiding - dotnet-csharp/svc
• F#-handleiding- dotnet-fsharp/svc
• Visual Basic Guide - dotnet-visualbasic/svc
• handleiding voor ML.NET - dotnet-ml/svc
• Azure .NET SDK - dotnet-azure/svc
• Handleiding voor .NET Desktop - dotnet-desktop/svc

Er worden andere productlabels gedefinieerd voor gebieden die tussen opslagplaatsen vallen.

Problemen opsporen voor één sectie van een handleiding

De .NET-handleidingen zijn groot, daarom beperken deze labels het bereik verder tot een specifieke sectie van een handleiding. Elk subgebied van de .NET-handleiding wordt vermeld met het /subsvc achtervoegsel en heeft een lichtblauwe achtergrond. Veel van deze labels zijn van toepassing op meerdere handleidingen, terwijl andere slechts in één handleiding staan. Voeg na het filteren op een gebied een van deze labels toe om het bereik van problemen verder te beperken.

Uitgaven

Problemen die zijn getagd voor een specifieke release, worden vermeld met het :checkered_flag: Release: voorvoegsel en hebben een donkergele achtergrond.

Hoe zit het met de andere labels?

Er zijn veel andere labels die door de inhoudsteams worden gebruikt om verschillende classificaties van problemen te beheren. Als u niet in het inhoudsteam bent, kunt u deze andere labels negeren.

Projecten

Projecten zijn bedoeld voor planningsdoeleinden, waarbij geprioriteerd werk wordt geautomatiseerd via een Kanbanbord. Projecten mogen alleen GitHub-problemen bevatten, niet pull-aanvragen. Projecten verschillen van mijlpalen, omdat mijlpalen in het algemeen pull-aanvragen bevatten. We houden mijlpalen in de gaten om ervoor te zorgen dat pull requests niet verouderen.

We gebruiken projecten op twee manieren:

• Month YYYY projecttypen: Dit zijn Kanbanborden voor het werkplan van elke maand.
• Langlopende epics: deze worden gebruikt om taken naar een doel te organiseren wanneer het werk gedurende meerdere maanden plaatsvindt.

Mijlpalen

Mijlpalen volgen doorgaans dezelfde naamconventie van projecten Month YYYY, maar ze verschillen van projecten. We gebruiken mijlpalen om voltooid werk bij te houden. Mijlpalen mogen geen problemen (mogelijk werk) bevatten, maar bevatten alleen pull-aanvragen. De huidige mijlpaal wordt automatisch toegepast op nieuwe pull-aanvragen.