This is an automated archive made by the Lemmit Bot.

The original was posted on /r/opensource by /u/fake_slim_shady_4u on 2026-06-19 19:55:38+00:00.

I’m trying to understand an OSS interaction I recently had and whether there’s something I should be doing differently as a contributor.

For context, this is the third PR I’ve had closed on this project. I’m completely okay with PRs being closed if the approach is wrong, doesn’t fit the architecture, or doesn’t meet project standards. I also don’t use AI-generated code for my contributions — I spend time reproducing the issue, tracing the root cause, and understanding the code before proposing a fix.

This particular case confused me because it felt like a situation where the PR could have been adjusted rather than closed.

I found and reported a bug where a settings form became dirty but never valid, which kept the Save button disabled.

I:

  • Opened the issue with reproduction steps
  • Investigated the root cause
  • Shared my findings and proposed approach on the issue
  • Opened a draft PR
  • Intentionally kept it in draft because I wanted feedback before finalizing

My fix worked, but it modified a shared validation schema.

A maintainer later closed my PR and explained that there was a better approach because the schema I modified was used elsewhere in the codebase.

A few hours later, another maintainer merged a different fix. The merged fix was based on the same root-cause analysis, but instead of loosening the shared schema, it introduced a dedicated schema for that specific form.

What I’m struggling with is this:

If the diagnosis was correct and the issue was primarily where the fix lived, why close the PR instead of requesting changes?

Something as simple as:

would have been enough for me to update the PR.

Again, I’m not arguing that my implementation should have been merged. Looking back, I actually agree that the merged approach is cleaner.

What I’m trying to understand is whether this kind of workflow is normal in OSS projects:

  • Contributor identifies bug
  • Contributor shares root cause and draft implementation
  • Maintainer closes PR
  • Similar fix gets merged separately

Questions for maintainers and experienced contributors:

  1. Is this a common workflow, or would you typically request changes first?
  2. When you see a contributor is on the right track but the implementation isn’t ideal, what determines whether you coach them through revisions versus closing the PR?
  3. As a contributor, how can I get architectural feedback earlier before investing time into a fix?

I’m genuinely trying to learn how to navigate OSS projects better and avoid repeating the same mistakes.