Hacker News Reader

Comment by emmaviolet | Hacker News Reader

GitHub PM here working on how we can make this problem feel better for maintainers. Really appreciate how tiring this can be, especially when even low volume is sustained for many months.

Would love your thoughts on some of the things we're thinking about: - Would it help to disable all PRs? All non-contributor PRs? - Would a "close as admin" button help address the issue of not wanting to be rude or discouraging? - What about Copilot doing an initial review and proposing to close anything that doesn't meet contribution guidelines - would that help a "close this" decision feel less personal?

View on HN

My ideal is copilot that would evaluate the PR against some basic guidelines that maintainers write down.

And perhaps a way to filter PRs to just contributor PRs would be easy to implement and pretty useful

Another GitHub PM here. Thanks for the feedback! We're currently working on adding a way restrict PR creation to collaborations only. We've also heard some feedback around evaluating PRs against contributing guidelines which would allow maintainers to clearly define criteria that PRs must meet, so we're exploring that option as well.

Good questions, thanks. I'll share this thread with other maintainers. Is this the best place for feedback in a week or two? Or is there a GitHub meta discussion somewhere?

We just posted a discussion on this topic and some solutions we're exploring: https://github.com/orgs/community/discussions/185387

Feel free to drop any feedback or questions in the post.

As someone on the other side of the PR, the current situation makes things awkward for me, too. Occasionally, I'll make an actual fix to scratch some particular itch I have with the software, and I'm hesitant to even open a PR, because it's just going to 1. pile yet another PR onto the maintainer, and 2. might get dismissed out of hand because it's mistaken for AI slop or other low-effort spam that these attackers are doing. So, I usually just fork, make the change in my own repo, and leave it at that.

Disabling PRs or limiting PRs to "contributors" would be a signal to me that I should just keep doing that and not contribute back to the main repo.

Yeah, I kinda stopped involving myself in other people's OSS projects a while ago for that reason. If I have an itch to scratch, I just use my fork. It usually feels like my itch isn't theirs and I always feel like I'm imposing on the maintainer's vision or at best just taking time away from them. I think maintainers have a lot of pressure to accept things because "open source!".

A couple questions here - would more clear guidelines in the CONTRIBUTING.md file help in clarifying project direction and what contributions would be most valuable? Is there a better way for projects to indicate what issues should be prioritized? Do you ever want to run your contribution ideas past a maintainer before opening up a PR and if so do you ever do that? I'm curious if your itch may actually be something they're looking for too but it's not made clear in an effective way.

To be honest, I didn't really think about the goals of the projects at all. I'm not even sure if a CONTRIBUTING.md existed. I just needed a particular feature for something I was working and it felt like "being a good OSS citizen" to at least offer it back to the maintainer, but I think I just ended up putting them in a position where they felt like they had to make it work.

Totally get this. One thing we'd love to do is help make contribution patterns (not just guidelines) more visible to contributors, to help you get a better read of what's expected. Would that help? If so, where would you expect it to sit in your existing contribution flow?

I always thought it would be nice to see some kind of "maintainer profile" for each project, that the maintainers could set up: Is the project open to PRs? What is the quality bar for PRs? How much developer testing is expected before a PR is accepted? Are there any automated test coverage requirements/expectations? Sort of like a more structured version of CONTRIBUTING.md.

Also, statistics about past PRs: How long does it take, on average, before the maintainer responds to a PR, before it gets merged? What % are rejected or closed? How many edits do PRs for this project on average need before being accepted? What is the current incoming rate for PRs and what is the current merge rate? I could look at these and figure out if a project can sustain yet another incoming PR or if they are in over their heads. And it would help me understand what level of "done" they are expecting. Maybe some of these are even already available--i haven't really explored GitHub that much. Hope this helps.

> I'm hesitant to even open a PR, because...

For me the answer to this is to let go of all expectations. Fix things for your own purpose, and then open PRs to give the maintainers the option to engage or ignore.

Obviously from my post above, with my maintainer hat on I often fail to let go of the emotions. But it's a goal.

The lowest-stress PRs to handle are the ones with clearest test cases, and minimal incidental changes. Don't refactor, reformat or rename things to your own preferences and then expect a maintainer to engage.

Reducing changes to the meaningful minimum will also make your fork easier to maintain if the PR is refused, or ignored for months+ as the upstream project continues to evolve.

Ultimately, opening a PR is in part self-serving - best case is my change is upstreamed, worst case is I have taken time to streamline it, and simplify integration of future upstream changes into my fork.

Reply on news.ycombinator.com