Comment by brunoborges | Hacker News Reader

Comment by brunoborges | Hacker News Reader

Open Source licenses are not about entitlement to contributions, engagement with the maintainers, or even community building. Open Source license is exclusively about the software. But the "Open Source Movement" is blending over, and that's what is burning out so many people on both sides: maintainers and contributors. GitHub's Pull Request feature creates an expectation that the maintainers will read a contributor's code, whether they had discussed about it or not.

Back in the days of SourceForge, open source software would be simply put for download. Anyone willing to collaborate, often times would first engage in the mailing lists or forums. That is not what GH Pull Requests do though, but quite the opposite. It builds on the idea that it is easier to discuss by showing code than by exchanging words. But that's just not how it works for anything beyond trivial/typo fixes. And that just frustrates everyone.

This is the flow I'd like to see GitHub allowing maintainers to choose, in addition to leaving today's flow as default:

- Allow maintainer to disable Pull Requests just like they can disable Issues/Discussions

- Allow maintainer to "Open Issue for Pull Requests"

This basically means that Pull Requests are on a per-issue basis, not per-repo. And only if the maintainers open said issue for accepting Pull Requests. This would push the contributors to first dialogue and discuss the enhancements/bugs before wasting any time writing code thay may never be accepted.

This flow would be much better for setting the right expectations, in my opinion.

> GitHub's Pull Request feature creates an expectation that the maintainers will read a contributor's code

> Back in the days of SourceForge...

Strongly agree. The github PR is a somewhat toxic misfeature. The last thing I want in my open source projects is some rando sending some huge diff that does who knows what. Now I'm supposed to read and understand this code and figure out all the unintended side effects? And even if the code is ok it's probably missing test coverage, doc updates, etc. So filling the gaps would generate more work for me.

However, I do like and accept tiny PRs that fix very targeted things.

I wish I could put a size limit on PR diffs in github. Something like if the PR changes more than 10 lines of code, block it. File a ticket instead of discuss the proposal, don't blast me with code I don't have time to read.

There is one way to disable pull requests on GitHub: enabling "interaction limits" on the repository. The gotchas are that it disables all interactions, not just pull requests, and it can only be enabled for 6 months at a time.

What I described is what I believe GitHub should support. Not that they support it today.

Right, I mean that there is a (caveat-ridden) workaround as it stands. I agree that repository maintainers should have the option to restrict or disable pull requests, just like they can disable other features.

GitHub should have an option to disable PRs for a repo, however:

- Owners are of no obligation to approve, close, merge, or interact with a PR in any way. If you don’t want to merge a PR, just don’t.

- you can include a readme which can include whatever discouragement you want.

- if you have a CONTRIBUTORS.md file, GitHub will show that to first time contributors when they submit a PR.

- I’m sure you could trivially have a GitHub action that will auto close all PRs as soon as they’re submitted.

All of that imply that contributors will read things before hitting the Fork button.

And everything (besides ignoring PRs) requires content to be explicitly added to the repository to configure GitHub's behavior. For some use cases -- like mirrors of repositories hosted elsewhere -- this isn't possible.

If someone's not going to bother themselves with checking the readme or contributors guide before submitting a PR, then they shouldn't be bothered by their PR being ignored or rejected.

It would be super nice if new issues (and PRs) could be made hidden from non-repo-members by default until they're triaged by a repo member (or until some timeout passes without the issue being closed/deleted).

There is a lot of performative abuse on github, where someone opens an ill-tempered or outright misleading issue, and hurls insults and then takes to twitter or reddit to try to get people to pile on, or they complain that their wall of invective was just summarily closed. And when you do ban people on github it has all kinds of weird side effects like blocking them from commenting on other project's issues where you're active.

In general, GH makes it really hard to ghost people. There have always been people who through personality or situation were unable to participate productively. Under older models of communication it was easy to simply ignore these unproductive actions without initiating any visible response that would trigger retaliation or fixation.

This is a great write up of just some of the challenges that open source project creators face.

I see a lot of people on this thread of calling for modifications to githubs systems. I really don't see them doing that.

maybe I misunderstand GitHub but as much as I like, enjoy and benefit from GitHub I just think their mission is to cater to the long tail as much as possible. and well maybe somewhat controversial I don't actually think their main play is enabling seamless collaboration I think that's just sort of a necessity for what they're really trying to do. I'm not sure what they're really trying to do but one can imagine there must be some sort of profitable businesses where you have all the world's developers on your system.

I think basically GitHub still wants to create a very sort of simple consumer focus product to maximize the quantity of interactions. they're not necessarily trying to lock down and restrict all those things you know and and and provide tools to upregulate the quality of that.

I'm sure that is a misrepresentation of only a small slice of github's strategy, but anyway I think it's an interesting thing to consider. I just basically don't see them landing a whole lot of features that provide really granular controls to all this stuff because I think they'd be worried that this is going to get in the way of the sort of simple understanding of the uniformity of their product and it's going to cause too much you know confusion and raise the barriers to long tail large quantity collaboration.

I could be totally misreading them but that's my feeling about it.

Reply on news.ycombinator.com