Part 1
요약·해설
Enhancement·Feature request·Feature·Hardware Support·Meta 분류, priority, assignee와 milestone 규칙을 정리합니다.
5 GitHub labels
TSC · priority · owner
Roadmap → release
Part 2
접을 수 있는 영어 원문 전체
영어 원문 전체 펼치기
5124068FF8E991929E418EF20831E0BD9625971DF3A05D563322268944FE01CB
.. _feature-tracking:
Feature Tracking
#################
For feature tracking we use Github labels to classify new features and
enhancements. The following is the description of each category:
Enhancement
Changes to existing features that are not considered a bug and would not
block a release. This is an incremental enhancement to a feature that already
exists in Zephyr.
Feature request
A request for the implementation or inclusion of a new unit of functionality
that is not part of any release plans yet, that has not been vetted, and needs
further discussion and details.
Feature
A committed and planned unit of functionality with a detailed design and
implementation proposal and an owner. Features must go through an RFC process
and must be vetted and discussed in the TSC before a target milestone is set.
Hardware Support
A request or plan to port an existing feature or enhancement to a particular
hardware platform. This ranges from porting Zephyr itself to a new
architecture, SoC or board to adding an implementation of a peripheral driver
API for an existing hardware platform.
Meta
A label to group other GitHub issues that are part of a single feature or unit
of work.
The following workflow should be used to process features:.
This is the formal way for asking for a new feature in Zephyr and indicating its
importance to the project. Often, the requester may have a readiness and
willingness to drive implementation of the feature in an upcoming release, and
should assign the request to themselves.
If not though, an owner will be assigned after evaluation by the TSC.
A feature request can also have a companion RFC with more details on the feature
and a proposed design or implementation.
- Label new features requests as ``feature-request``
- The TSC discusses new ``feature-request`` items regularly and triages them.
Items are examined for similarity with existing features, how they fit with
the project goals and other timeline considerations. The priority is
determined as follows:
- High = Next milestone
- Medium = As soon as possible
- Low = Best effort
- After the initial discussion and triaging, the label is moved from
``feature-request`` to ``feature`` with the target milestone and an assignee.
All items marked as ``feature-request`` are non-binding and those without an
assignee are open for grabs, meaning that they can be picked up and implemented
by any project member or the community. You should contact an assigned owner if
you'd like to discuss or contribute to that feature's implementation
Roadmap and Release Plans
*************************
Project roadmaps and release plans are both important tools for the project, but
they have very different purposes and should not be confused. A project roadmap
communicates the high-level overview of a project's strategy, while a release
plan is a tactical document designed to capture and track the features planned
for upcoming releases.
- The project roadmap communicates the why; a release plan details the what
- A release plan spans only a few months; a product roadmap might cover a year
or more
Project Roadmap
================
The project roadmap should serve as a high-level, visual summary of the
project's strategic objectives and expectations.
If built properly, the roadmap can be a valuable tool for several reasons. It
can help the project present its plan in a compelling way to existing and new
stakeholders, to help recruit new members and it can be a helpful resource the
team and community can refer to throughout the project's development, to ensure
they are still executing according to plan.
As such, the roadmap should contain only strategic-level details, major project
themes, epics, and goals.
Release Plans
==============
The release plan comes into play when the project roadmap's high-level strategy
is translated into an actionable plan built on specific features, enhancements,
and fixes that need to go into a specific release or milestone.
The release plan communicates those features and enhancements slated for your
project' next release (or the next few releases). So it acts as more of a
project plan, breaking the big ideas down into smaller projects the community
and main stakeholders of the project can make progress on.
Items labeled as ``features`` are short or long term release items that shall
have an assignee and a milestone set.
Part 3
한국어 전문 번역
Feature tracking에는 GitHub label을 사용해 새 feature와 enhancement를 분류합니다. 각 category의 의미는 다음과 같습니다.
Enhancement- Bug가 아니며 release를 막지 않는 기존 feature 변경입니다. Zephyr에 이미 존재하는 feature를 점진적으로 개선합니다.
Feature request- 아직 release plan에 포함되지 않았고 검토·승인되지 않아 추가 discussion과 detail이 필요한 새 functionality 구현 또는 포함 요청입니다.
Feature- 상세 design·implementation proposal과 owner가 있는, 확정되고 계획된 functionality 단위입니다. RFC process를 거쳐야 하며 target milestone을 정하기 전에 TSC에서 검토하고 논의해야 합니다.
Hardware Support- 기존 feature 또는 enhancement를 특정 hardware platform으로 port하자는 요청이나 계획입니다. 새 architecture·SoC·board로 Zephyr를 port하는 일부터 기존 platform에 peripheral-driver API implementation을 추가하는 일까지 포함합니다.
Meta- 하나의 feature 또는 작업 단위를 구성하는 여러 GitHub issue를 묶는 label입니다.
새 feature를 요청하고 project에서의 중요도를 나타내는 공식 workflow는 다음과 같습니다. Requester가 다음 release에서 직접 구현할 준비와 의지가 있다면 자신을 assignee로 지정해야 합니다. 그렇지 않으면 TSC 평가 뒤 owner가 지정됩니다. Feature request에는 더 자세한 설명과 proposed design·implementation을 담은 RFC가 함께 있을 수 있습니다.
- 새 feature request에
feature-requestlabel을 붙입니다. - TSC는 새
feature-request를 정기적으로 논의하고 triage합니다. 기존 feature와의 유사성, project goal과의 적합성, 일정 요인을 검토합니다. Priority는 High=다음 milestone, Medium=가능한 한 빨리, Low=best effort로 정합니다. - 초기 discussion과 triage가 끝나면 label을
feature-request에서feature로 바꾸고 target milestone과 assignee를 지정합니다.
feature-request label이 붙은 모든 항목은 구속력이 없습니다. Assignee가 없는 항목은 누구나 맡을 수 있으므로 project member나 community가 선택해 구현할 수 있습니다. 이미 owner가 지정되어 있다면 구현을 논의하거나 기여하기 전에 해당 owner에게 연락해야 합니다.
Roadmap과 Release Plan
Project roadmap과 release plan은 모두 중요한 도구지만 목적이 매우 다르므로 혼동하면 안 됩니다. Roadmap은 project strategy의 상위 개요를 전달하고, release plan은 앞으로의 release에 계획한 feature를 담고 추적하는 tactical document입니다.
- Project roadmap은 왜 하는지를 전달하고 release plan은 무엇을 하는지 구체화합니다.
- Release plan은 몇 달만 다루지만 product roadmap은 1년 이상을 포괄할 수 있습니다.
Project Roadmap
Project roadmap은 strategic objective와 expectation을 높은 수준에서 시각적으로 요약해야 합니다.
잘 만든 roadmap은 기존·신규 stakeholder에게 project plan을 설득력 있게 보여 주고 새 member를 모집하는 데 도움이 됩니다. 개발 기간 내내 team과 community가 계획대로 실행하고 있는지 확인할 공통 reference가 되기도 합니다.
따라서 roadmap에는 strategic-level detail, major project theme, epic, goal만 포함해야 합니다.
Release Plan
Release plan은 roadmap의 상위 strategy를 특정 release 또는 milestone에 들어갈 구체적인 feature, enhancement, fix를 기반으로 실행 가능한 plan으로 옮길 때 사용합니다.
다음 release 또는 몇 개 release에 예정된 feature와 enhancement를 전달하며, 큰 idea를 community와 주요 stakeholder가 진전시킬 수 있는 작은 project로 나누는 project plan 역할을 합니다.
feature label이 붙은 항목은 단기 또는 장기 release item이며 assignee와 milestone이 반드시 지정되어야 합니다.
Source
출처
영어 원문에는 문단, 문서 지시문, 표, 코드, 코드 심벌, 경로를 그대로 보존했습니다.