yeah, I thought they were going to provide some sort of rationale as to why they've never implemented this. instead this post just basically goes "yeah, you guys have been asking for this feature for 10 years, and... it's a good idea! let's do it."
Imagine the panic inside Microsoft right now where they're all-in in "AI in everything, everywhere" and the results have been so bad that GitHub is being forced to finally let repo owners disable PRs to make it stop.
Honestly, it's not an area where there has been consensus on when we talk with maintainers. Some folks worry about that reducing the very nature of open source collaboration.
We've had the ability to temporarily disable PR's for a while for maintainers but we felt like it was time to look at this again and see what folks think.
> Some folks worry about that reducing the very nature of open source collaboration.
Collaboration on repos where the authors explicitly don't accept PRs and are going to auto close or ignore them? I don't get it - it's not like you're going to force opensource on anyone.
It is almost like finding 20 year old bugs on Mozilla tracker. That said GitHub doesn't have the excuse of mostly relying on volunteer work.
Also I don't find GitLab that much better. I remember the feature request for "Give option to disable automatic adding of 'Closes ISSUE' to merge requests" closed with "Why would you need an option for that, everyone either loves it or likes manually removing it every time.
Hey everyone, I'm a PM on the GitHub team building this feature. Really appreciate all the feedback coming in and want you to know that we're reviewing it carefully so we can figure out the best path forward.
Disabling PRs is just the first step in giving maintainers more control over their PR experience. We're exploring several longer-term ideas which you can learn more about in this discussion: https://github.com/orgs/community/discussions/185387
Please keep the ideas, questions, or concerns coming in either thread. Would love to keep hearing your thoughts!
Tldw: a popular YouTube video on “how to open a PR on GitHub” by an Indian channel (targeting Indian audiences) showed how to add their name to a PR step by step. The rest is just the scale of the Indian population in action. I hope the maintainers of expressjs can rest easy
Advise from low-quality bootcamp-like training programs that encourage open-source contribution, providing low-quality examples of such contribution, in order to improve one's resume and career chances.
I think we should still allow open contribution to OSS.
Maybe, a "Contributor Requests".
It would be a gate for new contributors. For maintainers, they would see what they have contributed to and see their new PR. It would show "open contributor requests"
I like the idea. Right now it's only possible to require approval for actions for new contributors. But once they get a PR in, they're free to spam new PRs that can clog resource-expensive pipelines. Would be nice to have something like 5+ PRs merged and be a contributor for 1 month before a PR is auto created and actions are allowed to run.
I have always been an advocate of forking, despite the overhead of maintaining patches, but porting patches should be trivial to automate now. There needs to be an easy way to publish, discover, and require community patches even if they don’t have the maintainer’s blessing.
The whole GitHub paradigm has muddied the meaning of the term "forking". It used to imply a serious intention to diverge. Now to a lot of people it just means doing any development on a copy of a repo. The "Fork" button on GitHub is really "Clone (to my account)".
An another thing I hope is added is some kind of internal karma system. E.g. if a user is spamming multiple PR to multiple repos, or is otherwise being disruptive and reported, their contributions should be flagged for review, or optionally not accepted at all.
They need to talk about how the pr itself should change. The text diff just is not the right thing to center. We should be using ai to chunk changes into reviewable bytes and to align on semantics and contracts.
> They need to talk about how the pr itself should change.
When PRs are spammed, it's impractical to discuss each submitted change. The existence of the PRs interferes with the ability of maintainers to continue making directed changes.
> We should be using ai to chunk changes into reviewable bytes and to align on semantics and contracts.
That statement is a convoluted version of the narcissist's entitlement. ie "other people should realize my vision".
The increased review burden is also happening inside companies. It’s genuinely hard to keep up with the volume. I was a little surprised to see my comment downvoted. I’m not saying we shouldn’t be able to delete slop PRs. Of course we should! I’m saying that the pr should change at least _somewhat_ in response to how much programming is changing.
Also worth stating that I have been ranting about contract first reviews for 10 years and it’s not just in response to llm written code.
I hope someone can explain the sentiment on HN to me. I don't get it, why is this popular?
I want to know how many PRs a project is getting, but more than that how receptive the maintainers are. Issues don't tell the whole picture, because work gets backlogged, and you can't expect people doing this for free to have an SLA or something. but PRs.. the work is ideally at least mostly done.
There is the one project for example, very popular in the industry it's used in. There is a specific use-case that I run into repeatedly, that it fails at. The project has lots of open issues (understandably), and there are multiple PRs to address that, but the maintainers give no good reason for not accepting it. I've been using some random guy's branch (who isn't even keeping up with the latest releases and backporting) for many years now, waiting for the maintainers to either reject it or accept the PR. Lots of people upvote, comment, and beg.
I want to see how maintainers handle that. This is really bad. I'd prefer if they stopped reporting of issues instead of PRs. Issues is providing support, PRs let other people who fixed something or added a feature attempt to contribute.
You can't just "fork it", that means you have to be the maintainer now. And how will people even find your "fork" which may have fixed things? I'd like to be able to at least find open and unmerged forks with a fix in place I could apply, even if the maintainer never got around to it.
Turning PRs off is the software equivalent of hardware makers turning off support for aftermarket parts.
Honestly, if you don't like PRs, ignore them like many already do. Does it look bad when you do that? Yes. As it should! Don't hide away from your preferences, own it. Let other people get access to fixes you either have no time to get to, or unwilling to implement.
Just the discussions alone on security related issues (or PRs as in this case) is telling sometimes.
> there are multiple PRs to address that, but the maintainers give no good reason for not accepting it.
Congrats on discovering the difference between “““Open Source””” (pro-corporate; a way to socially engineer people to do work for you for free from which you can turn around and profit) and Free Software!
“THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.”
You quoted a snipped out of context and argued the wrong thing. They don't need to give a good reason for accepting it, that's not the issue. the issue in this thread is taking away the ability to create PRs to begin with. You're overreaching and saying "not only do we offer no warranty or guarantees for this program, but we will actively prohibit others from linking their fixes to issues to prevent you from making the program usable". You don't owe users anything, but your users don't deserve hostility from you either!
Wrong; unsolicited PRs from people who want me to maintain their needs for them are what's hostile. Take the project as-is, fork and maintain it yourself, or pay up.
Why are unsolicited PRs hostile, you have no obligation to even read them? Unless you're saying you're obligated to do something about PRs.
If you want to host public projects, you will always have some responsibility to the public. Similar to how hardware makers shouldn't be making hard to repair their hardware.
If you plant a public tree for example, you may not be responsible if the tree produces a poisonous fruit or not, but if someone puts a sign next to the tree telling people "boil before eating,otherwise it's poisonous", that's their right. But if you don't want your tree to look bad and prevent them from doing so, now you're responsible for any poisoning from the tree. You can either be responsible or not responsible, but you can't be __irresponsible__. You can't act in a manner that you know will harm others, when not doing so costs you nothing, not even a perception of obligation.
If you have the right to turn off PRs, any company out there also has the right to make thing that are hard to repair. I don't want to say anyone who agrees with you on this thread complaining about Google or some other company shutting down your accounts with no explanation either.
Making my code public at all is what costs me nothing. I am already writing it. I am already versioning it with Git. Giving you access to it is either a no-op or is some amount of public good. It can never be a negative. This is what Free Software is. Read Stallman: https://www.gnu.org/philosophy/free-sw.html#four-freedoms
Joke's not on me, that's exactly what I was suggesting. you win! and I agree with that bot as a solution.
Keep your code private if that's your attitude though. You don't want to share your code, you just want free advertisement.
You know what, you wrote your code, you didn't write github, you don't own github and you don't own the interaction github users have regarding public projects.
PRs are not your software. What you need to do is maintain a private git repo, or just make the repo private and post tarballs and builds on the releases page. that will solve the problem even better for you. you'll still be publishing source as well as executables that way. PRs are about github, it's users and their interaction with projects. When you give someone access to a repo, you can't complain when they create a feature branch and request a merge, that's all a PR is. In your case, you want to give people access to source code but not a repository, so do just that and leave people who want to publish a repository alone, or restrict access to your repo to a github organization with people you approve of to make contributions to private repos.
> Keep your code private if that's your attitude though. You don't want to share your code, you just want free advertisement.
There is no money nor mindshare to be had, so advertising is the entirely wrong way to think about it. This is a thought-process warped by the commercial sector. Even if somebody doesn't use my code they are still welcome to learn from it. They're welcome to use it, too, I just don't want to know about it :)
Fair enough. But I go back to my point that you can share source code without hosting a repository and a version control system. version control systems are intended to facilitate collaboration on code, and their exposure implies the intended audience that would perform such collaboration. Making it private shows that collaboration isn't a public affair. You can have a public repo that only hosts releases, or just host releases on your website.
> taking away the ability to create PRs to begin with.
> your users don't deserve hostility from you either!
No one has the right to demand my time to review their PR to my code and explain or justify a rejection. If I don't want to accept PRs, that's a valid choice on my part.
I feel like I'm not even speaking english on this thread. I've said MANY times that project owners owe nothing to anyone, period. You don't owe anything. Ignore the PRs, send them to your junk folder. I don't care.
That has nothing to do with this discussion.
People have a right to propose changes to broken things they use. Your right to ignore them and not provide support is a two-way street. Others also have a right to ignore what you want and propose changes for other users to see.
it's right there is name of the feature "Pull Request", it's a request, not a demand.
If you were operating a non-profit business in person, you can't get mad at people suggesting changes either. You can ignore them for sure, you can pull up some disclaimer or whatever. But it's hostile and mean to prevent people from even stating their opinions and proposing a change.
At that point, make your project private.
You don't owe the public many things, but when you create a project and make it public on a shared hosting site, other users also have rights to make commentary, since you've exposed it as public, and proposals and to assist each other. I'd even go further to say that this counts as intentional interference with users' attempt to fix vulnerable and buggy code, and as such an intentional attempt to harm the public. It's one thing to not guarantee anything about your software, it's another thing to prevent people from trying to fix it.
> You don't owe the public many things, but when you create a project and make it public on a shared hosting site, other users also have rights to make commentary, since you've exposed it as public, and proposals and to assist each other.
Nothing is stopping them from doing that. But they are not entitled to do it on my repo.
It is not on your repo, that's the confusion in this thread. PRs have not made it to your repo yet, you're not entitled to them. It's regarding your repo, but it is not a change or an activity that's made it into your repo. It's people who have checked out a branch on their repo, PRs are a way for those people to publish the changes in their version of your repo -- their version.
What you guys are suggesting on this thread is to prohibit people who gained access to your repo as a result of you making it public (not just the zip/tarball of the code, but the repo) from linking the changes they made in their repo to the original parent repo. They're requesting you merge their changes, but not demanding, and you can ignore them. but that request and linkage helps your users, who are already not being supported by you or given any warrantly of usability of functionality by anyone at all. You're making something available to people and making it harder for them to support each other and fix the software on their own.
There is no confusion about that. I think the confusion is repo being used for both 1) the actual remote git repo hosted by GitHub and 2) the “repo” at GitHub.com/username/project.
I know that opening a PR does not affect the first, but it very much affects the second. For my project both are mine, and just as I have the right to ignore a PR and I have the right to reject any after they’re opened, so too do I have the right to reject PRs before they’re opened.
> their version
And they can keep doing that without cluttering my page.
> what you guys are suggesting…
So what? Who or what states they are entitled to have their changes visible as a request on my repo?
Having publicly accessible issue and PR pages opens breeds the kind of entitlement you are showing here: they do not have a right to open requests on my page any more than people have a “right” to comment on a blog post or a YouTube video. And keeping an issue/PR section available leads people to assume that they have a right to do it simply because they can.
> So what? Who or what states they are entitled to have their changes visible as a request on my repo?
You did, by making the repo public. You didn't make a release tarball public, you made git repository, designed for collaborating on code changes public. In this case, other users of github (including the general public) are exposed to a repository and all that entails. If you have no intention to let others do PRs, you don't need to host a public repository, you just need to host public tarballs of your source code.
> they do not have a right to open requests on my page any more than people have a “right” to comment on a blog post or a YouTube video.
Youtube videos are one-way consumption of media. Git repositories have the concept of merging, which is taking remote repository content and assimilating it with your repo (as you know), that's PRs. public repo = public/open PRs, because that's how a vcs works. You're not hosting a social media content on Github, you're hosting a public version control system, and you have the ability to make it private.
Youtube is hardly a good analogy, perhaps twitter or blue sky is, although even then it's consumed content, not collaboration. In that example though, what you all are proposing here is similar to tweeting but turning off the ability to get "noted" by the community. You have the right to say whatever you want (within the site's policy), but others also have the right to make community corrections (notes) so you won't mislead others.
> you just need to host public tarballs of your source code.
Except now I can do it all on one place.
> public repo = public/open PRs, because that's how a vcs works.
No it’s not. A PR is not a feature of git the vcs, it’s a feature of GitHub the website.
> other have the right to make community corrections
No, others have the ability. They are not an unalienable right to do so. Likewise they don’t have a right on my GitHub repo.
You keep falling back to “because they can, they have a right to”, which I think is obviously incorrect.
And I disagree that this is similar to notes on Twitter. It is comments on YouTube or replies on Twitter; they are by and large used by people to add their opinion on the topic.
> People have a right to propose changes to broken things they use.
Here's the root of your misunderstanding. “Broken” is subjective, relative only to you.
> it's right there is name of the feature "Pull Request", it's a request, not a demand.
That's marketing-speak. It is absolutely a demand. PRs are a growth-hacking feature and are part of how GitHub got to be so dominant. The abuse of social pressure calling someone's project unmaintained was the same mechanism used for the XZ Utils backdoor: https://securelist.com/xz-backdoor-story-part-2-social-engin...
> Here's the root of your misunderstanding. “Broken” is subjective, relative only to you.
This is not a misunderstanding. I want to know what other people subjectively think is broken, and their proposed fixes. So, if I agree with them, I can opt to use their fixes. A lot of time the developer does not want to maintain the added complexity, or does not agree with architectural or design decisions by the contributor, and that's fine. But I, as a user might agree with the contributor. it costs you, as the maintainer nothing to let people propose changes. nothing at all. as others have repeated many times on this thread, you're not even obliged to respond to PRs, it won't even cost you appearance or reputation. You're just annoyed, that's it, and instead of ignoring the thing that annoys you, the solution is hostility.
> That's marketing-speak. It is absolutely a demand.
If you have a contributor policy clearly defined, it isn't. When you publish a project for the public, people will use it, that's the expectation.
Perhaps if github linked your contributor policy that might help. You can also setup an action that will auto-close all PRs, commenting your contributor policy for everyone to see the reason. There are many ways to handle this, but people on this thread are choosing the lazy option that harms users the most. I think part of it might be that many of you have not dealt with projects that benefit heavily from PRs.
> I want to know what other people subjectively think is broken
And I do not. In fact I don't want to hear from anyone who uses my software at all, in any way. My software is for me, not for you, and not for them. If you think it's broken, make your own that isn't.
If your software is only for you, keep it private. Period.
When you make it public, the public have the right to fix it and share their fixes with each other. They can do it on another repo, but they discovered the code through your repo, so the easiest way is by linking it to your repo. If you don't want to hear from people at all, just publish the source without giving anyone access to the repo, or send notifications to junk folder, or use a lockdown bot like in the other post, host it on your own server and publish it on your own site, the solutions for you are endless. For the public, which you've exposed your software to, not so much. and that's the problem.
You should understand that this line of thinking is exactly why everyone is trying to require developers to identify themselves, sign their code,etc... We're depending on software too much to be tolerant of willful sabotage and reckless endangerment (e.g.: security patches).
Too late to edit, but here's the inarguable truth straight from the mouth of the Open Source Initiative, that the term was the direct product of Netscape's desire to get people to work for them for free: https://opensource.org/history
“The ‘open source’ label was created at a strategy session held on February 3rd, 1998 in Palo Alto, California, shortly after the announcement of the release of the Netscape source code. […] The conferees believed the pragmatic, business-case grounds that had motivated Netscape to release their code illustrated a valuable way to engage with potential software users and developers, and convince them to create and improve source code by participating in an engaged community. The conferees also believed that it would be useful to have a single label that identified this approach and distinguished it from the philosophically- and politically-focused label ‘free software.’”
Open source is not open contribution. There are many examples of open source, but closed contribution, e.g. SQLite.
What you are listing is a business strategy of a company (free labor and advertising). Desires of a company are very different from an unpaid volunteer.
In projects that leave PRs unanswered, the maintainer is already unpaid labor, but contributor want him to work on the contribution. That might not align with what maintainer wants.
Edit: Personally, I find reviewing least pleasant part of dev work. Thanks to LLMs, that now also significantly more of my paid work. My desire to do code reviews in my free time is massively lower. I would rather do it myself.
You can find the forks by looking in the "network" part of the UI.
I do agree that GitHub could do more to highlight forks and their relationship to one another. But I don't think the current way - having an open pull request - is the only way to do that.
As a former maintainer, I am very in favor of this move. After having spent 10 years or so being hounded with "Any update on this?" and "Can we get this merged?", I don't think I would ever do it again as long as there aren't controls in place to be able to set the expectation that the code is free to do with as you will, and please go ahead and fork if you want it to do something different.
Is there a way I can tell why the forks were created, like the PR description? Even if there was, I would still want to see comments/discussions both from maintainers and the community so I know i'm not applying some shady patch.
I think you and others on this thread have the problem of not being able to ignore people. But that's your problem entirely. If you want a feature to silence PR notifications, by all means, I have no problem with that. You're taking out your notification annoyance by taking away a critical feature from your users. That's just petty and mean in my opinion.
Heck, does your email client not have the feature to auto-sort emails to junk/deleted? Is there any frustration you have beyond that?
So you don't want to maintain a fork, but want a maintainer to do it for free for you and wondering why that PR is not accepted? If you feel so strongly about the project popular in your 'industry', consider providing some incentive for the maintainer to care. And no, a coffee is not an incentive.
Edit: this probably came off quite abrasive, but I'm getting entitled comments from users with no contributions, demanding fixes for their most ridiculously niche issues almost weekly. Like stuff doesn't build with their toolchain from 2014. Seriously? Yet, they can't be arsed to even check the fixes or follow up with basic details.
It's not even about the maintainer, I can't maintain a large and complex project supported by lots of maintainers on my own, as a fork. But I can make fixes available for other users as a PR..until it's merged (or not). This is about users of the software, how will taking away PRs affect them?
I'm not wondering why that PR is not accepted, maintainers have every right to ignore or reject PRs. But this discussion is about taking away the ability to even create PRs that other users of the software an discover. This is a user-hostile behavior fueled solely by laziness and pettiness.
> This is a user-hostile behavior fueled solely by laziness and pettiness.
Damn, that last quip is really poisoning the well here. As a maintainer, not being paid for my projects or contributions, I have every right to decide how and if I want to accept contributions.
who said otherwise? don't accept contributions, don't review them. I already conceded your rights there. This is about preventing other people from posting PRs in the first place, not about if you accept or reject them. Two different topics.
>I can't maintain a large and complex project supported by lots of maintainers on my own, as a fork
Do you need to "maintain" a complex project? Why can't you just add the patches you want on your fork and update as far as it suits you? Just as the upstream doesn't have to review or accept PRs, neither do you. Users can still see the network of forks, and ime there are few that are actively updated.
How can i tell why every fork was created? How can I tell it'll fix my issue?
The idea of maintaining a fork for the sake of a patch affecting only one version of the original software is silly. Not only that, others mentioned "networks" but how do users tell what I patched, diff every fork one by one? Perhaps there is a feature I don't know about since PRs just work for me.
About time. It's absolutely ridiculous that this hasn't existed for the past 10 years.
yeah, I thought they were going to provide some sort of rationale as to why they've never implemented this. instead this post just basically goes "yeah, you guys have been asking for this feature for 10 years, and... it's a good idea! let's do it."
My guess is AI powered auto-submission / spam to high value customers is forcing their hand.
Imagine the panic inside Microsoft right now where they're all-in in "AI in everything, everywhere" and the results have been so bad that GitHub is being forced to finally let repo owners disable PRs to make it stop.
Honestly, it's not an area where there has been consensus on when we talk with maintainers. Some folks worry about that reducing the very nature of open source collaboration.
We've had the ability to temporarily disable PR's for a while for maintainers but we felt like it was time to look at this again and see what folks think.
> Some folks worry about that reducing the very nature of open source collaboration.
Collaboration on repos where the authors explicitly don't accept PRs and are going to auto close or ignore them? I don't get it - it's not like you're going to force opensource on anyone.
A lot of GitHub public repo’s aren’t FOSS though.
It is almost like finding 20 year old bugs on Mozilla tracker. That said GitHub doesn't have the excuse of mostly relying on volunteer work.
Also I don't find GitLab that much better. I remember the feature request for "Give option to disable automatic adding of 'Closes ISSUE' to merge requests" closed with "Why would you need an option for that, everyone either loves it or likes manually removing it every time.
Exactly. Yes, please.
Just make the repo private?
"I am fine with my code being public, but I am not fine being badgered by people about changes I have no interest in." is a perfectly valid stance.
That doesn't work. What if your repo is a mirror of another repo?
Hey everyone, I'm a PM on the GitHub team building this feature. Really appreciate all the feedback coming in and want you to know that we're reviewing it carefully so we can figure out the best path forward.
Disabling PRs is just the first step in giving maintainers more control over their PR experience. We're exploring several longer-term ideas which you can learn more about in this discussion: https://github.com/orgs/community/discussions/185387
Please keep the ideas, questions, or concerns coming in either thread. Would love to keep hearing your thoughts!
I can imagine a few maintainers might appreciate that ability (https://github.com/expressjs/express/pulls?q=is%3Apr%20is%3A...).
Wow, what is the context for all of these spam PRs?
Tldw: a popular YouTube video on “how to open a PR on GitHub” by an Indian channel (targeting Indian audiences) showed how to add their name to a PR step by step. The rest is just the scale of the Indian population in action. I hope the maintainers of expressjs can rest easy
Advise from low-quality bootcamp-like training programs that encourage open-source contribution, providing low-quality examples of such contribution, in order to improve one's resume and career chances.
https://www.youtube.com/watch?v=YFkeOBqfQBw
[flagged]
Some projects (like the pi coding agent) use a gated approach for first-time contributors:
https://github.com/badlogic/pi-mono/blob/main/CONTRIBUTING.m...
Here is what it looks like in practice:
https://github.com/badlogic/pi-mono/issues/1218
I've started aggressively blocking low-quality contributions that have that AI-generated je ne sais quoi.
[flagged]
I think we should still allow open contribution to OSS.
Maybe, a "Contributor Requests".
It would be a gate for new contributors. For maintainers, they would see what they have contributed to and see their new PR. It would show "open contributor requests"
Once approved, The PR will then appear under PRs.
And obviously this is opt in.
I like the idea. Right now it's only possible to require approval for actions for new contributors. But once they get a PR in, they're free to spam new PRs that can clog resource-expensive pipelines. Would be nice to have something like 5+ PRs merged and be a contributor for 1 month before a PR is auto created and actions are allowed to run.
I have always been an advocate of forking, despite the overhead of maintaining patches, but porting patches should be trivial to automate now. There needs to be an easy way to publish, discover, and require community patches even if they don’t have the maintainer’s blessing.
The whole GitHub paradigm has muddied the meaning of the term "forking". It used to imply a serious intention to diverge. Now to a lot of people it just means doing any development on a copy of a repo. The "Fork" button on GitHub is really "Clone (to my account)".
How can you trivially automate conflicting changes?
Isn't porting patches the equivalent of a halting problem? Or did you have something specific in mind?
It's a founded move. GitHub is code hosting platform, so there are both grounds and needs for read-only repos without PRs.
We can easily close PR's. Even automated. Deletion is censorship and does certainly not improve the PR experience. To the contrary
An another thing I hope is added is some kind of internal karma system. E.g. if a user is spamming multiple PR to multiple repos, or is otherwise being disruptive and reported, their contributions should be flagged for review, or optionally not accepted at all.
[dead]
I'd like to see the ability for projects to require a payment before allowing an Issue to be opened.
Open source doesn't mean labor should be free. Would be a great way to support maintainers etc spending time investigating bug reports etc.
Absolutely not. That's the easiest way to kill a project.
[dead]
They need to talk about how the pr itself should change. The text diff just is not the right thing to center. We should be using ai to chunk changes into reviewable bytes and to align on semantics and contracts.
> They need to talk about how the pr itself should change.
When PRs are spammed, it's impractical to discuss each submitted change. The existence of the PRs interferes with the ability of maintainers to continue making directed changes.
> We should be using ai to chunk changes into reviewable bytes and to align on semantics and contracts.
That statement is a convoluted version of the narcissist's entitlement. ie "other people should realize my vision".
The increased review burden is also happening inside companies. It’s genuinely hard to keep up with the volume. I was a little surprised to see my comment downvoted. I’m not saying we shouldn’t be able to delete slop PRs. Of course we should! I’m saying that the pr should change at least _somewhat_ in response to how much programming is changing.
Also worth stating that I have been ranting about contract first reviews for 10 years and it’s not just in response to llm written code.
I hope someone can explain the sentiment on HN to me. I don't get it, why is this popular?
I want to know how many PRs a project is getting, but more than that how receptive the maintainers are. Issues don't tell the whole picture, because work gets backlogged, and you can't expect people doing this for free to have an SLA or something. but PRs.. the work is ideally at least mostly done.
There is the one project for example, very popular in the industry it's used in. There is a specific use-case that I run into repeatedly, that it fails at. The project has lots of open issues (understandably), and there are multiple PRs to address that, but the maintainers give no good reason for not accepting it. I've been using some random guy's branch (who isn't even keeping up with the latest releases and backporting) for many years now, waiting for the maintainers to either reject it or accept the PR. Lots of people upvote, comment, and beg.
I want to see how maintainers handle that. This is really bad. I'd prefer if they stopped reporting of issues instead of PRs. Issues is providing support, PRs let other people who fixed something or added a feature attempt to contribute.
You can't just "fork it", that means you have to be the maintainer now. And how will people even find your "fork" which may have fixed things? I'd like to be able to at least find open and unmerged forks with a fix in place I could apply, even if the maintainer never got around to it.
Turning PRs off is the software equivalent of hardware makers turning off support for aftermarket parts.
Honestly, if you don't like PRs, ignore them like many already do. Does it look bad when you do that? Yes. As it should! Don't hide away from your preferences, own it. Let other people get access to fixes you either have no time to get to, or unwilling to implement.
Just the discussions alone on security related issues (or PRs as in this case) is telling sometimes.
> there are multiple PRs to address that, but the maintainers give no good reason for not accepting it.
Congrats on discovering the difference between “““Open Source””” (pro-corporate; a way to socially engineer people to do work for you for free from which you can turn around and profit) and Free Software!
“THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.”
You quoted a snipped out of context and argued the wrong thing. They don't need to give a good reason for accepting it, that's not the issue. the issue in this thread is taking away the ability to create PRs to begin with. You're overreaching and saying "not only do we offer no warranty or guarantees for this program, but we will actively prohibit others from linking their fixes to issues to prevent you from making the program usable". You don't owe users anything, but your users don't deserve hostility from you either!
Wrong; unsolicited PRs from people who want me to maintain their needs for them are what's hostile. Take the project as-is, fork and maintain it yourself, or pay up.
Why are unsolicited PRs hostile, you have no obligation to even read them? Unless you're saying you're obligated to do something about PRs.
If you want to host public projects, you will always have some responsibility to the public. Similar to how hardware makers shouldn't be making hard to repair their hardware.
> If you want to host public projects, you will always have some responsibility to the public.
I disagree with this completely.
If you plant a public tree for example, you may not be responsible if the tree produces a poisonous fruit or not, but if someone puts a sign next to the tree telling people "boil before eating,otherwise it's poisonous", that's their right. But if you don't want your tree to look bad and prevent them from doing so, now you're responsible for any poisoning from the tree. You can either be responsible or not responsible, but you can't be __irresponsible__. You can't act in a manner that you know will harm others, when not doing so costs you nothing, not even a perception of obligation.
If you have the right to turn off PRs, any company out there also has the right to make thing that are hard to repair. I don't want to say anyone who agrees with you on this thread complaining about Google or some other company shutting down your accounts with no explanation either.
> If you have the right to turn off PRs
Joke's on you; I already do shut down every PR automatically on my projects with the repo-lockdown bot: https://github.com/marketplace/actions/repo-lockdown
Making my code public at all is what costs me nothing. I am already writing it. I am already versioning it with Git. Giving you access to it is either a no-op or is some amount of public good. It can never be a negative. This is what Free Software is. Read Stallman: https://www.gnu.org/philosophy/free-sw.html#four-freedoms
Joke's not on me, that's exactly what I was suggesting. you win! and I agree with that bot as a solution.
Keep your code private if that's your attitude though. You don't want to share your code, you just want free advertisement.
You know what, you wrote your code, you didn't write github, you don't own github and you don't own the interaction github users have regarding public projects.
PRs are not your software. What you need to do is maintain a private git repo, or just make the repo private and post tarballs and builds on the releases page. that will solve the problem even better for you. you'll still be publishing source as well as executables that way. PRs are about github, it's users and their interaction with projects. When you give someone access to a repo, you can't complain when they create a feature branch and request a merge, that's all a PR is. In your case, you want to give people access to source code but not a repository, so do just that and leave people who want to publish a repository alone, or restrict access to your repo to a github organization with people you approve of to make contributions to private repos.
> Keep your code private if that's your attitude though. You don't want to share your code, you just want free advertisement.
There is no money nor mindshare to be had, so advertising is the entirely wrong way to think about it. This is a thought-process warped by the commercial sector. Even if somebody doesn't use my code they are still welcome to learn from it. They're welcome to use it, too, I just don't want to know about it :)
Fair enough. But I go back to my point that you can share source code without hosting a repository and a version control system. version control systems are intended to facilitate collaboration on code, and their exposure implies the intended audience that would perform such collaboration. Making it private shows that collaboration isn't a public affair. You can have a public repo that only hosts releases, or just host releases on your website.
> taking away the ability to create PRs to begin with.
> your users don't deserve hostility from you either!
No one has the right to demand my time to review their PR to my code and explain or justify a rejection. If I don't want to accept PRs, that's a valid choice on my part.
I feel like I'm not even speaking english on this thread. I've said MANY times that project owners owe nothing to anyone, period. You don't owe anything. Ignore the PRs, send them to your junk folder. I don't care.
That has nothing to do with this discussion.
People have a right to propose changes to broken things they use. Your right to ignore them and not provide support is a two-way street. Others also have a right to ignore what you want and propose changes for other users to see.
it's right there is name of the feature "Pull Request", it's a request, not a demand.
If you were operating a non-profit business in person, you can't get mad at people suggesting changes either. You can ignore them for sure, you can pull up some disclaimer or whatever. But it's hostile and mean to prevent people from even stating their opinions and proposing a change.
At that point, make your project private.
You don't owe the public many things, but when you create a project and make it public on a shared hosting site, other users also have rights to make commentary, since you've exposed it as public, and proposals and to assist each other. I'd even go further to say that this counts as intentional interference with users' attempt to fix vulnerable and buggy code, and as such an intentional attempt to harm the public. It's one thing to not guarantee anything about your software, it's another thing to prevent people from trying to fix it.
> You don't owe the public many things, but when you create a project and make it public on a shared hosting site, other users also have rights to make commentary, since you've exposed it as public, and proposals and to assist each other.
Nothing is stopping them from doing that. But they are not entitled to do it on my repo.
It is not on your repo, that's the confusion in this thread. PRs have not made it to your repo yet, you're not entitled to them. It's regarding your repo, but it is not a change or an activity that's made it into your repo. It's people who have checked out a branch on their repo, PRs are a way for those people to publish the changes in their version of your repo -- their version.
What you guys are suggesting on this thread is to prohibit people who gained access to your repo as a result of you making it public (not just the zip/tarball of the code, but the repo) from linking the changes they made in their repo to the original parent repo. They're requesting you merge their changes, but not demanding, and you can ignore them. but that request and linkage helps your users, who are already not being supported by you or given any warrantly of usability of functionality by anyone at all. You're making something available to people and making it harder for them to support each other and fix the software on their own.
There is no confusion about that. I think the confusion is repo being used for both 1) the actual remote git repo hosted by GitHub and 2) the “repo” at GitHub.com/username/project.
I know that opening a PR does not affect the first, but it very much affects the second. For my project both are mine, and just as I have the right to ignore a PR and I have the right to reject any after they’re opened, so too do I have the right to reject PRs before they’re opened.
> their version
And they can keep doing that without cluttering my page.
> what you guys are suggesting…
So what? Who or what states they are entitled to have their changes visible as a request on my repo?
Having publicly accessible issue and PR pages opens breeds the kind of entitlement you are showing here: they do not have a right to open requests on my page any more than people have a “right” to comment on a blog post or a YouTube video. And keeping an issue/PR section available leads people to assume that they have a right to do it simply because they can.
> So what? Who or what states they are entitled to have their changes visible as a request on my repo?
You did, by making the repo public. You didn't make a release tarball public, you made git repository, designed for collaborating on code changes public. In this case, other users of github (including the general public) are exposed to a repository and all that entails. If you have no intention to let others do PRs, you don't need to host a public repository, you just need to host public tarballs of your source code.
> they do not have a right to open requests on my page any more than people have a “right” to comment on a blog post or a YouTube video.
Youtube videos are one-way consumption of media. Git repositories have the concept of merging, which is taking remote repository content and assimilating it with your repo (as you know), that's PRs. public repo = public/open PRs, because that's how a vcs works. You're not hosting a social media content on Github, you're hosting a public version control system, and you have the ability to make it private.
Youtube is hardly a good analogy, perhaps twitter or blue sky is, although even then it's consumed content, not collaboration. In that example though, what you all are proposing here is similar to tweeting but turning off the ability to get "noted" by the community. You have the right to say whatever you want (within the site's policy), but others also have the right to make community corrections (notes) so you won't mislead others.
> you just need to host public tarballs of your source code.
Except now I can do it all on one place.
> public repo = public/open PRs, because that's how a vcs works.
No it’s not. A PR is not a feature of git the vcs, it’s a feature of GitHub the website.
> other have the right to make community corrections
No, others have the ability. They are not an unalienable right to do so. Likewise they don’t have a right on my GitHub repo.
You keep falling back to “because they can, they have a right to”, which I think is obviously incorrect.
And I disagree that this is similar to notes on Twitter. It is comments on YouTube or replies on Twitter; they are by and large used by people to add their opinion on the topic.
> People have a right to propose changes to broken things they use.
Here's the root of your misunderstanding. “Broken” is subjective, relative only to you.
> it's right there is name of the feature "Pull Request", it's a request, not a demand.
That's marketing-speak. It is absolutely a demand. PRs are a growth-hacking feature and are part of how GitHub got to be so dominant. The abuse of social pressure calling someone's project unmaintained was the same mechanism used for the XZ Utils backdoor: https://securelist.com/xz-backdoor-story-part-2-social-engin...
> Here's the root of your misunderstanding. “Broken” is subjective, relative only to you.
This is not a misunderstanding. I want to know what other people subjectively think is broken, and their proposed fixes. So, if I agree with them, I can opt to use their fixes. A lot of time the developer does not want to maintain the added complexity, or does not agree with architectural or design decisions by the contributor, and that's fine. But I, as a user might agree with the contributor. it costs you, as the maintainer nothing to let people propose changes. nothing at all. as others have repeated many times on this thread, you're not even obliged to respond to PRs, it won't even cost you appearance or reputation. You're just annoyed, that's it, and instead of ignoring the thing that annoys you, the solution is hostility.
> That's marketing-speak. It is absolutely a demand.
If you have a contributor policy clearly defined, it isn't. When you publish a project for the public, people will use it, that's the expectation.
Perhaps if github linked your contributor policy that might help. You can also setup an action that will auto-close all PRs, commenting your contributor policy for everyone to see the reason. There are many ways to handle this, but people on this thread are choosing the lazy option that harms users the most. I think part of it might be that many of you have not dealt with projects that benefit heavily from PRs.
> I want to know what other people subjectively think is broken
And I do not. In fact I don't want to hear from anyone who uses my software at all, in any way. My software is for me, not for you, and not for them. If you think it's broken, make your own that isn't.
If your software is only for you, keep it private. Period.
When you make it public, the public have the right to fix it and share their fixes with each other. They can do it on another repo, but they discovered the code through your repo, so the easiest way is by linking it to your repo. If you don't want to hear from people at all, just publish the source without giving anyone access to the repo, or send notifications to junk folder, or use a lockdown bot like in the other post, host it on your own server and publish it on your own site, the solutions for you are endless. For the public, which you've exposed your software to, not so much. and that's the problem.
You should understand that this line of thinking is exactly why everyone is trying to require developers to identify themselves, sign their code,etc... We're depending on software too much to be tolerant of willful sabotage and reckless endangerment (e.g.: security patches).
“everyone” lmfao
fair criticism, everyone not in tech then. I meant governments and corporations though, it wasn't meant in the strictest sense obviously.
Too late to edit, but here's the inarguable truth straight from the mouth of the Open Source Initiative, that the term was the direct product of Netscape's desire to get people to work for them for free: https://opensource.org/history
“The ‘open source’ label was created at a strategy session held on February 3rd, 1998 in Palo Alto, California, shortly after the announcement of the release of the Netscape source code. […] The conferees believed the pragmatic, business-case grounds that had motivated Netscape to release their code illustrated a valuable way to engage with potential software users and developers, and convince them to create and improve source code by participating in an engaged community. The conferees also believed that it would be useful to have a single label that identified this approach and distinguished it from the philosophically- and politically-focused label ‘free software.’”
Open source is not open contribution. There are many examples of open source, but closed contribution, e.g. SQLite.
What you are listing is a business strategy of a company (free labor and advertising). Desires of a company are very different from an unpaid volunteer.
In projects that leave PRs unanswered, the maintainer is already unpaid labor, but contributor want him to work on the contribution. That might not align with what maintainer wants.
Edit: Personally, I find reviewing least pleasant part of dev work. Thanks to LLMs, that now also significantly more of my paid work. My desire to do code reviews in my free time is massively lower. I would rather do it myself.
You can find the forks by looking in the "network" part of the UI.
I do agree that GitHub could do more to highlight forks and their relationship to one another. But I don't think the current way - having an open pull request - is the only way to do that.
As a former maintainer, I am very in favor of this move. After having spent 10 years or so being hounded with "Any update on this?" and "Can we get this merged?", I don't think I would ever do it again as long as there aren't controls in place to be able to set the expectation that the code is free to do with as you will, and please go ahead and fork if you want it to do something different.
Is there a way I can tell why the forks were created, like the PR description? Even if there was, I would still want to see comments/discussions both from maintainers and the community so I know i'm not applying some shady patch.
I think you and others on this thread have the problem of not being able to ignore people. But that's your problem entirely. If you want a feature to silence PR notifications, by all means, I have no problem with that. You're taking out your notification annoyance by taking away a critical feature from your users. That's just petty and mean in my opinion.
Heck, does your email client not have the feature to auto-sort emails to junk/deleted? Is there any frustration you have beyond that?
So you don't want to maintain a fork, but want a maintainer to do it for free for you and wondering why that PR is not accepted? If you feel so strongly about the project popular in your 'industry', consider providing some incentive for the maintainer to care. And no, a coffee is not an incentive.
Edit: this probably came off quite abrasive, but I'm getting entitled comments from users with no contributions, demanding fixes for their most ridiculously niche issues almost weekly. Like stuff doesn't build with their toolchain from 2014. Seriously? Yet, they can't be arsed to even check the fixes or follow up with basic details.
It's not even about the maintainer, I can't maintain a large and complex project supported by lots of maintainers on my own, as a fork. But I can make fixes available for other users as a PR..until it's merged (or not). This is about users of the software, how will taking away PRs affect them?
I'm not wondering why that PR is not accepted, maintainers have every right to ignore or reject PRs. But this discussion is about taking away the ability to even create PRs that other users of the software an discover. This is a user-hostile behavior fueled solely by laziness and pettiness.
> This is a user-hostile behavior fueled solely by laziness and pettiness.
Damn, that last quip is really poisoning the well here. As a maintainer, not being paid for my projects or contributions, I have every right to decide how and if I want to accept contributions.
who said otherwise? don't accept contributions, don't review them. I already conceded your rights there. This is about preventing other people from posting PRs in the first place, not about if you accept or reject them. Two different topics.
>I can't maintain a large and complex project supported by lots of maintainers on my own, as a fork
Do you need to "maintain" a complex project? Why can't you just add the patches you want on your fork and update as far as it suits you? Just as the upstream doesn't have to review or accept PRs, neither do you. Users can still see the network of forks, and ime there are few that are actively updated.
How can i tell why every fork was created? How can I tell it'll fix my issue?
The idea of maintaining a fork for the sake of a patch affecting only one version of the original software is silly. Not only that, others mentioned "networks" but how do users tell what I patched, diff every fork one by one? Perhaps there is a feature I don't know about since PRs just work for me.