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.
[dead]
GitHub discusses giving maintainers control to disable PRs
31–40 of 75 posts
Re: GitHub discusses giving maintainers control to disable PRs
#32I 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…
> 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…
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.’”
Re: GitHub discusses giving maintainers control to disable PRs
#33I 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.
Isn't porting patches the equivalent of a halting problem? Or did you have something specific in mind?
Re: GitHub discusses giving maintainers control to disable PRs
#34Earlier quoted context omitted.
> 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…
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…
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.
Re: GitHub discusses giving maintainers control to disable PRs
#35About time. It's absolutely ridiculous that this hasn't existed for the past 10 years.
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.
Re: GitHub discusses giving maintainers control to disable PRs
#36I 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)".
Re: GitHub discusses giving maintainers control to disable PRs
#37Earlier quoted context omitted.
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, demandin…
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 a…
>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.
Re: GitHub discusses giving maintainers control to disable PRs
#38They 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 "oth…
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.
Re: GitHub discusses giving maintainers control to disable PRs
#39Some 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:
Re: GitHub discusses giving maintainers control to disable PRs
#40Earlier quoted context omitted.
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 a…
> 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.