docs: remove no-more-than-three-PRs rule from contributor guidance - #13073
Conversation
Removes the explicit numeric cap on concurrent PRs across CONTRIBUTING.md and the contributing docs pages, while keeping guidance to prioritize high-impact work and discourage batches of low-value or weakly reviewed PRs.
|
@IamCoder18 is attempting to deploy a commit to the Kilo Code Team on Vercel. A member of the Team first needs to authorize it. |
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (3 files)
Docs-only change removing the "no more than three PRs at a time" cap from contributor guidance. Verified: remaining text is grammatically coherent in all three locations, the surrounding guidance on prioritization and batch PRs is intact, and a repo-wide search confirms no other references to the removed rule remain. Changeset exemption is reasonable for internal contributor docs. Reviewed by kimi-k3 · Input: 32.2K · Output: 4.5K · Cached: 198.3K Review guidance: REVIEW.md from base branch |
|
Another reason to remove the limit is because the limit encourages unreviewable mega PRs instead of stacked, small PRs. |
|
And I'll admit I've been in near-constant violation of this rule, sometimes egregiously (like right now with 11 PRs scattered over multiple weeks): 
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
…r-rule docs: remove no-more-than-three-PRs rule from contributor guidance
2 participants
Issue
Closes #13072
Context
Removes the explicit "no more than three PRs at a time" cap introduced in #10574 across
CONTRIBUTING.mdand the contributing docs pages, while keeping the surrounding advice to prioritize high-impact work and avoid batches of low-value or weakly reviewed PRs.Kilo is an open source project where PRs regularly take 2 weeks to a month to be reviewed and merged. Maintainer @emilieschario acknowledged this directly in #12239 (comment):
A hard cap on concurrent PRs might harm the project under those conditions. Contributor @shssoichiro agreed that PRs take a while to get merged in #12447 (comment):
A rule that only counts PRs against a contributor while the project's review backlog grows does not deter low-value work, it deters contributors. Removing the numeric limit lets contributors build at "Kilo Speed" (https://kilo.ai/manifesto) instead of throttling themselves to match the maintainers' review cadence. The remaining text in each section still preserves the substantive guidance against low-signal batch PRs and weakly reviewed agent-generated work, which is the actual underlying concern.
Implementation
Three single-line edits that delete the numeric cap sentence. No restructuring, no other wording changes — the surrounding paragraphs already convey the desired behavior. Affected sections:
CONTRIBUTING.md—### Tracker Use and Automationpackages/kilo-docs/pages/contributing/development-environment.md—### Using AI and Coding Agentspackages/kilo-docs/pages/contributing/index.md—## Tracker Use and AutomationScreenshots / Video
N/A
How to Test
Manual/local verification
git diff mainon this branch and confirmed the only changes are deletion of the "no more than three PRs at a time" wording in each of the three files above.Reviewer test steps
CONTRIBUTING.mdaround the### Tracker Use and Automationsection and confirm the sentence "As a rule, open no more than three PRs at a time..." is gone, and the "Prioritize high-impact or high-priority issues first..." sentence remains.packages/kilo-docs/pages/contributing/development-environment.mdunder### Using AI and Coding Agentsand confirm "Keep concurrent PRs limited, generally no more than three at a time..." is gone.packages/kilo-docs/pages/contributing/index.mdunder## Tracker Use and Automationand confirm "As a rule, open no more than three PRs at a time..." is gone.Checklist
Get in Touch
Discord: @IamCoder18