lizhimins opened a new issue, #2107:
URL: https://github.com/apache/rocketmq-dashboard/issues/2107

   ## What we are asking for
   
   Please keep your pull requests **cohesive**: one PR should contain one 
complete, self-contained change (a feature, a bug fix, or a clearly scoped 
refactor) together with its tests. **Please do not split closely related 
changes into many tiny PRs** — for example, one PR per file, per page, per 
guard, or per single-line fix when all of them serve the same purpose.
   
   ## Why this matters
   
   Recently the maintainers had to consolidate **70+ open PRs from a single 
contributor into 4 commits** before they could be merged. All of those PRs were 
valid improvements, but because each one covered only a single file or a 
one-line concern of the same theme (e.g. one PR per page for the same antd prop 
migration, one PR per null guard of the same pattern), they created:
   
   - a large review and merge overhead for maintainers (conflict resolution, 
semantic merging, re-running full verification per batch);
   - a cluttered PR queue that makes it harder for everyone's contributions to 
get noticed;
   - history that does not read meaningfully after squash-merge.
   
   Your changes are welcome and valuable — we just need them packaged in a 
reviewable shape.
   
   ## How to structure your PRs
   
   - **Group by theme, not by file.** If you are applying the same 
fix/migration to 17 pages, that is **one PR** with 17 files, not 17 PRs.
   - **Keep the fix and its tests together** in the same PR.
   - A good PR size is typically from a few files up to a few dozen files, as 
long as they serve one purpose. Large features may be split into a small number 
of meaningful PRs (e.g. backend contract first, then UI), but each part should 
still be complete on its own.
   - Before opening a PR, rebase onto the latest `rocketmq-studio` branch and 
make sure the build and tests pass locally.
   - If you have already opened several fragmented PRs, feel free to merge 
their branches into one and let us know — we are happy to re-review the 
consolidated version.
   
   Thanks for helping keep the review queue healthy — and thanks for your 
contributions!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to