diff --git a/docs/source/contributor-guide/index.md b/docs/source/contributor-guide/index.md
index dbbcd58730249..5bb4e26b9525b 100644
--- a/docs/source/contributor-guide/index.md
+++ b/docs/source/contributor-guide/index.md
@@ -41,11 +41,29 @@ DataFusion is a very active fast-moving project and we try to review and merge P
 
 Review bandwidth is currently our most limited resource, and we highly encourage reviews by the broader community. If you are waiting for your PR to be reviewed, consider helping review other PRs that are waiting. Such review both helps the reviewer to learn the codebase and become more expert, as well as helps identify issues in the PR (such as lack of test coverage), that can be addressed and make future reviews faster and more efficient.
 
-Things to help look for in a PR:
+## Creating Pull Requests
+
+We recommend splitting your contributions into smaller PRs rather than large PRs (500+ lines) because:
+
+1. The PR is more likely to be reviewed quickly -- our reviewers struggle to find the contiguous time needed to review large PRs.
+2. The PR discussions tend to be more focused and less likely to get lost among several different threads.
+3. It is often easier to accept and act on feedback when it comes early on in a small change, before a particular approach has been polished too much.
+
+If you are concerned that a larger design will be lost in a string of small PRs, creating a large draft PR that shows how they all work together can help.
+
+# Reviewing Pull Requests
+
+When reviewing PRs, please remember our primary goal is to improve DataFusion and its community together. PR feedback should be constructive with the aim to help improve the code as well as the understanding of the contributor.
+
+Please ensure any issues you raise contains a rationale and suggested alternative -- it is frustrating to be told "don't do it this way" without any clear reason or alternate provided.
+
+Some things to specifically check:
 
 1. Is the feature or fix covered sufficiently with tests (see `Test Organization` below)?
 2. Is the code clear, and fits the style of the existing codebase?
 
+## "Major" and "Minor" PRs
+
 Since we are a worldwide community, we have contributors in many timezones who review and comment. To ensure anyone who wishes has an opportunity to review a PR, our committers try to ensure that at least 24 hours passes between when a "major" PR is approved and when it is merged.
 
 A "major" PR means there is a substantial change in design or a change in the API. Committers apply their best judgment to determine what constitutes a substantial change. A "minor" PR might be merged without a 24 hour delay, again subject to the judgment of the committer. Examples of potential "minor" PRs are:
@@ -55,6 +73,8 @@ A "major" PR means there is a substantial change in design or a change in the AP
 3. Non-controversial build-related changes (clippy, version upgrades etc.)
 4. Smaller non-controversial feature additions
 
+The good thing about open code and open development is that any issues in one change can almost always be fixed with a follow on PR.
+
 ## Getting Started
 
 This section describes how you can get started at developing DataFusion.