12 ms·

You can already turn on repository interaction limits limiting issues/PRs to collaborators. It needs to be re-enabled every 6 months https://docs.github.com/en/

by inglor 5y ago

You can already turn on repository interaction limits limiting issues/PRs to collaborators. It needs to be re-enabled every 6 months https://docs.github.com/en/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository https://docs.github.com/en/communities/moderating-comments-a...

brunoborges 5y ago
It's not the same thing, because of the flow: - developer finds a cool project - developer consumes the cool project - developer finds opportunity for bug fix or enhancement - developer forks and starts working on the enhancements - developer spends hours/days writing code - developer submits a PR - developer gets a notification (upon filling the PR, or after, from a bot) - developer is now extremely frustrated - developer complains - maintainers and the developer start debating - the Pull Request storm goes viral - developer threatens to stop using cool project - maintainers handle the situation poorly (they are coders, not Public Relations people) - the community makes things worse And so on...
- bachmeier 5y ago
  I don't understand. You have "developer forks". Everything after that is irrelevant. That's the whole point of open source.
  - kccqzy 5y ago
    On GitHub a fork is a lightweight thing. People fork the repo in order to contribute because they can't push to the original repo. It's not like you are philosophically against Emacs and decide to fork it to produce XEmacs.
    - bachmeier 5y ago
      Just as I don't understand the original comment, I also don't understand yours. You don't need to push to the original repo because open source allows you to make your fork available to others. The developer of the original has a right to decide to accept your changes or not, so I fail to see why it matters that your PR isn't accepted.
      - Nadya 5y ago
        Maintaining a fork and maintaining a single feature of a project are two different levels of commitment and you can want to do one without doing the other although all too often people want to contribute a feature and then not provide support for it and expect the project maintainer to now maintain the contributed code. But that's a different issue (and why many maintainers sometimes don't accept random PR's even if the code itself is fine). > You don't need to push to the original repo because open source allows you to make your fork available to others. This is simply not true - not all open source software is copyleft. You can have restrictive licensing regarding use and/or distribution and still be open source.
        bachmeier 5y ago
        > This is simply not true - not all open source software is copyleft. You can have restrictive licensing regarding use and/or distribution and still be open source. Well, of course you can adopt any definition of "open source" you want, but I'm using the OSI definition, which states: "The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software." You are referring to "source available", for which they offer the clarification: "Open source doesn't just mean access to the source code."
        Nadya 5y ago
        There is a reason FLOSS exists as a term to differentiate itself from OSS and I think the ideological differences between the two are important. So does Bruce Perens, the co-founder of OSI and the author of the Debian Social Contract of which the OSI definition was based off: https://web.archive.org/web/20140716055445/https://lists.debian.org/debian-devel/1999/02/msg01641.html https://web.archive.org/web/20140716055445/https://lists.deb... This was back in 1999 - it's been over 20 years and "OSS" has only been muddied further and further to mean "source available" since. Pedantry aside tremon's response sums it up well: "Feature branch hosted in a separate repository."
        5y ago
- jenscow 5y ago
  Perhaps the developer should have discussed their ideas before investing their time, if they're going to be upset about their unsolicited code being rejected.
  - rectang 5y ago
    The maintainer still has to deal with the negative interaction even if in some cosmic sense the contributor could have known better. A workflow design which ensures that such negative interactions take place is structurally flawed.
    - chii 5y ago
      what's so negative about pressing the reject button of the PR? The maintainer doesn't have to even spend more than a second rejecting any contributions they get. They don't have to read any of the comments, nor reply to any concerns from the contributors. The contributors aren't entitled to the time of the maintainers.
- jrochkind1 5y ago
  If issues/PRs were limited to collaborators, wouldn't they not be able to submit a PR at all?
  - brunoborges 5y ago
    Here's how I propose a better PR flow in GitHub: https://news.ycombinator.com/item?id=30705581 https://news.ycombinator.com/item?id=30705581
lamontcg 5y ago
That isn't the same thing. It is temporary. You can also only limit to existing users (blocking only new GH users which is useless), or limit to contributors (people who have merged commits in the main branch), or limit to users with write access. I want to retain sole write access but allow issues to be cut by trusted users who have never submitted PRs or code. I also want it permanent and not temporary.

by inglor 5y ago

brunoborges 5y ago

It's not the same thing, because of the flow: - developer finds a cool project - developer consumes the cool project - developer finds opportunity for bug fix or enhancement - developer forks and starts working on the enhancements - developer spends hours/days writing code - developer submits a PR - developer gets a notification (upon filling the PR, or after, from a bot) - developer is now extremely frustrated - developer complains - maintainers and the developer start debating - the Pull Request storm goes viral - developer threatens to stop using cool project - maintainers handle the situation poorly (they are coders, not Public Relations people) - the community makes things worse And so on...

bachmeier 5y ago
I don't understand. You have "developer forks". Everything after that is irrelevant. That's the whole point of open source.
- kccqzy 5y ago
  On GitHub a fork is a lightweight thing. People fork the repo in order to contribute because they can't push to the original repo. It's not like you are philosophically against Emacs and decide to fork it to produce XEmacs.
  - bachmeier 5y ago
    Just as I don't understand the original comment, I also don't understand yours. You don't need to push to the original repo because open source allows you to make your fork available to others. The developer of the original has a right to decide to accept your changes or not, so I fail to see why it matters that your PR isn't accepted.
    - Nadya 5y ago
      Maintaining a fork and maintaining a single feature of a project are two different levels of commitment and you can want to do one without doing the other although all too often people want to contribute a feature and then not provide support for it and expect the project maintainer to now maintain the contributed code. But that's a different issue (and why many maintainers sometimes don't accept random PR's even if the code itself is fine). > You don't need to push to the original repo because open source allows you to make your fork available to others. This is simply not true - not all open source software is copyleft. You can have restrictive licensing regarding use and/or distribution and still be open source.
      - bachmeier 5y ago
        > This is simply not true - not all open source software is copyleft. You can have restrictive licensing regarding use and/or distribution and still be open source. Well, of course you can adopt any definition of "open source" you want, but I'm using the OSI definition, which states: "The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software." You are referring to "source available", for which they offer the clarification: "Open source doesn't just mean access to the source code."
        Nadya 5y ago
        There is a reason FLOSS exists as a term to differentiate itself from OSS and I think the ideological differences between the two are important. So does Bruce Perens, the co-founder of OSI and the author of the Debian Social Contract of which the OSI definition was based off: https://web.archive.org/web/20140716055445/https://lists.debian.org/debian-devel/1999/02/msg01641.html https://web.archive.org/web/20140716055445/https://lists.deb... This was back in 1999 - it's been over 20 years and "OSS" has only been muddied further and further to mean "source available" since. Pedantry aside tremon's response sums it up well: "Feature branch hosted in a separate repository."
        5y ago
jenscow 5y ago
Perhaps the developer should have discussed their ideas before investing their time, if they're going to be upset about their unsolicited code being rejected.
- rectang 5y ago
  The maintainer still has to deal with the negative interaction even if in some cosmic sense the contributor could have known better. A workflow design which ensures that such negative interactions take place is structurally flawed.
  - chii 5y ago
    what's so negative about pressing the reject button of the PR? The maintainer doesn't have to even spend more than a second rejecting any contributions they get. They don't have to read any of the comments, nor reply to any concerns from the contributors. The contributors aren't entitled to the time of the maintainers.
jrochkind1 5y ago
If issues/PRs were limited to collaborators, wouldn't they not be able to submit a PR at all?
- brunoborges 5y ago
  Here's how I propose a better PR flow in GitHub: https://news.ycombinator.com/item?id=30705581 https://news.ycombinator.com/item?id=30705581

lamontcg 5y ago

That isn't the same thing. It is temporary. You can also only limit to existing users (blocking only new GH users which is useless), or limit to contributors (people who have merged commits in the main branch), or limit to users with write access. I want to retain sole write access but allow issues to be cut by trusted users who have never submitted PRs or code. I also want it permanent and not temporary.