kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update parts of the contributor guide to match the style guide 

Edit parts of the Contributor Guide to match the Kubernetes
Documentation style guide. This PR updates the following:

- the GitHub Workflow document
- the Help Wanted guide
- the Coding Conventions document

Co-authored-by: Joel Barker <joel@lionswaycontent.com>
Co-authored-by: Bob Killen <killen.bob@gmail.com>
This commit is contained in:
Erik L. Arneson 2022-01-06 11:53:08 -08:00
parent ee18898805
commit 7df15f70b7
3 changed files with 144 additions and 236 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

138
contributors/guide/coding-conventions.md
View File

@ -2,133 +2,61 @@
title: "Coding Conventions"
weight: 8
description: |
A collection of guidelines, style suggestions, and tips for writing code in
the different programming languages used throughout the project.
This document outlines a collection of guidelines, style suggestions, and tips
for writing code in the different programming languages used throughout the
Kubernetes project.
---
**Table of Contents**
- [Coding Conventions](#coding-conventions)
- [Code conventions](#code-conventions)
- [Testing conventions](#testing-conventions)
- [Directory and file conventions](#directory-and-file-conventions)
## Code conventions
- Bash
- https://google.github.io/styleguide/shell.xml
- Ensure that build, release, test, and cluster-management scripts run on
macOS
- Ensure that build, release, test, and cluster-management scripts run on macOS
- Go
- [Go Code Review
Comments](https://github.com/golang/go/wiki/CodeReviewComments)
- [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments)
- [Effective Go](https://golang.org/doc/effective_go.html)
- Know and avoid [Go landmines](https://gist.github.com/lavalamp/4bd23295a9f32706a48f)
- Comment your code.
- [Go's commenting
conventions](http://blog.golang.org/godoc-documenting-go-code)
- If reviewers ask questions about why the code is the way it is, that's a
sign that comments might be helpful.
- [Go's commenting conventions](http://blog.golang.org/godoc-documenting-go-code)
- If reviewers ask questions about why the code is the way it is, that's a sign that comments might be helpful.
- Command-line flags should use dashes, not underscores
- Naming
- Please consider package name when selecting an interface name, and avoid
redundancy.
- e.g.: `storage.Interface` is better than `storage.StorageInterface`.
- Do not use uppercase characters, underscores, or dashes in package
names.
- Please consider parent directory name when choosing a package name.
- so pkg/controllers/autoscaler/foo.go should say `package autoscaler`
not `package autoscalercontroller`.
- Unless there's a good reason, the `package foo` line should match
the name of the directory in which the .go file exists.
- Please consider package name when selecting an interface name, and avoid redundancy. For example, `storage.Interface` is better than `storage.StorageInterface`.
- Do not use uppercase characters, underscores, or dashes in package names.
- Please consider parent directory name when choosing a package name. For example, `pkg/controllers/autoscaler/foo.go` should say `package autoscaler` not `package autoscalercontroller`.
- Unless there's a good reason, the `package foo` line should match the name of the directory in which the `.go` file exists.
- Importers can use a different name if they need to disambiguate.
- Locks should be called `lock` and should never be embedded (always `lock
sync.Mutex`). When multiple locks are present, give each lock a distinct name
following Go conventions - `stateLock`, `mapLock` etc.
- Locks should be called `lock` and should never be embedded (always `lock sync.Mutex`). When multiple locks are present, give each lock a distinct name following Go conventions: `stateLock`, `mapLock` etc.
- [API changes](/contributors/devel/sig-architecture/api_changes.md)
- [API conventions](/contributors/devel/sig-architecture/api-conventions.md)
- [Kubectl conventions](/contributors/devel/sig-cli/kubectl-conventions.md)
- [Logging conventions](/contributors/devel/sig-instrumentation/logging.md)
## Testing conventions
- All new packages and most new significant functionality must come with unit
tests
- Table-driven tests are preferred for testing multiple scenarios/inputs; for
example, see [TestNamespaceAuthorization](https://git.k8s.io/kubernetes/test/integration/auth/auth_test.go)
- Significant features should come with integration (test/integration) and/or
[end-to-end (test/e2e) tests](/contributors/devel/sig-testing/e2e-tests.md)
- Including new kubectl commands and major features of existing commands
- Unit tests must pass on macOS and Windows platforms - if you use Linux
specific features, your test case must either be skipped on windows or compiled
out (skipped is better when running Linux specific commands, compiled out is
required when your code does not compile on Windows).
- Avoid relying on Docker hub (e.g. pull from Docker hub). Use gcr.io instead.
- Avoid waiting for a short amount of time (or without waiting) and expect an
asynchronous thing to happen (e.g. wait for 1 seconds and expect a Pod to be
running). Wait and retry instead.
- All new packages and most new significant functionality must come with unit tests.
- Table-driven tests are preferred for testing multiple scenarios/inputs. For an example, see [TestNamespaceAuthorization](https://git.k8s.io/kubernetes/test/integration/auth/auth_test.go).
- Significant features should come with integration (test/integration) and/or [end-to-end (test/e2e) tests](/contributors/devel/sig-testing/e2e-tests.md).
- Including new `kubectl` commands and major features of existing commands.
- Unit tests must pass on macOS and Windows platforms - if you use Linux specific features, your test case must either be skipped on windows or compiled out (skipped is better when running Linux specific commands, compiled out is required when your code does not compile on Windows).
- Avoid relying on Docker Hub. Use the [Google Cloud Container Registry](https://gcr.io) instead.
- Do not expect an asynchronous thing to happen immediately---do not wait for one second and expect a pod to be running. Wait and retry instead.
- See the [testing guide](/contributors/devel/sig-testing/testing.md) for additional testing advice.
## Directory and file conventions
- Avoid package sprawl. Find an appropriate subdirectory for new packages.
(See [#4851](http://issues.k8s.io/4851) for discussion.)
- Libraries with no more appropriate home belong in new package
subdirectories of pkg/util
- Avoid general utility packages. Packages called "util" are suspect. Instead,
derive a name that describes your desired function. For example, the utility
functions dealing with waiting for operations are in the "wait" package and
include functionality like Poll. So the full name is wait.Poll
- All filenames should be lowercase
- Go source files and directories use underscores, not dashes
- Package directories should generally avoid using separators as much as
possible (when packages are multiple words, they usually should be in nested
subdirectories).
- Document directories and filenames should use dashes rather than underscores
- Contrived examples that illustrate system features belong in
/docs/user-guide or /docs/admin, depending on whether it is a feature primarily
intended for users that deploy applications or cluster administrators,
respectively. Actual application examples belong in /examples.
- Examples should also illustrate [best practices for configuration and using the system](https://kubernetes.io/docs/concepts/configuration/overview/)
- Third-party code
- Go code for normal third-party dependencies is managed using
[go modules](https://github.com/golang/go/wiki/Modules) and is described in the kubernetes
[vendoring guide](/contributors/devel/sig-architecture/vendor.md)
- Other third-party code belongs in `/third_party`
- forked third party Go code goes in `/third_party/forked`
- forked _golang stdlib_ code goes in `/third_party/forked/golang`
- Third-party code must include licenses
- This includes modified third-party code and excerpts, as well
- Avoid package sprawl. Find an appropriate subdirectory for new packages. [See issue #4851](http://issues.k8s.io/4851) for discussion.
- Libraries with no appropriate home belong in new package subdirectories of `pkg/util`.
- Avoid general utility packages. Packages called "util" are suspect. Instead, derive a name that describes your desired function. For example, the utility functions dealing with waiting for operations are in the `wait` package and include functionality like `Poll`. The full name is `wait.Poll`.
- All filenames should be lowercase.
- Go source files and directories use underscores, not dashes.
- Package directories should generally avoid using separators as much as possible. When package names are multiple words, they usually should be in nested subdirectories.
- Document directories and filenames should use dashes rather than underscores.
- Examples should also illustrate [best practices for configuration and using the system](https://kubernetes.io/docs/concepts/configuration/overview/).
- Follow these conventions for third-party code:
- Go code for normal third-party dependencies is managed using [go modules](https://github.com/golang/go/wiki/Modules) and is described in the kubernetes [vendoring guide](/contributors/devel/sig-architecture/vendor.md).
- Other third-party code belongs in `third_party`.
- forked third party Go code goes in `third_party/forked`.
- forked _golang stdlib_ code goes in `third_party/forked/golang`.
- Third-party code must include licenses. This includes modified third-party code and excerpts, as well.

147
contributors/guide/github-workflow.md
View File

@ -2,43 +2,42 @@
title: "GitHub Workflow"
weight: 6
description: |
An overview of the GitHub workflow used by the Kubernetes project. It includes
some tips and suggestions on things such as keeping your local environment in
sync with upstream and commit hygiene.
This document is an overview of the GitHub workflow used by the
Kubernetes project. It includes tips and suggestions on keeping your
local environment in sync with upstream and how to maintain good
commit hygiene.
---
![Git workflow](git_workflow.png)
### 1 Fork in the cloud
## 1. Fork in the cloud
1. Visit https://github.com/kubernetes/kubernetes
2. Click `Fork` button (top right) to establish a cloud-based fork.
### 2 Clone fork to local storage
## 2. Clone fork to local storage
Per Go's [workspace instructions][go-workspace], place Kubernetes' code on your
`GOPATH` using the following cloning procedure.
[go-workspace]: https://golang.org/doc/code.html#Workspaces
Define a local working directory:
In your shell, define a local working directory as `working_dir`. If your `GOPATH` has multiple paths, pick
just one and use it instead of `$GOPATH`. You must follow exactly this pattern,
neither `$GOPATH/src/github.com/${your github profile name}/`
nor any other pattern will work.
```sh
# If your GOPATH has multiple paths, pick
# just one and use it instead of $GOPATH here.
# You must follow exactly this pattern,
# neither `$GOPATH/src/github.com/${your github profile name/`
# nor any other pattern will work.
export working_dir="$(go env GOPATH)/src/k8s.io"
```
> If you already do Go development on github, the `k8s.io` directory
> will be a sibling to your existing `github.com` directory.
If you already do Go development on github, the `k8s.io` directory
will be a sibling to your existing `github.com` directory.
Set `user` to match your github profile name:
```sh
export user={your github profile name}
export user=<your github profile name>
```
Both `$working_dir` and `$user` are mentioned in the figure above.
@ -62,71 +61,75 @@ git remote set-url --push upstream no_push
git remote -v
```
### 3 Branch
## 3. Create a Working Branch
Get your local master up to date:
Get your local master up to date. Note that depending on which repository you are working from,
the default branch may be called "main" instead of "master".
```sh
# Depending on which repository you are working from,
# the default branch may be called 'main' instead of 'master'.
cd $working_dir/kubernetes
git fetch upstream
git checkout master
git rebase upstream/master
```
Branch from it:
Create your new branch.
```sh
git checkout -b myfeature
```
Then edit code on the `myfeature` branch.
You may now edit files on the `myfeature` branch.
#### Build
### Building Kubernetes
This workflow is process-specific; for quick start build instructions for [kubernetes/kubernetes](https://git.k8s.io/kubernetes) please [see here](/contributors/devel/development.md#building-kubernetes-on-a-local-osshell-environment).
This workflow is process-specific. For quick-start build instructions for [kubernetes/kubernetes](https://git.k8s.io/kubernetes), please [see here](/contributors/devel/development.md#building-kubernetes-on-a-local-osshell-environment).
### 4 Keep your branch in sync
## 4. Keep your branch in sync
You will need to periodically fetch changes from the `upstream`
repository to keep your working branch in sync. Note that depending on which repository you are working from,
the default branch may be called 'main' instead of 'master'.
Make sure your local repository is on your working branch and run the
following commands to keep it in sync:
```sh
# Depending on which repository you are working from,
# the default branch may be called 'main' instead of 'master'.
# While on your myfeature branch
git fetch upstream
git rebase upstream/master
```
Please don't use `git pull` instead of the above `fetch` / `rebase`. `git pull`
does a merge, which leaves merge commits. These make the commit history messy
Please don't use `git pull` instead of the above `fetch` and
`rebase`. Since `git pull` executes a merge, it creates merge commits. These make the commit history messy
and violate the principle that commits ought to be individually understandable
and useful (see below). You can also consider changing your `.git/config` file via
and useful (see below).
You might also consider changing your `.git/config` file via
`git config branch.autoSetupRebase always` to change the behavior of `git pull`, or another non-merge option such as `git pull --rebase`.
### 5 Commit
## 5. Commit Your Changes
Commit your changes.
You will probably want to regularly commit your changes. It is likely that you will go back and edit,
build, and test multiple times. After a few cycles of this, you might
[amend your previous commit](https://www.w3schools.com/git/git_amend.asp).
```sh
git commit
```
Likely you go back and edit/build/test some more then `commit --amend`
in a few cycles.
### 6 Push
## 6. Push to GitHub
When ready to review (or just to establish an offsite backup of your work),
push your branch to your fork on `github.com`:
When your changes are ready for review, push your working branch to
your fork on GitHub.
```sh
git push -f ${your_remote_name} myfeature
git push -f <your_remote_name> myfeature
```
### 7 Create a pull request
## 7. Create a Pull Request
1. Visit your fork at `https://github.com/$user/kubernetes`
2. Click the `Compare & Pull Request` button next to your `myfeature` branch.
1. Visit your fork at `https://github.com/<user>/kubernetes`
2. Click the **Compare & Pull Request** button next to your `myfeature` branch.
3. Check out the pull request [process](/contributors/guide/pull-requests.md) for more details and
advice.
@ -134,7 +137,7 @@ _If you have upstream write access_, please refrain from using the GitHub UI for
creating PRs, because GitHub will create the PR branch inside the main
repository rather than inside your fork.
#### Get a code review
### Get a code review
Once your pull request has been opened it will be assigned to one or more
reviewers. Those reviewers will do a thorough code review, looking for
@ -146,7 +149,7 @@ fork.
Very small PRs are easy to review. Very large PRs are very difficult to review.
#### Squash commits
### Squash commits
After a review, prepare your PR for merging by squashing your commits.
@ -161,8 +164,7 @@ Before merging a PR, squash the following kinds of commits:
Aim to have every commit in a PR compile and pass tests independently if you can, but it's not a requirement. In particular, `merge` commits must be removed, as they will not pass tests.
To squash your commits, perform an [interactive
rebase](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History):
To squash your commits, perform an [interactive rebase](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History):
1. Check your git branch:
@ -170,7 +172,7 @@ rebase](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History):
git status
```
Output is similar to:
The output should be similar to this:
```
On branch your-contribution
@ -183,7 +185,7 @@ rebase](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History):
git rebase -i HEAD~3
```
Output is similar to:
The output should be similar to this:
```
pick 2ebe926 Original commit
@ -214,7 +216,7 @@ rebase](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History):
```
Output (after saving changes) is similar to:
The output after saving changes should look similar to this:
```
[detached HEAD 61fdded] Second unit of work
@ -231,17 +233,17 @@ rebase](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History):
git push --force
```
For mass automated fixups (e.g. automated doc formatting), use one or more
For mass automated fixups such as automated doc formatting, use one or more
commits for the changes to tooling and a final commit to apply the fixup en
masse. This makes reviews easier.
### Merging a commit
## Merging a commit
Once you've received review and approval, your commits are squashed, your PR is ready for merging.
Merging happens automatically after both a Reviewer and Approver have approved the PR. If you haven't squashed your commits, they may ask you to do so before approving a PR.
Merging happens automatically after both a Reviewer and Approver have approved the PR. If you haven't squashed your commits, they may ask you to do so before approving a PR.
### Reverting a commit
## Reverting a commit
In case you wish to revert a commit, use the following instructions.
@ -249,12 +251,8 @@ _If you have upstream write access_, please refrain from using the
`Revert` button in the GitHub UI for creating the PR, because GitHub
will create the PR branch inside the main repository rather than inside your fork.
- Create a branch and sync it with upstream.
- Create a branch and sync it with upstream. Note that depending on which repository you are working from, the default branch may be called 'main' instead of 'master'.
```sh
# Depending on which repository you are working from,
# the default branch may be called 'main' instead of 'master'.
# create a branch
git checkout -b myrevert
@ -262,25 +260,20 @@ will create the PR branch inside the main repository rather than inside your for
git fetch upstream
git rebase upstream/master
```
- If the commit you wish to revert is a:<br>
- **merge commit:**
```sh
# SHA is the hash of the merge commit you wish to revert
git revert -m 1 SHA
```
- **single commit:**
```sh
# SHA is the hash of the single commit you wish to revert
git revert SHA
```
- If the commit you wish to revert is a *merge commit*, use this command:
```sh
# SHA is the hash of the merge commit you wish to revert
git revert -m 1 <SHA>
```
If it is a *single commit*, use this command:
```sh
# SHA is the hash of the single commit you wish to revert
git revert <SHA>
```
- This will create a new commit reverting the changes. Push this new commit to your remote.
```sh
git push <your_remote_name> myrevert
```
```sh
git push ${your_remote_name} myrevert
```
- [Create a Pull Request](#7-create-a-pull-request) using this branch.
- Finally, [create a Pull Request](#7-create-a-pull-request) using this branch.

95
contributors/guide/help-wanted.md
View File

@ -2,16 +2,15 @@
title: "Help Wanted and Good First Issue Labels"
weight: 9
description: |
Provides guidance on how and when to use the help wanted and good first issue
labels. These are used to identify issues that have been specially groomed for
new contributors.
This document provides guidance on how and when to use the help wanted and
good first issue labels. These are used to identify issues that have been
specially groomed for new contributors.
---
# Overview
## Overview
We use two labels [help wanted](#help-wanted) and [good first
issue](#good-first-issue) to identify issues that have been specially groomed
for new contributors. The `good first issue` label is a subset of `help wanted`
We use two labels to identify issues that have been specifically created or selected for new contributors: [help wanted](#help-wanted) and [good first
issue](#good-first-issue). The `good first issue` label is a subset of the `help wanted`
label, indicating that members have committed to providing extra assistance for
new contributors. All `good first issue` items also have the `help wanted`
label.
@ -21,41 +20,37 @@ grow and improve our community.
## Help Wanted
Items marked with the `help wanted` label need to ensure that they are:
Items marked with the `help wanted` label need to ensure that they meet these criteria:
- **Low Barrier to Entry**
It should be tractable for new contributors. Documentation on how that type of
It should be easy for new contributors. Documentation on how that type of
change should be made should already exist.
- **Clear Task**
The task is agreed upon and does not require further discussions in the
community. Call out if that area of code is untested and requires new
fixtures.
API / CLI behavior is decided and included in the OP issue, for example: _"The
new command syntax is `svcat unbind NAME [--orphan] [--timeout 5m]`"_, with
API and CLI behavior should be decided and included in the OP issue, for example: "The
new command syntax is `svcat unbind NAME [--orphan] [--timeout 5m]`", with
expected validations called out.
- **Goldilocks priority**
Not too high that a core contributor should do it, but not too low that it
isn't useful enough for a core contributor to spend time to review it, answer
questions, help get it into a release, etc.
The priority should not be so high that a core contributor should do it, but not too low that it
isn't useful enough for a core contributor to spend time reviewing it, answering
questions, helping get it into a release, etc.
- **Up-To-Date**
Often these issues become obsolete and have already been completed, are no longer
desired, no longer make sense, or have changed priority or difficulty.
Often these issues become obsolete and have already been done, are no longer
desired, no longer make sense, have changed priority or difficulty , etc.
A good example of a Help Wanted issue description can be found here: [kubernetes/test-infra#21356 (comment)](https://github.com/kubernetes/test-infra/issues/21356#issuecomment-799972711).
Example of a Help Wanted issue description can be found here: [kubernetes/test-infra#21356 (comment)](https://github.com/kubernetes/test-infra/issues/21356#issuecomment-799972711).
Related commands:
These commands can be used with GitHub issues to manage the `help wanted` label:
- `/help` : Adds the `help wanted` label to an issue.
- `/remove-help` : Removes the `help wanted` label from an issue. If the
`good first issue` label is present, it is removed as well.
`good first issue` label is present, it is removed as well.
## Good First Issue
@ -65,89 +60,81 @@ requests and shepherd it through our processes.
**New contributors should not be left to find an approver, ping for reviews,
decipher prow commands, or identify that their build failed due to a flake.**
This makes new contributors feel welcome, valued, and assures them that they
It is important to make new contributors feel welcome and valued. We should assure them that they
will have an extra level of help with their first contribution.
After a contributor has successfully completed 1-2 `good first issue`'s, they
should be ready to move on to `help wanted` items, saving remaining `good first
issue`'s for other new contributors.
After a contributor has successfully completed one or two `good first issue` items, they
should be ready to move on to `help wanted` items.
These items need to ensure that they follow the guidelines for `help wanted`
labels (above) in addition to meeting the following criteria:
All `good first issue` items need to follow the guidelines for `help wanted`
items in addition to meeting the following criteria:
- **No Barrier to Entry**
The task is something that a new contributor can tackle without advanced
setup, or domain knowledge.
setup or domain knowledge.
- **Solution Explained**
The recommended solution is clearly described in the issue.
- **Provides Context**
If background knowledge is required, this should be explicitly mentioned and a
list of suggested readings included.
- **Gives Examples**
Link to examples of similar implementations so new contributors have a
reference guide for their changes.
- **Identifies Relevant Code**
The relevant code and tests to be changed should be linked in the issue.
- **Ready to Test**
There should be existing tests that can be modified, or existing test cases
fit to be copied. If the area of code doesn't have tests, before labeling the
issue, add a test fixture. This prep often makes a great `help wanted` task!
Example of a Good First Issue description can be found here: [kubernetes/kubernetes#68231](https://github.com/kubernetes/kubernetes/issues/68231).
A good example of a `good first issue` description can be found here: [kubernetes/kubernetes#68231](https://github.com/kubernetes/kubernetes/issues/68231).
Related commands:
These commands can be used in the GitHub issue comments to control the `good first issue` label:
- `/good-first-issue` : Adds the `good first issue` label to an issue. Also adds
the `help wanted` label, if not already present.
- `/remove-good-first-issue` : Removes the `good first issue` label from an
issue.
- `/remove-good-first-issue` : Removes the `good first issue` label from an issue.
# Suggestions
## Suggestions for Experienced Community Members
We encourage our more experienced members to help new contributors, so that the
Kubernetes community can continue to grow and maintain the kind, inclusive
community that we all enjoy today.
The following suggestions go a long way toward preventing "drive-by" PRs, and
ensure that our investment in new contributors is rewarded by them coming back
and becoming regulars.
ensure that our investment in new contributors is rewarded by returning contributors.
Provide extra assistance during reviews on `good first issue` pull requests:
- Provide extra assistance during reviews on `good first issue` pull requests.
- Answer questions and identify useful docs.
- Offer advice such as _"One way to reproduce this in a cluster is to do X and
then you can use kubectl to poke around"_, or _"Did you know that you can
use fake clients to setup and test this easier?"_.
- Offer advice such as "One way to reproduce this in a cluster is to do X and
then you can use kubectl to poke around," or "Did you know that you can
use fake clients to setup and test this easier?"
- Help new contributors learn enough about the project, setting up their
environment, running tests, and navigating this area of the code so that they
can tackle a related `help wanted` issue next time.
If you make someone feel like a part of our community, that it's safe to ask
questions, that people will let them know the rules/norms, that their
contributions are helpful and appreciated... they will stick around! 🌈
If you make someone feel like a part of our community, they will know that it is safe to ask
questions, that people will let them know the rules, and that their
contributions are helpful and appreciated. They will stick around! 🌈
- Encourage new contributors to seek help on the appropriate slack channels,
introduce them, and include them in your conversations.
- Invite them to the SIG meetings.
- Give credit to new contributors so that others get to know them, _"Hey, would
- Give credit to new contributors so that others get to know them: "Hey, would
someone help give a second LGTM on @newperson's first PR on chocolate
bunnies?"_. Mention them in the SIG channel/meeting, thank them on twitter or
bunnies?" Mention them in the SIG channel and meeting, and thank them on Twitter or
#shoutouts.
- Use all the emoji in your approve or lgtm comment. 💖 🚀
- Let them know that their `good first issue` is getting extra attention to make
the first one easier and help them find a follow-up issue.
- Suggest a related `help wanted` so that can build up experience in an area.
- People are more likely to continue contributing when they know what to expect,
what's the acceptable way to ask for people to review a PR, nudge things along
- People are more likely to continue contributing when they know what to expect.
They want to know the acceptable way to ask for people to review a PR, and how to nudge things along
when a PR is stalled. Show them how we operate by helping move their first PR
along.
- If you have time, let the contributor know that they can DM you with questions