diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -42,7 +42,7 @@
 * All commits have, as the author, your name and valid email address as you would like to see them in the FreeBSD repository. Fake github.com addresses cannot be used.
 * The scope of the pull request should not change during review. If the review suggests changes that expand the scope, please create an independent pull request.
 * Fixup commits should be squashed with the commit they are fixing. Each commit in your branch should be suitable for FreeBSD's repository.
-* Commits should include one or more `Signed-off-by:` lines with full name and email address certifying [Developer Certificate of Origin](https://developercertificate.org/).
+* Commits should include one or more `Signed-off-by:` lines with name and email address certifying [Developer Certificate of Origin](https://developercertificate.org/). But see [Author Name and Email][#author-name-and-email] for details.
 * The commits follow FreeBSD's style guide. See [Style](#Style).
 * Run tools/build/checkstyle9.pl on your Git branch and eliminate all errors, or provide an explanation for exceptions.
 * The commits do not introduce trailing white space.
@@ -53,29 +53,31 @@
 * Submissions using generative AI will be rejected.
 * Submissions from AI chatbots will result in the account being banned.
 
-When updating your pull request, please rebase with a forced push rather than a
-merge commit.
+When revising your pull request after feedback, please rebase with a forced push
+rather than a merge commit.
 
 More complex changes may be submitted as pull requests, but they may be closed
 if they are too large, too unwieldy, become inactive, need further discussion in
-the community, or need extensive revision.  Please avoid creating large,
-wide-ranging cleanup patches: they are too large and lack the focus needed for a
-good review.  Misdirected patches may be redirected to a more appropriate forum
-for the patch to be resolved.
+the community, or need extensive revision.
+
+Please avoid creating large, wide-ranging cleanup patches: they often lack the
+focus needed for a good review and can be hard to test.  Misdirected patches may
+be redirected to a more appropriate forum for the patch to be resolved.
 
 Please make sure that your submissions compile and work before submitting. If
-you need feedback, a pull request might not be the right place (it may just be
-summarily closed if there are too many obvious mistakes).
+you need feedback, a pull request might not be the right place. A pull request
+may be closed if there are too many obvious mistakes, or when a time-consuming
+rework is needed.
 
 If you want to cleanup style or older coding conventions in preparation for some
-other commit, please go ahead and prepare those patches. However, please avoid just
-cleaning up to make it cleaner, unless there's a clear advantage to doing
+other commit, please go ahead and prepare those patches. However, please avoid
+just cleaning up to make it cleaner, unless there's a clear advantage to doing
 so. While the project strives to have a uniform coding style, our style offers a
 range of choices making some 'cleanups' ambiguous at best. Also, some files have
-their own consistent style that deviates from style(9). Style changes take
-volunteer time to process, but that time can be quite limited, so please be
-respectful. Trivial spelling changes should generally not be made in isolation
-as they usually add little value, but do take up valuable volunteer time.
+their own consistent style that deviates from style(9). Style changes take time
+to process, but our volunteers have limited time, so please be respectful of
+their time. Trivial spelling changes take this valuable time, but rerturn little
+benefit relative to other changes.
 
 The current theory for pull requests on GitHub is to facilitate inclusion in the
 project. The guidelines are streamlined for quick decisions about each pull
@@ -92,11 +94,13 @@
 
 ### Author Name and Email
 
-We require that contributions are associated with a unique identity.
-The author email address should not be `<something>@users.noreply.github.com`.
-Do note that your name and email address will become a permanent and immutable
-part of the public Git history of the FreeBSD source tree. Authors that use
-pseudonyms will be considered on a case by case basis.
+We require that contributions are associated with a unique identity.  The author
+email address should not be `<something>@users.noreply.github.com`.  Do note
+that your name and email address will become a permanent and immutable part of
+the public Git history of the FreeBSD source tree. Authors may use pseudonyms
+for smaller changes, but the project requires that authors of significant
+changes use their full name, or that they make arrangements with the Core
+Team (core@FreeBSD.org).
 
 ## Style