Skip to content

Conversation

@softhack007
Copy link
Member

@softhack007 softhack007 commented Feb 5, 2026

  • Add clearer documentation in CONTRIBUTING.md explaining why force-pushes cause issues
  • Recommend using regular git push to add fixup commits instead of rewriting history
  • Explain that force-pushes can lose review comments and disrupt bot reviews
  • Highlight alternatives to force-push
  • Some re-styling and minor editorials to improve readability and friendly tone

based on AI proposals in #5348

Summary by CodeRabbit

  • Documentation
    • Reworked CONTRIBUTING into a step-by-step contributor workflow with a new Getting Started flow.
    • Clarified target branch guidance, renamed PR description guidance, and added concise PR-writing tips.
    • Added Testing Your Changes, pre-submission checks, During Review, Responding to Reviews, and After Approval guidance.
    • New Dealing with Merge Conflicts section with GUI/CLI examples and cherry-pick notes.
    • Updated branch-update/force-push guidance and bot-impact warnings.
    • Added Coding Guidelines, AI best practices, and refreshed style and formatting.

based on AI proposals in #5348
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 5, 2026

Walkthrough

CONTRIBUTING.md is substantially reorganized: PR guidance renamed and restructured with a new Getting Started section; added a Testing Your Changes checklist; expanded PR description, pre-submission checks, and update practices (ongoing commits allowed; squashing not required); added During Review, Responding to Reviews, Dealing with Merge Conflicts (GUI/CLI and cherry-pick examples), Additional Resources, After Approval, and AI-related/code-style guidance. (+147 / -46 lines)

Changes

Cohort / File(s) Summary
Documentation
CONTRIBUTING.md
Comprehensive rewrite of contribution workflow: introduces Getting Started; reorders and expands sections for PR descriptions, testing, pre-submission checks, and Updating Your Code (permits ongoing commits; clarifies force-push implications and bot interactions); adds During Review, Responding to Reviews, Dealing with Merge Conflicts (GUI and CLI flows, cherry-pick guidance), After Approval, Additional Resources, and dedicated AI-related and coding-guideline subsections; multiple stylistic and formatting edits.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly summarizes the main change: improving contributor guidelines with a focus on force-push practices and overall documentation clarity.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch push_back_force_p1

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In `@CONTRIBUTING.md`:
- Line 51: Update the capitalization of the platform name in CONTRIBUTING.md by
changing the lowercase word "github" to the correct "GitHub" where it appears in
the sentence "It has many subtle and unexpected consequences on our github
repository." so the official branding is used.
🧹 Nitpick comments (3)
CONTRIBUTING.md (3)

54-54: Remove blank line inside blockquote.

Markdown style guidelines recommend avoiding blank lines within blockquote blocks for consistency.

📝 Proposed fix
 > So, pretty please, do not force-push.
-
 > [!TIP]

69-71: Specify language for code fence.

Markdown linters recommend specifying a language identifier for fenced code blocks to improve rendering and accessibility.

📝 Proposed fix
-> ```
+> ```text
 > Fix naming per `@Aircoookie`'s suggestion
 > ```

121-121: Consider a more descriptive section heading.

The lowercase "more" heading is less formal than other section titles. Consider using a more descriptive title like "Additional Resources" for consistency.

📝 Proposed alternative
-### more
+### Additional Resources
 You can find a collection of very useful tips and tricks here: https://github.com/wled-dev/WLED/wiki/How-to-properly-submit-a-PR

official style is "GitHub"

Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Fix all issues with AI agents
In `@CONTRIBUTING.md`:
- Around line 63-66: Update the review guidance bullet items to use a more
polite tone by inserting "please" where appropriate; specifically edit the lines
"**Add new commits** - don't amend or force-push", "**Reply in the PR** - let us
know when you've addressed comments", "**Ask questions** - if something's
unclear, just ask!" and "**Be patient** - we're all volunteers here 😊" to
include "please" (e.g., "**Please add new commits** - don't amend or
force-push", "**Please reply in the PR** - let us know when you've addressed
comments", etc.), keeping the original meaning and punctuation consistent.
- Around line 68-71: The fenced code block containing the example commit message
"Fix naming per `@Aircoookie`'s suggestion" is missing a language identifier and
triggers markdownlint; update that fenced block in CONTRIBUTING.md by adding a
language token (for example `text`) after the opening backticks so the block
becomes ```text ... ``` to satisfy the linter.

Copy link
Collaborator

@DedeHai DedeHai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Fix all issues with AI agents
In `@CONTRIBUTING.md`:
- Line 120: Update the header string "### Additional Ressources" to use the
correct spelling "### Additional Resources" so the CONTRIBUTING.md heading reads
properly; locate the header line and replace "Ressources" with "Resources".
- Line 53: Remove the stray blank line inside the blockquote by deleting the
empty line that begins with ">" (the blank line within the quoted section) so
the blockquote lines are contiguous; simply ensure every quoted paragraph in the
blockquote starts with ">" with no intervening empty ">" line to satisfy
markdownlint.
🧹 Nitpick comments (1)
CONTRIBUTING.md (1)

62-65: Consider adding "please" for tone consistency.

Line 62 uses "please" but lines 63-65 don't, creating slight inconsistency. Adding "please" to the other bullet points would create a more uniformly polite tone throughout the guidance.

✏️ Suggested refinement
 - **Add new commits** - please don't amend or force-push
-- **Reply in the PR** - let us know when you've addressed comments
-- **Ask questions** - if something's unclear, just ask!
-- **Be patient** - we're all volunteers here 😊
+- **Reply in the PR** - please let us know when you've addressed comments
+- **Ask questions** - please ask if something's unclear!
+- **Be patient** - please remember we're all volunteers here 😊

addressing minor recommendations by the rabbit
@softhack007
Copy link
Member Author

@coderabbitai as we are already updating the contributor's guide: please review the complete file, and summarize your recommendations also for unchanged parts of CONTRIBUTING.md.

Our objective is to provide a guide that is clear and easy to follow, addresses the most important points, while being written in an inviting and casual tone.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 5, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

@softhack007, I'll review the complete CONTRIBUTING.md file and provide comprehensive recommendations for you.


🏁 Script executed:

#!/bin/bash
# Read the complete CONTRIBUTING.md file
cat CONTRIBUTING.md

Length of output: 8257


@softhack007, I've reviewed the complete CONTRIBUTING.md file. Here's my comprehensive analysis organized by section:

✅ Strengths (What's Working Well)

New sections are excellent:

  • ✅ "Testing Your Changes" - clear checklist format, very practical
  • ✅ "Responding to Reviews" - friendly tone with good examples
  • ✅ "Dealing with Merge Conflicts" - dual approach (GUI + CLI) is beginner-friendly
  • ✅ Force-push warning - now prominent with concrete reasons

Good existing content:

  • ✅ Opening "thank you" sets inviting tone
  • ✅ Fork/branch guidance is clear
  • ✅ Code style examples are visual and practical

📝 Recommendations for Improvement

1. Title & Introduction

Current: "Thank you for making WLED better!"

Suggestion: Add a brief sentence about what WLED is for newcomers:

# Thank you for making WLED better!

WLED is a community-driven project, and we appreciate every contribution! Here are a few suggestions to make it easier for you to contribute.

2. "Describing your PR" Section

Current: Good content but feels slightly formal in places.

Suggestions:

  • Change "It does not need to be an exhaustive essay" → "No need to write an essay!"
  • The bullet points are great but could use a friendlier intro:
    A good description helps us understand what you're trying to do. For example:
    * **What's the goal?** (new feature, bug fix, refactoring, etc.)
    * **How does it work?** (quick technical overview - focus on the non-obvious bits)
    * **What did you test?** Known limitations? Anything you couldn't quite solve?
    * **Need help?** Let us know if you'd like guidance from a maintainer (WLED is a big project 😉)

3. "Additional Resources" Section

Current: Single link, feels tacked on.

Suggestions:

  • Expand slightly or integrate earlier:
    ### Additional Resources
    
    New to Git or GitHub? Check out:
    - 🎓 [How to properly submit a PR](https://github.com/wled-dev/WLED/wiki/How-to-properly-submit-a-PR) - detailed tips and tricks
    - 📚 [GitHub Desktop documentation](https://docs.github.com/en/desktop) - if you prefer GUI tools

4. "Source Code from an AI agent or bot" Section

Current: Good warnings but slightly wordy and repetitive.

Suggestions for streamlining:

## Using AI-Generated Code

> [!IMPORTANT]
> AI tools can be helpful, but as the contributor, **you're responsible for the code**.

Here's what we expect:

✅ **Understand it** - Don't just copy-paste because it "seems to work"  
✅ **Review carefully** - AI can lose comments, introduce bugs, or make unnecessary changes  
✅ **Be transparent** - Add a comment like `// This section was AI-generated` for larger chunks  
✅ **Use AI for translation** - AI is great for translating comments to English (but verify technical terms!)

Remember: AI tools are powerful but "often wrong" - your judgment is essential! 😊

5. Code Style Section

Current: Clear with good examples, but could be more inviting.

Suggestions:

  • Add a friendlier intro:

    ## Code Style
    
    Don't stress too much about style! When in doubt, just match the style in the files you're editing. 😊
    
    Here are our main guidelines:
  • In the "Acceptable" example, tone is slightly negative. Consider:

    Also fine (though the first style is usually easier to read):

6. Comments Subsection

Issue: States "This is a recent change, the majority of the codebase still has comments without spaces."

Suggestion: This might confuse contributors. Either:

  • Remove this note (it's internal context)
  • OR rephrase: "We're gradually adopting this style - don't worry if you see older code without spaces!"

7. Structure & Flow

Current order works well, but consider these minor adjustments:

  1. Move "Additional Resources" higher (after "PR from a branch" or after "Describing your PR")
  2. Consider grouping related sections:
    • Getting Started: Fork, Branch, Describe PR, Testing
    • During Review: Updating code, Responding to reviews, Merge conflicts
    • Code Guidelines: AI code, Code style

8. Missing Content (Optional Additions)

Consider adding brief sections on:

  • When will my PR be reviewed? - Set expectations about review times

    ### Review Timeline
    We're all volunteers, so reviews can take a few days (or longer during busy times). Don't worry - we haven't forgotten you! Feel free to ping after a week if there's no activity.
  • What happens after approval? - Explain merging process

    ### After Approval
    Once approved, a maintainer will merge your PR (usually squashing commits). Your contribution will be in the next release - thank you! 🎉

9. Consistency & Tone

Minor inconsistencies to address:

  • Mix of "you" and "we" - consider standardizing (currently it's mostly good)
  • Some emoji usage 😊😉🎉 vs none - consider adding a few more for consistency in the inviting tone
  • "pretty please" in force-push section is great! More of this casual tone would be nice

10. Typos & Grammar

Found one minor issue:

  • "Its OK" → "It's OK" (in AI section)

🎯 Priority Recommendations

If you want to make quick improvements with high impact:

  1. High Priority: Simplify and reorganize the AI-generated code section (it's a bit wordy)
  2. High Priority: Fix "Its" → "It's" typo
  3. Medium Priority: Make "Describing your PR" section more casual/friendly
  4. Medium Priority: Remove or rephrase the "recent change" note in Comments section
  5. Low Priority: Consider adding "Review Timeline" expectations

Overall Assessment

The file is very good overall! The new sections (Testing, Responding to Reviews, Merge Conflicts) are excellent additions. The force-push guidance is now much clearer. Main areas for improvement are:

  • Slight tone inconsistencies (some sections are more formal than others)
  • AI section could be more concise
  • A few minor opportunities to be more inviting/casual

The file successfully balances being informative with being approachable, which is exactly what you're aiming for! 🎉

Would you like me to generate a complete rewrite with these suggestions incorporated, or would you prefer to cherry-pick specific improvements?

@softhack007
Copy link
Member Author

Current: "Thank you for making WLED better!"
Suggestion: Add a brief sentence about what WLED is for newcomers:

# Thank you for making WLED better!

WLED is a community-driven project, and we appreciate every contribution! Here are a few suggestions to make it easier for you to contribute.

@coderabbitai I need some writing help. I think the intro should also mention why maintainers review contributions at all.
In my own words: "we appreciate contributions, but we don't want unmaintainable balls of hack, or features that are adding bloat without adding value. Maintainers are there to help you improve your contribution, but we are also guardians of a maintainable and efficient architecture."

Please find a wording to express this, while matching the overall style and tone of the guide.
Where would this statement fit best?

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 5, 2026

Tip

For best results, initiate chat on the files or code changes.

@softhack007, great point! Setting these expectations early helps everyone. Here are a few options that express your intent while keeping the friendly, casual tone:

Option 1: Direct & Friendly

# Thank you for making WLED better!

WLED is a community-driven project, and we appreciate every contribution! We're here to help you improve your code and make it shine. ✨

Our maintainers review contributions to keep WLED efficient, maintainable, and focused. We're not just gatekeepers - we're collaborators who want your feature to succeed! We'll help refine your code, suggest improvements, and sometimes push back on changes that might add bloat or create maintenance headaches down the road. Think of us as guardians of WLED's architecture, working with you to make your contribution the best it can be.

Here are a few suggestions to make it easier for you to contribute:

Option 2: More Concise & Casual

# Thank you for making WLED better!

WLED is a community-driven project, and we love contributions! 🎉

Our maintainers are here for two things: **helping you** improve your code, and **keeping WLED** lean, efficient, and maintainable. We'll work with you to refine your contribution, but we'll also push back if something might create technical debt or add features without clear value. Don't take it personally - we're just protecting WLED's architecture while helping your contribution succeed!

Here are a few suggestions to make it easier for you to contribute:

Option 3: Balanced & Welcoming

# Thank you for making WLED better!

WLED is a community-driven project, and every contribution matters! We appreciate your time and effort.

**What maintainers do:** We're here to collaborate with you! We'll help improve your code, suggest better approaches, and ensure everything fits WLED's architecture. We're also guardians - we'll respectfully decline changes that might bloat the codebase or create maintenance issues. Our goal isn't to be picky; it's to keep WLED efficient and sustainable for everyone. 😊

Here are a few suggestions to make it easier for you to contribute:

📍 Best Placement

I recommend putting this right at the top, as the introduction (replacing or expanding the current simple thank-you). This way:

  • Contributors know what to expect before investing time
  • Sets a collaborative tone from the start
  • Frames maintainer feedback as helpful rather than critical

Alternatively, you could add a separate "What to Expect from Reviews" section after "Describing your PR" and before "Testing Your Changes", but I think the intro placement is stronger - it sets the right expectations immediately.

My Preference

Option 2 feels the most natural and matches your existing casual tone ("pretty please", emojis). It's honest without being discouraging, and the "Don't take it personally" bit preemptively addresses potential friction.

What do you think? Want me to adjust any of these? 😊

* extended opening section
* section groups: Getting Started, During Review, After Approval, Coding Guidelines
* removed duplications in AI section
* improve friendly style
* minor corrections
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 5

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
CONTRIBUTING.md (1)

201-205: ⚠️ Potential issue | 🟡 Minor

Grammar cleanup in spacing rules.

Multiple small fixes in the same rule block.

✏️ Proposed fix
-Within the condition, no space should be between the parenthesis and variables.  
-Spaces between variables and operators are up to the authors discretion.
-There should be no space between function names and their argument parenthesis.
+Within the condition, no space should be between the parentheses and variables.  
+Spaces between variables and operators are up to the author's discretion.
+There should be no space between function names and their argument parentheses.
🤖 Fix all issues with AI agents
In `@CONTRIBUTING.md`:
- Line 155: The sentence in CONTRIBUTING.md has a subject-verb agreement error:
change the phrase "the results is correct" (or "if the results is correct") to
use the plural verb "are" so it reads "the results are correct" (i.e., update
"check if the results is correct" to "check if the results are correct").
- Line 152: Replace the unhyphenated phrase "AI generated code" with the
hyphenated compound adjective "AI-generated code" in the CONTRIBUTING.md content
(look for the exact string "AI generated code") to correct the grammar.
- Line 174: The sentence "We use tabs for Indentation in Web files
(.html/.css/.js) and spaces (2 per indentation level) for all other files." uses
an uppercase "Indentation" in running text; change "Indentation" to lowercase
"indentation" so the sentence reads "We use tabs for indentation in Web files
(.html/.css/.js) and spaces (2 per indentation level) for all other files." in
CONTRIBUTING.md.
- Line 19: Update the sentence "When you chose to 'Commit changes', GitHub will
automatically create a PR from your fork." by correcting the typo: replace
"chose" with "choose" so it reads "When you choose to 'Commit changes', GitHub
will automatically create a PR from your fork."; ensure only that single word is
changed and punctuation/quoting remains unchanged.
- Line 64: The sentence in CONTRIBUTING.md uses past tense ("regularly lost")
but should be present tense; edit the sentence "For example, we regularly lost
review comments when the PR author force-pushes code changes. Our review bot
(coderabbit) may become unable to properly track changes, it gets confused or
stops responding to questions." to replace "regularly lost" with "regularly
lose" so it reads "For example, we regularly lose review comments when the PR
author force-pushes code changes..." ensuring tense agreement across the
sentence.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Fix all issues with AI agents
In `@CONTRIBUTING.md`:
- Around line 67-68: Change the TIP sentence so it starts with a capital letter:
locate the markdown TIP block that begins with "[!TIP]" containing the sentence
"use [cherry-picking](...)" and update the word "use" to "Use" to match
capitalization consistency with other headings and sentences.
- Around line 154-162: Edit the sentences in the CONTRIBUTING.md section to fix
grammar and hyphenation: change “AI are still "Often-Wrong" ;-)” to use singular
verb and normal capitalization (e.g., “AI is still often wrong.”) and hyphenate
“AI generated” to “AI-generated” wherever it appears (for example in the header
“Best Practice with AI” and the bullet “Understand the code”/“Review carefully”
lines) so the text reads grammatically correct and consistently styled.

@softhack007
Copy link
Member Author

OK, I'm happy with the result now.
👓 RFC! (request-for-comments) 👀

softhack007 and others added 2 commits February 6, 2026 00:37
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In `@CONTRIBUTING.md`:
- Around line 17-19: The blockquote lines starting with ">   " have multiple
spaces after the ">" which triggers markdownlint MD027; update the tip
blockquote by replacing each leading ">   " with a single "> " so the three
lines ("**The easiest way to start your first PR**", "When viewing a file in
`wled/WLED`, click on the "pen" icon and start making changes.", "When you
choose to 'Commit changes', GitHub will automatically create a PR from your
fork.") use "> " (one space) after the ">" to satisfy MD027.

Copy link
Member

@netmindz netmindz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for sorting that. Some good improvement in there

@softhack007 softhack007 merged commit 8b6d413 into main Feb 7, 2026
51 checks passed
@softhack007 softhack007 deleted the push_back_force_p1 branch February 7, 2026 15:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants