[dtolnay]

I think about pull requests the same way:

As a library maintainer, closing and empathetically conveying why a pull request is not a net benefit to the project is an order of magnitude more effort than what it takes to throw up not-well-motivated pull requests on someone else's project.

[worldsayshi]

I would argue that libraries have an additional problem in that there's a many to one relationship between users and maintainer. It feels like there should be a way to design the ecosystems so that the maintainer doesn't end up with so much default expectations.

I think a more generalized version of OP's concept goes into a lot of things.

I thought about this when I first played Minecraft on a multiplayer server where people had vandalized the world. Much harder to keep it tidy than making it ugly. I think they usually solved this by giving mods ability to rewind. Crude but effective.

Like, what makes Wikipedia work? It's easy to go back in the version history when somebody breaks stuff?

It looks like there should be a bunch of tricks that could be used to design these systems so that doing the right thing is easier than breaking stuff.

[throw101010]

I see pull requests on my projects from new/outside contributors as suggestions, not actual demands.

Refusing a suggestion doesn't prompt for a full explanation, it also doesn't mean it won't ever be reconsidered potentially.

People who engage in open source contributions are usually aware of this, the fact that they generally can fork and use their own "improvement" for themselves is usually enough, and the people who feel entitled to get their code merged in your repository are usually not the kind of regular contributors you want to keep around in my experience.

[gitgud]

There's also similarities with making any change to software.

It's relatively easy to merge code in, but takes much more effort and thought to remove the code later. Especially once other things are dependant on it...