Skip to content

Commit

Permalink
docs: create issue label documentation (#33)
Browse files Browse the repository at this point in the history
  • Loading branch information
JamieMagee authored Jan 3, 2022
1 parent c13e1d1 commit 8b392ce
Show file tree
Hide file tree
Showing 4 changed files with 97 additions and 42 deletions.
22 changes: 0 additions & 22 deletions .github/labeler.yml

This file was deleted.

16 changes: 6 additions & 10 deletions .github/release-drafter.yml
Original file line number Diff line number Diff line change
Expand Up @@ -10,20 +10,19 @@ change-template: '- $TITLE by @$AUTHOR (#$NUMBER)'
change-title-escapes: '\<*_&' # You can add # and @ to disable mentions, and add ` to disable code blocks.
no-changes-template: '- No changes'
categories:
- title: '📚 Documentation'
- title: '📝 Documentation'
labels:
- 'documentation'
- 'type:docs'
- title: '🚀 New Features'
labels:
- 'enhancement'
- 'type:feature'
- title: '🐛 Bug Fixes'
labels:
- 'bug'
- 'type:bug'
- title: '🧰 Maintenance'
labels:
- 'repo-configuration'
- 'scripts'
- 'build'
- 'type:ci'
- 'type:refactor'
version-resolver:
major:
labels:
Expand All @@ -38,6 +37,3 @@ version-resolver:
template: |
## ⚙️ Changes
$CHANGES
## 👨🏼‍💻 Contributors
$CONTRIBUTORS
10 changes: 0 additions & 10 deletions .github/workflows/labeler.yml

This file was deleted.

91 changes: 91 additions & 0 deletions docs/issue-labeling.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,91 @@
# Issue labeling

We try to keep issues well-classified through use of labels.
Any repository collaborator can apply labels according to the below guidelines.

The general idea is that we have:

- status (`status:`)
- type (`type:`)
- detector (`detector:`)
- version (`version:`)

## Label categories

### Status

<details>
<summary>Status labels</summary>

status:requirements
status:blocked
status:ready
status:in-progress
status:waiting-on-response

</details>

Use these to label the status of an issue.
For example, use `status:requirements` to mean that an issue is not yet ready for development to begin.
If we need the original poster or somebody else to respond to a query of ours, apply the `status:waiting-on-response` label.
All open issues should have some `status:*` label applied, and [this search](https://github.com/microsoft/component-detection/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+-label%3Astatus%3Arequirements+-label%3Astatus%3Aready+-label%3Astatus%3Ain-progress+-label%3Astatus%3Ablocked+-label%3Astatus%3Awaiting-on-response) can identify any which are missing a status label.

### Type

<details>
<summary>Type labels</summary>

type:bug
type:docs
type:feature
type:refactor
type:help
type:ci

</details>

Use these to label the type of issue.
For example, use `type:bug` to label a bug type issue, and use `type:feature` for feature requests.
Only use `type:refactor` for code changes, don't use `type:refactor` for documentation type changes.
Use the `type:help` label for issues which should be converted to a discussion post.
The `type:ci` label is for issues related to builds or GitHub Actions.

Any issue which has the label `status:ready` should also have a `type:*` label, and [this search](https://github.com/microsoft/component-detection/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+-label%3Atype%3Abug+label%3Astatus%3Aready+-label%3Atype%3Afeature+-label%3Atype%3Adocs+-label%3Atype%3Arefactor+-label%3Atype%3Aci) can identify any which are missing one.

### Detector

Add the relevant `detector:` labels to the issue.
If there are multiple detectors affected, add labels for all of them.

### Version

<details>
<summary>Version labels</summary>

version:major
version:minor
version:patch

</details>

We use [release drafter](https://github.com/release-drafter/release-drafter) to automatically create new releases.
It generates the next version based on labels of the PRs since the last release.
If no label is applied the default is `version:patch`.

### Housekeeping

<details>
<summary>Housekeeping</summary>

good first issue
help wanted
duplicate

</details>

Add a label `good first issue` to issues that are small, easy to fix, and do-able for a newcomer.
This label is sometimes picked up by tools or websites that try to encourage people to contribute to open source.

Add the label `help wanted` to indicate that we need the original poster or someone else to do some work or it is unlikely to get done.

Add a label `duplicate` to issues/PRs that are a duplicate of an earlier issue/PR.

0 comments on commit 8b392ce

Please sign in to comment.