You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/CONTRIBUTING.md
+32-17Lines changed: 32 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,29 +2,29 @@
2
2
3
3
Hi! Thanks for your interest in contributing to the GitHub CLI!
4
4
5
-
We accept pull requests for bug fixes and features where we've discussed the approach in an issue and given the go-ahead for a community member to work on it. We'd also love to hear about ideas for new features as issues.
5
+
We accept pull requests for issues labelled `help wanted`. We encourage issues and discussion posts for all other contributions.
6
6
7
-
Please do:
7
+
### Please do:
8
8
9
-
* Check existing issues to verify that the [bug][bug issues] or [feature request][feature request issues] has not already been submitted.
10
-
* Open an issue if things aren't working as expected.
11
-
* Open an issue to propose a significant change.
12
-
* Open a pull request to fix a bug.
13
-
* Open a pull request to fix documentation about a command.
14
-
* Open a pull request for any issue labelled [`help wanted`][hw] or [`good first issue`][gfi].
9
+
* Check issues to verify that a [bug][bug issues] or [feature request][feature request issues] issue does not already exist for the same problem or feature
10
+
* Open an issue if things aren't working as expected
11
+
* Open an issue to propose a change
12
+
* Open an issue to propose a design for an issue labelled [`needs-design` and `help wanted`][needs design and help wanted], following the [proposing a design guidelines](#proposing-a-design) instructions below
13
+
* Open an issue to propose a new community supported `gh` package with details about support and redistribution
14
+
* Mention `@cli/code-reviewers` when an issue you want to work on does not have clear Acceptance Criteria
15
+
* Open a pull request for any issue labelled [`help wanted`][hw] and [`good first issue`][gfi]
15
16
16
-
Please avoid:
17
+
### Please _do NOT_:
17
18
18
-
* Opening pull requests for issues marked `needs-design`, `needs-investigation`, or `blocked`.
19
-
* Opening pull requests that haven't been approved for work in an issue
20
-
* Adding installation instructions specifically for your OS/package manager.
21
-
* Opening pull requests for any issue marked `core`. These issues require additional context from
22
-
the core CLI team at GitHub and any external pull requests will not be accepted.
19
+
* Open a pull request for issues without the `help wanted` label or explicit Acceptance Criteria
20
+
* Expand pull request scope to include changes that are not described in the issue's Acceptance Criteria
21
+
* Open pull requests for any issue marked `core`. These issues require additional context from
22
+
the core CLI team at GitHub and any external pull requests will not be accepted
23
23
24
24
## Building the project
25
25
26
26
Prerequisites:
27
-
- Go 1.22+
27
+
- Go 1.26+
28
28
29
29
Build with:
30
30
* Unix-like systems: `make`
@@ -52,7 +52,21 @@ We generate manual pages from source on every release. You do not need to submit
52
52
53
53
## Design guidelines
54
54
55
-
You may reference the [CLI Design System][] when suggesting features, and are welcome to use our [Google Docs Template][] to suggest designs.
55
+
### Proposing a design
56
+
57
+
You may propose a design to solve an open bug or feature request issue that has both [the `needs-design` and `help-wanted` labels][needs design and help wanted].
58
+
59
+
To propose a design:
60
+
61
+
- Open a new issue using the [design proposal issue template](./ISSUE_TEMPLATE/submit-a-design-proposal.md).
62
+
- Include a link to the issue that the design is for.
63
+
- Describe the design you are proposing to resolve the issue, leveraging the [CLI Design System][].
64
+
- Mock up the design you are proposing using our [Google Docs Template][] or code blocks.
65
+
- Mock ups should clearly illustrate the command(s) being run and the expected output(s).
66
+
67
+
### (core team only) Reviewing a design
68
+
69
+
A member of the core team will [triage](../docs/triage.md) the design proposal. Once a member of the core team has reviewed the design, they may add the [`help wanted`][hw] label to the issue, so a PR can be opened to provide the implementation.
56
70
57
71
## Resources
58
72
@@ -62,6 +76,7 @@ You may reference the [CLI Design System][] when suggesting features, and are we
about: Submit a design to resolve an open issue that has both `needs-design` and `help-wanted` labels
4
+
title: ''
5
+
labels: ''
6
+
assignees: ''
7
+
8
+
---
9
+
10
+
<!-- See [CONTRIBUTING.md](../CONTRIBUTING.md#proposing-a-design) for more information.-->
11
+
12
+
### Link to issue for design submission
13
+
14
+
<!--
15
+
Provide a link to the issue this design is for.
16
+
17
+
All design submissions must be linked to an open issue that
18
+
has both the `needs-design` and `help-wanted` labels.
19
+
-->
20
+
21
+
### Proposed Design
22
+
23
+
<!--
24
+
Describe the design you are proposing to resolve the issue.
25
+
26
+
All CLI designs must adhere to the [Primer CLI design reference](https://primer.style/cli/).
27
+
-->
28
+
29
+
### Mockup
30
+
31
+
<!--
32
+
Provide a mockup of the design you are proposing. All mockups should clearly illustrate the command(s) being run and the expected output(s).
33
+
34
+
When color and formatting are important, consider using our [CLI design Google Docs Template](https://docs.google.com/document/d/1JIRErIUuJ6fTgabiFYfCH3x91pyHuytbfa0QLnTfXKM/edit#heading=h.or54sa47ylpg).
35
+
36
+
Code blocks can also be used to submit a design mockup - remember to include the command(s) being run. Example:
37
+
38
+
```shell
39
+
$ gh issue list --json title -L 5
40
+
[
41
+
{
42
+
"title": "`gh pr checks <pr> --required` should not fail when there are no required checks"
43
+
},
44
+
{
45
+
"title": "gh pr view commits should include commit description"
46
+
},
47
+
{
48
+
"title": "Adapt the color of the device code to the color used by the terminal"
49
+
},
50
+
{
51
+
"title": "`gh pr create` does not default to fork when user has write access to upstream"
0 commit comments