diff --git a/documentation/content/en/articles/committers-guide/_index.adoc b/documentation/content/en/articles/committers-guide/_index.adoc
--- a/documentation/content/en/articles/committers-guide/_index.adoc
+++ b/documentation/content/en/articles/committers-guide/_index.adoc
@@ -2209,6 +2209,58 @@
 share the link with other collaborators.
 
 
+=== Landing a github pull request
+This section documents how to land a github pull request that's submitted against the FreeBSD git mirrors at github.
+While this is not an official way to submit patches at this time, sometimes good fixes come in this way and it is easiest just to bring them into a committer's tree and have them be commited from there.
+It is useful to have these steps documented for such situations.
+Similar steps can be used to pull branches from other repositories and land those.
+When pull requests from others, one should take extra care to examine all the changes to ensure they are exaclty as represented.
+
+Before you begin, make sure that your local Git repo is up to date and has the correct origins set <<keeping_current,as shown above.>>
+You'll also need to make sure you have the following origins setup:
+[source,shell]
+....
+% git remote -v
+freebsd https://git.freebsd.org/src.git (fetch)
+freebsd ssh://git@gitrepo.freebsd.org/src.git (push)
+github https://github.com/freebsd/freebsd-src (fetch)
+github https://github.com/freebsd/freebsd-src (fetch)
+....
+Often pull requests are simple: requests that contains only a single commit.
+In this case, a streamlined approach may be used, though the approach in the prior section will also work.
+Here, we create a branch, cherry pick in the change, adjust the commit message, test and push the result.
+I use the branch `staging` but it can be any name.
+This can also work when there are multiple commits without conflict, though rebasing works better when there are, as outlined below.
+Briefly, this creates a branch; cherry-picks the changes from the pull request; tests it; adjusts the commit messages; and fast forward merges it back to `main`.
+The PR number is `$PR` below.
+When adjusting the message, add `Pull Request: https://github.com/freebsd-src/pull/$PR`.
+[source,shell]
+....
+% git fetch github pull/$PR/head:staging
+% git rebase -i main staging	# to move the staging branch forward, adjust commit message here
+<do testing here, as needed>
+% git checkout main
+% git pull --ff-only		# to get the latest if time has passed
+% git checkout main
+% git merge --ff-only staging
+<test again if needed>
+% git push freebsd
+....
+
+[.procedure]
+====
+For complicated pull requests, that have mutliple commits with conflicts, follow the following outline.
+
+. checkout the pull request `git checkout github/pull/XXX`
+. create a branch to rebase `git checkout -b staging`
+. rebase that `staging` to the latest `main` with `git rebase -i main staging`
+. resolve conflicts and do whatever testing is needed
+. merge the `staging` branch into `main` as above with
+. push as above
+
+This will also work when bringing branches developed elsewhere into your tree for committing.
+====
+
 [[vcs-history]]
 == Version Control History