Delen via


Roadmap voor labels, projecten en mijlpalen

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

We gebruiken GitHub-projecten om sprints en andere doelgerichte EPICS te organiseren. We gebruiken ook GitHub-mijlpalen om het werk bij te houden. Het beste is om projecten te zien voor planning (problemen) en mijlpalen voor werk (pull-aanvragen).

Deze roadmap biedt uitleg over hoe we deze organisatieprogramma's gebruiken en beschikt over koppelingen naar handige filters waarmee we interessegebieden kunnen vinden.

Labels

Begin, als dit de eerste keer is dat u een bijdrage levert aan dotnet/docs, met de up-for-grabs-problemen. Dit zijn problemen met een meer gericht bereik. Deze zijn een uitstekende manier om uw eerste bijdrage te maken. Vanuit de up-for-grabs-weergave kunt u problemen verder filteren op basis van gebieden en prioriteit. Er zijn goede problemen gevonden voor beginners met een goed-eerste-probleem als u eerst een kleinere bijdrage wilt proberen.

We gebruiken labels om op verschillende manieren problemen te classificeren:

U kunt een label van elke set (gids, release, prioriteit) combineren om voor een beperkte focus te zorgen waarmee u problemen kunt vinden waaraan u wilt werken.

Problemen zoeken voor één .NET-handleiding

We gebruiken labels voor alle e-books over architectuur en voor elke .NET-gids. Alle ebooks worden genoteerd met het label dotnet-architecture/prod . Elk boek heeft een uniek label dat eindigt op /tech.

Elke .NET-handleiding wordt vermeld met het /prod achtervoegsel en heeft een blauwgrijze achtergrond. Hier worden actuele problemen gefilterd voor alle .NET-gidsen.

Andere productlabels worden gedefinieerd voor gebieden die meerdere opslagplaatsen bevatten.

Problemen zoeken voor één sectie van een handleiding

De .NET-gidsen zijn groot, zodat deze labels het bereik verder beperken tot een gedeelte van een gids. Elk .NET Guide-subgebied wordt vermeld met het /tech achtervoegsel en heeft een lichtblauwe achtergrond. Veel van deze labels zijn van toepassing op meerdere gidsen, terwijl andere zich in slechts één gids bevinden. Nadat u hebt gefilterd op een gebied, voegt u een van deze labels toe om het bereik van problemen verder te beperken.

Releases

:checkered_flag: Release: op donkergeel

Problemen met een label voor een specifieke release worden vermeld met het voorvoegsel :checkered_flag: Release: en hebben een donkergele achtergrond.

Prioriteit

Prioritaire labels worden alle Pri gevolgd door één cijfer. Lagere waarden geven een hogere prioriteit aan:

  • Pri0 - Kritieke prioriteit

    Beveiligingsprobleem of juridische vereiste voor naleving. We laten alles liggen om dit te herstellen

  • Pri1 - Hoge prioriteit

    Essentieel voor algemene scenario's. Of zeer zichtbare fout in een artikel met veel paginaweergaven. We voeren deze voor werk voor P2 of P3 uit.

  • Pri2 - Gemiddelde prioriteit

    Nuttig voor algemene scenario's, maar niets wordt geblokkeerd. We doen dit snel en eenvoudig, of passen deze in terwijl we een P1-probleem in hetzelfde artikel aanpakken.

  • Pri3 - Lage prioriteit

    Nuttig voor randgevallen, triviale correcties voor algemene scenario's, artikels met weinig paginaweergaven of afgeschafte technologie. Het is onze tijd niet waard, maar kan door de community worden opgepakt. Een P3-probleem kan worden gesloten als deze niet binnen twee maanden is opgelost.

Hoe zit het met de andere labels?

Er zijn veel andere labels waarmee de inhoudsteams verschillende classificaties van problemen beheren. Als u geen lid bent van het inhoudsteam, kunt u deze labels negeren.

Projecten

Projecten zijn bedoeld voor planningsdoeleinden, waar werk met prioriteit wordt geautomatiseerd in een Kanbanbord. Projecten mogen altijd alleen GitHub-problemen bevatten, geen pull-aanvragen. Projecten verschillen van mijlpalen, omdat mijlpalen alleen pull-aanvragen kunnen bevatten.

We gebruiken projecten op twee manieren:

Mijlpalen

Mijlpalen volgen doorgaans dezelfde naamconventies 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 alleen pull-aanvragen. De huidige mijlpaal wordt automatisch toegepast op nieuwe pull-aanvragen.