Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • AsciiDoc Language AsciiDoc Language
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 20
    • Issues 20
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1
    • Merge requests 1
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Code review
    • Insights
    • Issue
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Eclipse ProjectsEclipse Projects
  • AsciiDoc Language
  • AsciiDoc LanguageAsciiDoc Language
  • Issues
  • #3
Closed
Open
Issue created Mar 31, 2021 by Sarah White@swhitesalMaintainer

Set up project labels to compliment contribution workflow

The project should have a set of labels that communicate key information about an issue or MR. These labels should correspond to common events in the contribution workflow and help the community filter contributions by domain, kind, status, maintainer responsibility, etc.

I've added and defined a few preliminary labels to the project. They're serving as examples of some of the label categories I've proposed and to help us triage the initial issues that are filed. The triage::<value> labels are also an example of a scoped label. Assigning one triage label automatically unassigns any other triage label. status::<value> is also scoped.

I've rather shamelessly studied and borrowed from both the Kubernetes issue triaging process and the Eclipse Che repository labels because our long term goal should be to automate parts of issue triage and assessment process as well as MR testing and review so contributions get prompt feedback.

Below is a list of proposed labels. This list is by no means complete. For definitions see Labels and the attached "Issue Journey" (aka picture from my whiteboard)

kind/bug
kind/cleanup
kind/api-change
kind/process
kind/feature
kind/failing-test
kind/syntax-change
kind/dependency

area/spec-doc/content
area/spec-doc/organization
area/performance
area/DOM
area/release-plan
area/naming-and-terminology
area/architecture
area/converter

group/TCK
group/spec-doc
group/release

needs-triage
triage::accepted
triage::assessment-required
triage::need-information
triage::declined
triage::duplicate
triage::out-of-scope
triage::discuss
triage::not-reproducible

help wanted
good first issue

status::open
status::active
status::hold
status::frozen

assessment::call-for-team
assessment::hold
assessment::active
assessment::complete

assessment replaces the arch-review described in the contributing guide and governance document. @mojavelinux felt like review might get confused with MR review actions/steps.

Feedback and suggestions are definitely welcome and encouraged!

The final result of this issue will be a set of labels primarily for issues. These labels will no doubt evolve as our process matures.

issue-journey

Assignee
Assign to
Time tracking

Copyright © Eclipse Foundation, Inc. All Rights Reserved.     Privacy Policy | Terms of Use | Copyright Agent