Field

Definition

author

An audit field that is automatically set to the creator of the issue or PR.

title

A brief summary of the contents of the issue or pull request

Business rules:

·       Required always

description

The first comment box after the title is the description.  It provides the long description regarding what the issue or pull request is about.  For pull requests, the description contains the body of the commit message and additional metadata used by GitHub for automation purposes, such as "Fixes #" tags.

Business rules:

·       Required always

comments

Every comment box after description forms a running log of the community discussion of the issue or pull request. Diagnostic information from automation or bots may appear in comments as well.

assignees

If assigned, the assignee has assumed responsibility and is the point of contact for coordinating work on the issue.  The assignee must be a project member.  For pull requests, this field has no special meaning: if set, it is usually set to the author.

Business rules:

·       Required for all in-progress issues

·       Recommended for all release backlog issues
(apply help wanted label for all unassigned backlog)

reviewers

(Pull requests only.) List of project members who are solicited to review the pull request.

labels

Labels are used to implement virtual fields.  See "Virtual Field Definitions" below.

projects

Projects are used by EdgeX working groups to subscribe to the status of an issue on their project board. One of these working groups is responsible for managing the Issue through its lifecycle. An Issue may be on multiple boards simultaneously.

milestone

All milestones in EdgeX refer to releases.  The milestone field is used to include the issue in this release's backlog.  It indicates a commitment to resolve the issue by the named milestone.  (For retroactive milestones, it would be used to flag the issue as "wontfix".) Milestone is a single-select field: only one milestone can be selected at a time.

Virtual Field

Definition

issue_type

Indicates the type of issue (single-select):

• bug — A reactive change or broken functionality
• ci — Has to do with testing, building, packaging, et cetera.
• enhancement — A planned feature or change.
• question — A question.
• request for comments — Means "we have a proposal for a big architectural feature and we want some public feedback on it."
• security_audit — The issue is about a security problem with the project that is okay to be publicly known. (There is a private vulnerability reporting process for confidential security bugs.)
• tech-debt — The issue is about refactoring existing code to improve its design or to remove a previously-added workaround.

Business rules:

• Required always.

close_reason

Explains why an issue was closed (without a fix) (single-select):

• duplicate — Is substantially the same as another issue.
• invalid — Something is substantially wrong with the issue such that it can't move forward (for example, a bug report filed against a feature that is provided by a third-party).
• wontfix — Used to document that the issue is valid but that not resources will be put into fixing the issue. Often used to indicate that a bug won't be fixed on a previous release.

Business rules:

• Required for all issues closed without a fix.
• A comment explaining why the Issue was dispositioned is required.

subsystem_affected

Indicates the scope of the proposed change (multiple-select):

• app-services
• core-services
• device-services
• documentation
• export-services
• security-services
• snap — Cross-cutting label for any Issue that requires changes to the snap packaging of EdgeX
• support-services
• system-management

release_affected

A multiple-select field used for bugs only that indicates a release of EdgeX which is affected by the issue. Note, there may be multiple release_affected labels if the issue exists in more than one EdgeX release.  For feature development work, the milestone field is the official field used for release planning. (This changes the current practice so there will be a transition period where both fields are used.)  If multiple release_affected tags exist and the issue is only fixed in one of these releases resulting in the issue being closed, if any of affected releases is either an active development release or an LTS release, then a new issue should be opened with release_affected set accordingly. This allows the issue to continue to be tracked in the other affected releases where it makes sense to do so.

Values:

• california
• california dot - 0.6.1
• delhi
• delhi dot - 0.7.1
• edinburgh
• fuji
• geneva
• geneva-f2f — An additional tag that that signifies that the issue belongs to a committed roadmap item at the Geneva planning face-to-face.
• hanoi
• hanoi-f2f — An additional tag that that signifies that the issue belongs to a committed roadmap item at the Hanoi planning face-to-face.
• unscoped — Indicates that the work is not targeted for any release.

Business rules:

• Required for all bug type issues requiring a code change

Exceptions:

• Special procedures are required (see below) for issues that affect multiple releases.

exception

Indicates an exceptional condition outside of the normal workflow (multiple-select):

• hold — Used on pull requests only.  Indicates that the pull request should not be merged despite successful pre-commit tests and approvals.  Contact the PR author for additional details.
• good first issue — Used to advertise an issue that is easy to approach and easy to finish and would be appropriate for a new contributor to the project to tackle.
• help wanted — Used to advertise the issue as something the project wants done, but the project doesn't have anyone assigned to work on it or does not have the required expertise to do it well.

priority

Priority is used to influence where to put resources and what features to cut when a release window is closing (single-select).  The permissible values for priority and suggested guidance around their usage are:

• 3-high — Indicates a release-blocking issue
• 2-medium — Indicates cross-cutting project impact
• 1-low — Used for isolated changes

Status

Meaning

new issue

Default state for incoming issues when assigned a project.  New issues require triage into either "icebox" or "release backlog" status.

icebox

There are no current plans to work on the issue in the near-term.

release backlog

The issue is planned for the upcoming release or be retroactively fixed for a previous release.

in progress

Someone has started working on the issue

QA/Code Review

A state reserved for pull requests that have not been approved.  GitHub automation automatically places new pull requests here.

Done

Terminal state for all issues and pull requests.  GitHub automation will move issues and pull requests here automatically when they are closed.