Sep 8, 2025 · Sep 4, 2025 · Sep 4, 2025 · Sep 4, 2025
diff --git a/docs/about/contributing/CONTRIBUTING.md b/docs/about/contributing/CONTRIBUTING.md

 - [Frontend styling guide](./frontend.md#styling)

 ## Pull Requests

 We welcome pull requests (PRs) from community members including (but not limited to) open source users, enthusiasts, and enterprise customers.

 We will ask that you sign a Contributor License Agreement before we accept any contributions into our repo.

 Please keep PRs small and self-contained. This allows code reviewers (see below) to focus and fully understand the PR. A good rule of thumb is less than 1000 lines changed. (One exception is a mechanistic refactor, like renaming, that is conceptually trivial but might have a large line count.)

 If your intended feature or refactor will be larger than this:

 1. Open an issue explaining what you intend to build, how it will work, and that you are volunteering to do the development. Include `@coder/community-triage` in the body.
 2. Give the maintainers a chance to respond. Changes to the visual, interaction, or software design are easier to adjust before you start laying down code.
 3. Break your work up into a series of smaller PRs.

 Stacking tools like [Graphite](https://www.graphite.dev) are useful for keeping a series of PRs that build on each other up to date as they are reviewed and merged.

 Each PR:

 - Must individually build and pass all tests, including formatting and linting.
 - Must not introduce regressions or backward-compatibility issues, even if a subsequent PR in your series would resolve the issue.
 - Should be a conceptually coherent change set.

 In practice, many of these smaller PRs will be invisible to end users, and that is ok. For example, you might introduce
 a new Go package that implements the core business logic of a feature in one PR, but only later actually "wire it up"
 to a new API route in a later PR. Or, you might implement a new React component in one PR, and only in a later PR place it on a page.

 ## Reviews

 The following information has been borrowed from [Go's review philosophy](https://go.dev/doc/contribute#reviews).
Original file line number	Diff line number	Diff line change
Expand Up		@@ -148,6 +148,32 @@ channel.

		- [Frontend styling guide](./frontend.md#styling)

		## Pull Requests
Copy link Contributor dannykoppingSep 4, 2025 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. This section feels like it could absorbhttps://coder.com/docs/about/contributing/CONTRIBUTING#reviews, and make it more concise.

		We welcome pull requests (PRs) from community members including (but not limited to) open source users, enthusiasts, and enterprise customers.

		We will ask that you sign a Contributor License Agreement before we accept any contributions into our repo.

		Please keep PRs small and self-contained. This allows code reviewers (see below) to focus and fully understand the PR. A good rule of thumb is less than 1000 lines changed. (One exception is a mechanistic refactor, like renaming, that is conceptually trivial but might have a large line count.)

		If your intended feature or refactor will be larger than this:

		1. Open an issue explaining what you intend to build, how it will work, and that you are volunteering to do the development. Include `@coder/community-triage` in the body.
		2. Give the maintainers a chance to respond. Changes to the visual, interaction, or software design are easier to adjust before you start laying down code.
		3. Break your work up into a series of smaller PRs.

		Stacking tools like [Graphite](https://www.graphite.dev) are useful for keeping a series of PRs that build on each other up to date as they are reviewed and merged.

		Each PR:

		- Must individually build and pass all tests, including formatting and linting.
		- Must not introduce regressions or backward-compatibility issues, even if a subsequent PR in your series would resolve the issue.
		- Should be a conceptually coherent change set.
johnstcn marked this conversation as resolved. Show resolvedHide resolved

		In practice, many of these smaller PRs will be invisible to end users, and that is ok. For example, you might introduce
		a new Go package that implements the core business logic of a feature in one PR, but only later actually "wire it up"
		to a new API route in a later PR. Or, you might implement a new React component in one PR, and only in a later PR place it on a page.
dannykopping marked this conversation as resolved. Show resolvedHide resolved

		## Reviews

		The following information has been borrowed from [Go's review philosophy](https://go.dev/doc/contribute#reviews).
Expand Down