Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Suggestion: strengthen contributor-first PR workflow and credit practices [1 pull requests, 3 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#60108•Fetched 2026-04-08 02:36:10
View on GitHub
Comments
3
Participants
3
Timeline
37
Reactions
2
Author
xinbenlvxinbenlv
Participants
jerronljerronlvincentkocvincentkocxinbenlvxinbenlv
Timeline (top)
mentioned ×15subscribed ×14commented ×3referenced ×2

Root Cause

I wanted to raise something I've been observing that I think could help us grow a healthier contributor ecosystem. I'm bringing this up constructively because I believe it's an easy win for the project.

Fix Action

Fixed

PR fix notes

PR #60117: docs(contributing): add contributor credit and deduplication guidelines

Description (problem / solution / changelog)

Summary

Add two new sections to CONTRIBUTING.md under "Before You PR":

  1. Check for Existing Work (for contributors): Search for existing issues/PRs before opening new ones. If your PR builds on or duplicates prior work, acknowledge it with links and Co-authored-by tags.

  2. For Maintainers: Credit and Contributor-First Practices: Prefer iterating on the first contributor's PR when feasible. When superseding is necessary, credit all original authors in merge commits using the (thanks @handle) convention already established by @steipete.

Why

Growing a healthy contributor pool requires that contributors feel their work is valued, even when their PR isn't the one that gets merged. These lightweight guidelines formalize practices that are already partially in use (see @steipete's (thanks @handle) commit convention) and make them consistent across all maintainers.

See discussion in #60108 for detailed examples and motivation.

Changes

  • CONTRIBUTING.md: +26 lines, two new subsections

Verification

  • No code changes; docs only
  • Reviewed against existing CONTRIBUTING.md structure and tone

Related #60108

Changed files

  • AGENTS.md (modified, +2/-0)
  • CONTRIBUTING.md (modified, +26/-0)
RAW_BUFFERClick to expand / collapse

Hey @vincentkoc 👋

First off — thank you for the incredible amount of work you put into maintaining OpenClaw. The velocity and quality of your contributions are genuinely impressive, and the project clearly benefits from your deep knowledge of the codebase.

I wanted to raise something I've been observing that I think could help us grow a healthier contributor ecosystem. I'm bringing this up constructively because I believe it's an easy win for the project.

Positive example from the project founder

Before diving into the concern, I want to highlight that @steipete already models the exact behavior we'd like to see consistently. In steipete/gogcli #421, @peteradams2026 submitted a PR. @steipete closed it and landed the fix himself, but left a detailed closing comment that:

  1. Explained why he landed it directly (GitHub UI conflict state bug)
  2. Listed the gate checks he ran
  3. Included the commit SHA for traceability
  4. Ended with "Thanks @peteradams2026!"
  5. The merge commit message itself: fix(auth): preserve extra scopes replay and satisfy lint on current main (#421) (thanks @peteradams2026)

The same (thanks @handle) convention already appears in many commits on openclaw/openclaw main. The culture is already there — it just needs to be applied consistently when superseding PRs too.

What I've noticed

There's a recurring pattern where an external contributor opens a PR, and it's later closed as "superseded by" a new PR — often authored by a maintainer — without carrying forward credit to the original contributor. Here are 5 examples:

#Original PRAuthorClosing CommentSuperseding PRAuthorMerge CommitCredit?
1#46686 — Slack Block Kit streaming fix@jeremykoerber"Superseded by #57473"#57473@vincentkoc12ae4ee❌ None
2#58811 — Status truncation fix@huohua-dev"Superseded by #58810"#58810@vincentkoc340c99d❌ None
3#58745 — Exec-approvals allowlist fix@w-sss"Superseded by #58792"#58792@vincentkoc2d53ffd❌ None
4#55348 — Discord health-monitor fix@jerronl"Closing in favor of #55991"#55991@vincentkoc02e3061❌ None
5#53225 — Anthropic cache prefix fix@coletebou"Superseded by #59054"#59054@vincentkoc(still open)❌ None

I understand there are often legitimate reasons to rewrite — the original PR may have drifted from main, the scope may need adjusting, or the fix may need to be combined with other changes. That's totally normal in a fast-moving project.

The concern is about what this looks like from the contributor's perspective: they invested time understanding the codebase, wrote a fix, submitted it in good faith — and then saw it closed and replaced without acknowledgment. For many contributors, especially first-timers, that experience is enough to not come back.

Suggestions

1. Prefer guiding the original contributor when feasible. If a PR is directionally correct, consider leaving review comments and giving the author a chance to iterate, rather than rewriting it from scratch. The "teach someone to fish" approach scales better for the project long-term.

2. When superseding is genuinely necessary, credit the original work:

  • Add Co-authored-by: Original Author <email> to the commit message (this shows up in GitHub's contributor graph)
  • Mention "Based on the approach in #XXXX by @author" in the PR description
  • Follow the (thanks @handle) convention already established by @steipete

3. A brief "why superseding" explanation when closing a PR in favor of another helps the contributor learn and doesn't leave them guessing.

Why this matters for OpenClaw

OpenClaw is at an exciting stage of growth. Projects like Node.js, Kubernetes, and Rust have all invested heavily in contributor-first practices precisely because they learned that a growing contributor pool is the lifeblood of sustainability.

Credit is free to give but incredibly meaningful to receive. Small gestures — a co-author tag, a mention, an "inspired by" — compound into a reputation that makes people want to contribute here.

Happy to discuss further or help draft a lightweight contributor guide if that would be useful. 🙏

cc @steipete

extent analysis

TL;DR

To improve the contributor experience in OpenClaw, maintainers should consistently credit original authors when superseding their pull requests, either by guiding them to improve their work or by acknowledging their contribution in the new pull request.

Guidance

  • When a pull request is directionally correct, consider leaving review comments to guide the original author instead of rewriting it from scratch.
  • When superseding a pull request is necessary, add a Co-authored-by tag to the commit message, mention the original approach in the new pull request description, and follow the (thanks @handle) convention.
  • Provide a brief explanation for why a pull request is being superseded to help the contributor understand and learn from the decision.
  • Establish a consistent practice of acknowledging contributors' work to foster a positive and inclusive community.

Example

A commit message that credits the original author could look like this:

fix: improve Slack Block Kit streaming
Co-authored-by: jeremykoerber <[email protected]>
(thanks @jeremykoerber)

Notes

This approach focuses on improving the contributor experience and does not require significant changes to the project's workflow or infrastructure.

Recommendation

Apply the suggested workaround by consistently crediting original authors when superseding their pull requests, as this promotes a positive and inclusive community that encourages contributors to participate and grow with the project.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#autograd error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING