diff --git a/README.md b/README.md
index 953ddf9..4e3a3b1 100644
--- a/README.md
+++ b/README.md
@@ -15,25 +15,29 @@ core developer.
 1. Only proposals that properly fill out the template will be considered. If
 the template is not filled out or is filled out improperly, it will be closed.
 
-2. All proposals must be linked to a substantive use-case. In justifying your
+2. Please open one proposal per feature requested. Do not cram multiple feature
+requests in a single proposal, as this makes it harder to discuss features
+individually.
+
+3. All proposals must be linked to a substantive use-case. In justifying your
 proposal, it is not enough to say it would be "nice" or "helpful". Use the
 template to show how Godot is not currently meeting your needs and then
 explain how your proposal will meet a particular need.
 
-3. Other users must express interest in your proposal for it to be considered.
+4. Other users must express interest in your proposal for it to be considered.
 Godot is community-driven: if no other users are interested in your proposal,
 it may be closed. It is up to you to draw interest in your proposed feature.
 Start by reaching out on the community channels (Reddit, Discord, IRC, etc.
 see the [Community Channels](http://docs.godotengine.org/en/stable/community/channels.html) doc),
 then create your proposal once you have gained some interest.
 
-4. You can make a PR implementing the feature in the main repository before
+5. You can make a PR implementing the feature in the main repository before
 making a proposal. However, if it is a large change, a core developer may
 require that you make a proposal before your PR can be merged. It is always
 better to make and discuss a proposal before spending your time implementing
 a new feature.
 
-5. If you or another user is capable of making a PR, include that fact in
+6. If you or another user is capable of making a PR, include that fact in
 the issue or in a subsequent comment so that a core contributor can
 fast-track the approval process.