레이블, 프로젝트 및 마일스톤 로드맵

.NET docs 팀에서는 GitHub 레이블을 광범위하게 사용하여 작업을 구성합니다. 레이블 조합을 필터링하여 .NET docs 웹 사이트에서 관심 있는 섹션에 빠르게 집중할 수 있습니다. 예를 들어 is:issue is:open label:"dotnet-architecture/prod"에 대한 쿼리를 사용하여 아키텍처 가이드에서 모든 미해결 이슈를 필터링할 수 있습니다.

GitHub 프로젝트를 사용하여 스프린트 및 기타 목표 중심 대규모 사용자 스토리를 구성합니다. 또한 GitHub 마일스톤을 사용하여 작업을 추적합니다. 계획을 위한 프로젝트(문제) 및 작업의 마일스톤(끌어오기 요청)을 생각해 두는 것이 좋습니다.

이 로드맵에서는 이러한 조직 도구를 사용하는 방법을 설명하고 관심 영역을 찾는 데 사용하는 편리한 필터 링크를 제공합니다.

레이블

dotnet/docs를 처음 사용하는 경우에는 일반 문제부터 시작하세요. 이러한 문제는 더 집중적인 범위가 있는 문제입니다. 첫 번째 기여를 만드는 좋은 방법입니다. 일반 보기에서 영역 및 우선 순위를 기준으로 문제를 추가로 필터링할 수 있습니다. 작은 규모의 첫 번째 기여를 시도하려는 경우 처음 사용하기 좋은 문제로 초보자에게 좋은 문제를 식별했습니다.

레이블을 사용하여 다양한 방법으로 문제를 분류합니다.

각 집합(가이드, 릴리스, 우선 순위)의 레이블을 결합하여 좁은 범위로 만들고 작업하려는 문제를 찾을 수 있습니다.

단일 .NET 가이드에 대한 이슈 찾기

각 아키텍처 전자책 및 각 .NET 가이드에 대해 레이블을 사용합니다. 모든 eBook은 dotnet-architecture/prod 레이블로 표시됩니다. 각 책에는 /tech로 끝나는 고유한 레이블이 있습니다.

각 .NET 가이드는 /prod 접미사로 표시되고 배경은 청회색입니다. 각 .NET 가이드에 대해 필터링된 현재 문제는 다음과 같습니다.

다른 제품 레이블은 리포지토리의 영역에 대해 정의됩니다.

가이드의 한 섹션에 대한 이슈 찾기

.NET 가이드는 대용량이므로 이 레이블은 가이드 섹션별로 범위를 제한합니다. 각 .NET 가이드 하위 영역은 /tech 접미사로 표시되고 배경은 연한 파란색입니다. 이러한 레이블의 대부분은 여러 가이드에 적용되고, 일부는 하나의 가이드에만 적용됩니다. 영역을 필터링한 후 이러한 레이블 중 하나를 추가하여 문제 범위를 추가로 제한합니다.

릴리스

:checkered_flag: 릴리스: 진한 노랑

특정 릴리스에 대해 태그가 지정된 문제는 :checkered_flag: Release: 접두사로 표시되고 진한 노란색 배경이 있습니다.

우선 순위

우선 순위 레이블은 모두 Pri 뒤에 단일 숫자가 옵니다. 숫자가 낮을수록 우선 순위가 높습니다.

  • Pri0 - 긴급 우선 순위

    보안 문제이거나 규정 준수를 위해 법적으로 해결해야 하는 문제입니다. 다른 모든 일을 중단하고 해당 문제를 우선적으로 수정합니다.

  • Pri1 - 높은 우선 순위

    일반적인 시나리오에 대해 핵심적인 문제이거나 조회수가 높은 문서에서 눈에 잘 띄는 문제입니다. P2 또는 P3 작업 전에 해결합니다.

  • Pri2 - 중간 우선 순위

    차단 문제가 아니며 일반적인 시나리오의 문제에 적합한 레이블입니다. 빠르고 간단히 해결할 수 있으면 수정하며, 같은 문서의 P1 문제를 다룰 때 함께 수정하기도 합니다.

  • Pri3 - 낮은 우선 순위

    경계 사례, 일반적인 시나리오의 사소한 수정, 조회수가 낮은 문서나 사용되지 않는 기술 문제에 적합한 레이블입니다. 시간을 투자할 필요는 없으나 관심이 있는 커뮤니티의 모든 구성원이 기여할 수 있습니다. 2개월이 지나도 해결되지 않으면 P3 문제는 종결 처리됩니다.

다른 레이블의 경우

콘텐츠 팀에서 다양한 문제 분류를 관리하기 위해 사용하는 다른 레이블이 많이 있습니다. 콘텐츠 팀에 있지 않은 경우에는 이러한 다른 레이블을 무시할 수 있습니다.

프로젝트

프로젝트는 계획 목적으로 제공되며, Kanban 보드를 통해 우선 순위가 지정된 작업을 자동화할 수 있습니다. 프로젝트는 끌어오기 요청이 아닌 GitHub 문제를 포함해야 합니다. 마일스톤은 끌어오기 요청만 포함하므로 프로젝트는 마일스톤과 다릅니다.

프로젝트는 다음과 같은 두 가지 방법으로 사용합니다.

마일스톤

마일스톤은 일반적으로 Month YYYY 프로젝트와 동일한 명명 규칙을 따르지만 프로젝트와는 다릅니다. 마일스톤은 완료된 작업을 추적할 때 사용합니다. 마일스톤은 문제(잠재적 작업)를 포함하는 것이 아니라 단독으로 끌어오기 요청을 포함해야 합니다. 현재 마일스톤은 새 끌어오기 요청에 자동으로 적용됩니다.