5 ms·

Once again I wish github would allow the ability to limit who could open issues and PRs in order to do development in the open with a trusted/vetted set of coll

Once again I wish github would allow the ability to limit who could open issues and PRs in order to do development in the open with a trusted/vetted set of collaborators without being subject to every zero-effort bug report from users.

lloydatkinson 5y ago
Bots that close or even delete issues where the issue template hasn't been filled in help a lot.
willcipriano 5y ago
I'm shocked that it doesn't. What would you do if you were being harassed?
- TingPing 5y ago
  You can block specific users and you can temporarily limit all interactions if getting spammed.
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."
- 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.
akvadrako 5y ago
You don't need to use github, especially when you don't want the public making issues.
- lamontcg 5y ago
  800# gorilla. don't think gitlab supports this either. that probably leaves self-hosting and all the brittleness and pain around that.
  - YorickPeterse 5y ago
    Correct, there's no way to restrict GitLab merge requests to trusted users, while still allowing others to view merge requests. It's either visible/accessible to all, or only to project members.
    - legobmw99 5y ago
      GitLab can have this “feature” if the accounts are locked behind an entity like a school which doesn’t allow arbitrary users to make a new account
  - MadeThisToReply 5y ago
    An aside, but is it a standard thing to write # to mean "pound" when you're talking about pounds as a unit of weight? Like as opposed to "800lb"? I knew what you meant, it's just I've never seen that notation before so I'm wondering if you just made it up or if I'm out of the loop somehow.
    - drfuchs 5y ago
      Using hash-mark to mean “pounds” goes back to 1850 at least. https://en.m.wikipedia.org/wiki/Number_sign https://en.m.wikipedia.org/wiki/Number_sign A few decades ago, it was very common to see at the deli counter, in the handwritten prices on signs jabbed into lunch meats and such. And on the price signs above the vegetable bins at the supermarket. In the US, anyway.
qbasic_forever 5y ago
It would be nice to make the "open source, but closed to contributions/collaborators" model like SQLite and others (lightstream, etc) follow more of a first class citizen on github.
- mtlynch 5y ago
  Small sidenote: Litestream loosened their contribution policy, and they now accept bugfixes but not new features: https://github.com/benbjohnson/litestream#contribution-policy https://github.com/benbjohnson/litestream#contribution-polic...
bsder 5y ago
I'm also not enamored of the fact that you can log into Github/Gitlab/etc. with accounts from everywhere (Gmail/Facebook/Twitter/etc.). I suspect that making someone go through the signup dance stopped a LOT of the worst level of morons. Is there a code hosting service that allows public viewing but still forces people to sign up for an account before being able to do actions?
- yjftsjthsd-h 5y ago
  Maybe sourcehut?
- cxr 5y ago
  Where do you see the ability to open issues and pull requests by signing in with Google without creating a GitHub account?

lloydatkinson 5y ago

Bots that close or even delete issues where the issue template hasn't been filled in help a lot.

willcipriano 5y ago

I'm shocked that it doesn't. What would you do if you were being harassed?

TingPing 5y ago
You can block specific users and you can temporarily limit all interactions if getting spammed.

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."
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.

akvadrako 5y ago

You don't need to use github, especially when you don't want the public making issues.

lamontcg 5y ago
800# gorilla. don't think gitlab supports this either. that probably leaves self-hosting and all the brittleness and pain around that.
- YorickPeterse 5y ago
  Correct, there's no way to restrict GitLab merge requests to trusted users, while still allowing others to view merge requests. It's either visible/accessible to all, or only to project members.
  - legobmw99 5y ago
    GitLab can have this “feature” if the accounts are locked behind an entity like a school which doesn’t allow arbitrary users to make a new account
- MadeThisToReply 5y ago
  An aside, but is it a standard thing to write # to mean "pound" when you're talking about pounds as a unit of weight? Like as opposed to "800lb"? I knew what you meant, it's just I've never seen that notation before so I'm wondering if you just made it up or if I'm out of the loop somehow.
  - drfuchs 5y ago
    Using hash-mark to mean “pounds” goes back to 1850 at least. https://en.m.wikipedia.org/wiki/Number_sign https://en.m.wikipedia.org/wiki/Number_sign A few decades ago, it was very common to see at the deli counter, in the handwritten prices on signs jabbed into lunch meats and such. And on the price signs above the vegetable bins at the supermarket. In the US, anyway.

qbasic_forever 5y ago

It would be nice to make the "open source, but closed to contributions/collaborators" model like SQLite and others (lightstream, etc) follow more of a first class citizen on github.

mtlynch 5y ago
Small sidenote: Litestream loosened their contribution policy, and they now accept bugfixes but not new features: https://github.com/benbjohnson/litestream#contribution-policy https://github.com/benbjohnson/litestream#contribution-polic...

bsder 5y ago

I'm also not enamored of the fact that you can log into Github/Gitlab/etc. with accounts from everywhere (Gmail/Facebook/Twitter/etc.). I suspect that making someone go through the signup dance stopped a LOT of the worst level of morons. Is there a code hosting service that allows public viewing but still forces people to sign up for an account before being able to do actions?

yjftsjthsd-h 5y ago
Maybe sourcehut?
cxr 5y ago
Where do you see the ability to open issues and pull requests by signing in with Google without creating a GitHub account?