Дорожная карта меток, проектов и вех

Команда документации .NET использует метки GitHub для организации нашей работы. Отфильтровав сочетания меток, мы можем быстро сосредоточиться на разделах, интересующих веб-сайт документации .NET. Например, мы можем отфильтровать все открытые проблемы в руководствах по архитектуре с запросом is:issue is:open label:"dotnet-architecture/svc".

Мы используем проекты GitHub для организации спринтов и других ориентированных на цели эпических событий. Мы также используем вехи GitHub для отслеживания работы. Лучше всего думать о проектах для планирования (задач), и о вехах для работы (пулреквесты).

Эта стратегия объясняет, как мы используем эти организационные инструменты и имеет ссылки на удобные фильтры, которые мы используем для поиска интересующих областей.

Наклейки

Если это ваш первый вклад в dotnet/docs, начните с задач, где требуется помощь. Это проблемы с более узкой областью. Это отличный способ внести свой первый вклад. В представлении "Обзор доступных задач" можно дополнительно фильтровать задачи по областям и приоритетам. Мы определили хорошие задачи для начинающих с хорошей первой задачей, если вы хотите начать с небольшого вклада.

Мы используем метки для классификации проблем различными способами:

• Руководства и разделы руководствапо .NET.
• Целевой релиз

Вы можете объединить метку из каждого набора (руководство, выпуск, приоритет), чтобы создать узкий фокус, чтобы найти проблемы, над которыми вы хотите работать.

Обнаружение проблем в одном руководстве по .NET

Мы используем метки для каждой архитектуры электронных книг и для каждого руководства .NET. Все электронные книги отмечены меткой dotnet-architecture/prod . Каждая книга имеет уникальную метку, которая заканчивается /subsvc.

Каждое руководство .NET отмечается суффиксом /svc и имеет синий серый фон. Ниже приведены текущие проблемы, отфильтрованные для каждого из руководств .NET.

• Руководство по .NET . dotnet/svc
• Руководство по основам .NET (прежнее название — руководство по .NET Standard) dotnet-fundamentals/svc
• Руководство по основам .NET (прежнее название — руководство по .NET Core) dotnet-core/svc
• Руководство по .NET Framework . dotnet-framework/svc
• Справочник по API — dotnet-api/svc
• Руководство по C# — dotnet-csharp/svc
• Руководство по F# dotnet-fsharp/svc
• Руководство по Visual Basic . dotnet-visualbasic/svc
• Руководство по ML.NET — dotnet-ml/svc
• Пакет SDK для Azure .NET — dotnet-azure/svc
• Руководство по рабочему столу .NET. dotnet-desktop/svc

Другие метки продуктов определяются для областей применения, которые пересекают границы репозиториев.

Поиск проблем для одного раздела руководства

Руководства .NET объемные, поэтому эти метки дополнительно ограничивают область в соответствии с разделом руководства. Каждый раздел .NET Guide отмечается суффиксом /subsvc и имеет светло-синий фон. Многие из этих меток применяются к нескольким руководствам, а другие — только в одном руководстве. После фильтрации области добавьте одну из этих меток, чтобы дополнительно ограничить область проблем.

Релизы

Проблемы, помеченные для определенного выпуска, отмечены :checkered_flag: Release: префиксом и имеют темно-желтый фон.

Что касается других меток

Существует множество других меток, используемых командами содержимого для управления различными классификациями проблем. Если вы не находитесь в группе содержимого, вы можете игнорировать эти другие метки.

Проекты

Проекты предназначены для планирования, где приоритетная работа автоматизирована с помощью доски Kanban. Проекты должны содержать только проблемы с GitHub, а не запросы на вытягивание. Проекты отличаются от вех в том, что вехи обычно содержат запросы на вытягивание. Мы следим за вехами, чтобы убедиться, что запросы на вытягивание не устаревают.

Мы используем проекты двумя способами:

• Month YYYY Типы проектов: это Kanban-доски для рабочего плана на каждый месяц.
• Длительные эпические эпосы: они используются для организации задач в направлении цели, когда работа будет происходить в течение нескольких месяцев.

Вехи

Вехи обычно соответствуют одному соглашению об именовании проектов Month YYYY, но они отличаются от проектов. Мы используем вехи для отслеживания завершенной работы. Вехи не должны содержать задачи, а исключительно пулл-реквесты. Текущая веха автоматически применяется к новым pull requests.