9 ms·

New tools for open source maintainers

164 points by joeyespo 9y ago

Nullabillity 9y ago
The "retirement" feature is a good start, but oddly over-engineered. Just stop allowing username reuse, period!
- tmerse 9y ago
  Maybe it is in order to prevent something like domainsquatting – just for usernames.
ocdtrekkie 9y ago
Minimized comments (hot take): A fancy new feature for AMP developers to ignore serious security and openness concerns about AMP. Namespace retirement: Agreed with Nullability, just disable username reuse, it causes a lot more oddities than just cloning projects from unknown sources, old comments link to incorrect users and the like, it's awful. Accidental PR protection: So this won't affect anyone, if I read it correctly, who types something in the PR description? As long as that's the case, fine, but I definitely don't want to overly impose upon the drive-by contributor... as an occasional drive-by contributor. (Sometimes I fix spelling errors, someone's gotta do it.)
- quiq 9y ago
  I'm really hoping they're only blocking PR's from non-collaborators if the PR description is empty. Requiring someone to be a collaborator on a repository to open a PR is a step backwards to me. It's really nice to notice a trivial fix like a typo when browsing the code, fix it in the integrated editor and hit PR right there. I could see having the option to disable PRs useful, but removing the functionality entirely
  - fourthark 9y ago
    I think they meant, when the contributor is also not the author of the changes. At least I hope this is what they meant.
    - ocdtrekkie 9y ago
      Ah, I didn't catch that, and that's a plausible read. Because any contributor making an edit has push access to the source branch.
    - dantiberian 9y ago
      That makes much more sense, I was a bit confused by that section.
    - archi42 9y ago
      I think that's what they meant. Anything else wouldn't make much sense anyway. Seems like making a PR out of someone else's "private" changes now requires two PRs: first into my fork, then to upstream. Not that this is a common use case, but I did consider this two or three times the last five years...
- Gaelan 9y ago
  Maintainers were always able to delete comments. Minimization doesn’t do anything worse that what was already possible.
maxnoe 9y ago
Can someone explain the Pull Request restrictions? What does: "the changes are not explained in the commit body" actually mean? Is this opt in?
- rurban 9y ago
  I see this new feature as a bug. If you don't like a pull request close it or ignore it. But disabling accidental and “drive-through” pull requests sounds very bad to me.
  - chr1 9y ago
    Sometimes people use compare view and accidentally create pull requests without description from branches on which they do not have any commits. On popular projects this happens often enough to become annoyance for maintainers. I don't see any case when opening a pull request from someone else's branch and without a description could be done intentionally.
  - handbanana 9y ago
    If I understand the changes correctly, I agree.
  - TheDong 9y ago
    If you wish to create a pull request, you can always push the content you wish to PR to your fork of the repo and create one. It does add an extra step if you wish to PR someone else's code (you now have to fetch it from their remote, push it to yours, and then make the PR vs directly cross-repo PR between two repos you don't own). It's not a heavy extra step though and I don't see this as removing the ability for any number of small PRs.
- pietroalbini 9y ago
  As far as I understood this means you can't create pull requests of branches you don't have push access to (for example other people's forks) unless you're a project collaborator. It shouldn't affect your own branches.
- 9y ago
dfabulich 9y ago
The main thing I want to hide in minimized comments are "+1 fix this plz!" comments on bugs, comments that add nothing above and beyond a thumbs-up reaction. The "reasons" Github offers for minimizing comments are: Spam, Abuse, Off Topic, Outdated, and Resolved. "+1" isn't exactly any of those. (I guess they're kinda "Spam" but they're not unsolicited commercial messages.)
- ocdtrekkie 9y ago
  Maybe the missing feature here is that GitHub should "just" automatically minimize +1 comments. Or even better, delete them without sending a notification to maintainers/watchers, and automagically have the user who posted it add a thumbs up to the original issue. (Personally, I would consider them spam.)
  - reificator 9y ago
    I think they were valuable back when you couldn't react to a specific comment. I also think they're still valuable when you have Github and another VCS host, where one mirrors the other automatically.
  - joshfriend 9y ago
    > automagically have the user who posted it add a thumbs up to the original issue. I was astonished that they didn't do this when they introduced the emoji reactions feature.
    - michaelmior 9y ago
      Part of the problem is deciding what the +1 should be attached to. Some people comment +1 just because they want to see a PR merged. Some +1s are intended to be associated with a specific comment.
      - Cthulhu_ 9y ago
        But there's other systems for that; what you're describing are 'bumps' that have been in forums and such for forever now, and I'm sure that e.g. an upvote system (or sort by +1 reactions) would replace that system. I think it could be done on a per repository basis, like, basic behaviour rules just like at forums and other such communities. It's then up to the maintainer / moderators / whatever to allow or disallow +1-style comments, and what the 'punishment' would be. They could then also tweak a setting that auto hides comments if they're shorter than X characters.
kazinator 9y ago
I get all this by not using github. Minimized comments: I run the mailing list and can enable moderation at any time. Retire namespace: I control the web server and so every aspect of the URL after the domain name. Unwanted pull requests: no different from unwanted anything else.
- codetrotter 9y ago
  As someone that frequently makes small issue reports and occasional pull requests I am incredibly glad that people are using GitHub. As a contributor it makes things much simpler that all projects use one system instead of everyone inventing their own that works in different ways. Furthermore GitHub is great for quickly looking over a project when trying to determine if it suits my needs and for getting an impression of how complete it is, how maintained it is and what the code is organized like. I love GitHub, it is the single best thing that happened in software development for a long while. GH is not perfect, but it is awesome nonetheless.
  - reificator 9y ago
    Furthermore the serious concern with a VCS hosting monopoly is portability, but as long as Github uses git, portability is a non issue. Cloned the repository? You can now declare yourself the canonical source for that repo instead of Github, host it from your own machine, and let others pull directly from you. Not that you'd usually want to do that, but it's available as an option if you do. If Github closed down tomorrow, we'd lose a lot of code. If Github announced that in one year they were going to close down, then we'd only lose private repositories that no one bothered to clone. There is the issue of, well, issues. And pull requests and wikis and all that. But wikis are, as far as I know, just git repos themselves, so that's not too bad. Issues and pull requests and all of that sort of data probably has to be pulled out through the API into some format that's hopefully useful in other places. Could easily lose a lot of work here if Github went poof. Not that I think they will or that I want them to, just something that's important to consider when a service becomes a monopoly becomes critical infrastructure.
  - kazinator 9y ago
benatkin 9y ago
This comment hiding is a good feature. For judicious use, it greatly enhances the experience for both collaborators (people with write access to the repositories) and viewers. When overused, it allows collaborators to do what they want, as they should be able to, because GitHub provides tools for organizing communities* rather than communities themselves. For astute viewers, it provides a chance to observe the way that the collaborators manage their communities. * For an alternative of having shared ownership of open source, see Zed Shaw's post about Launchpad https://web.archive.org/web/20120318224723/http://sheddingbikes.com/posts/1299555462.html https://web.archive.org/web/20120318224723/http://sheddingbi... https://news.ycombinator.com/item?id=2299748 https://news.ycombinator.com/item?id=2299748
mattbierner 9y ago
I really hope they add some sort of "highlighted" or "closed by" comment feature as well. I've occasionally had to lock closed issues to stop a flood of "+1" comments from crowding out the comment that fully addressed the originally reported problem. Manually hiding or deleting all new "+1" comments would be a lot of work in these cases
raimue 9y ago
> [...] The author is not a bot account [...] How does GitHub identify "bot accounts"? I thought there is just one type of user accounts. You can give the API tokens generated on that account to a bot. But there is no flag in the settings to make it a "bot account".
- dflock 9y ago
  I think when GitHub says bit, they mean app.

164 points by joeyespo 9y ago

Nullabillity 9y ago

The "retirement" feature is a good start, but oddly over-engineered. Just stop allowing username reuse, period!

tmerse 9y ago
Maybe it is in order to prevent something like domainsquatting – just for usernames.

ocdtrekkie 9y ago

Minimized comments (hot take): A fancy new feature for AMP developers to ignore serious security and openness concerns about AMP. Namespace retirement: Agreed with Nullability, just disable username reuse, it causes a lot more oddities than just cloning projects from unknown sources, old comments link to incorrect users and the like, it's awful. Accidental PR protection: So this won't affect anyone, if I read it correctly, who types something in the PR description? As long as that's the case, fine, but I definitely don't want to overly impose upon the drive-by contributor... as an occasional drive-by contributor. (Sometimes I fix spelling errors, someone's gotta do it.)

quiq 9y ago
I'm really hoping they're only blocking PR's from non-collaborators if the PR description is empty. Requiring someone to be a collaborator on a repository to open a PR is a step backwards to me. It's really nice to notice a trivial fix like a typo when browsing the code, fix it in the integrated editor and hit PR right there. I could see having the option to disable PRs useful, but removing the functionality entirely
- fourthark 9y ago
  I think they meant, when the contributor is also not the author of the changes. At least I hope this is what they meant.
  - ocdtrekkie 9y ago
    Ah, I didn't catch that, and that's a plausible read. Because any contributor making an edit has push access to the source branch.
  - dantiberian 9y ago
    That makes much more sense, I was a bit confused by that section.
  - archi42 9y ago
    I think that's what they meant. Anything else wouldn't make much sense anyway. Seems like making a PR out of someone else's "private" changes now requires two PRs: first into my fork, then to upstream. Not that this is a common use case, but I did consider this two or three times the last five years...
Gaelan 9y ago
Maintainers were always able to delete comments. Minimization doesn’t do anything worse that what was already possible.

maxnoe 9y ago

Can someone explain the Pull Request restrictions? What does: "the changes are not explained in the commit body" actually mean? Is this opt in?

rurban 9y ago
I see this new feature as a bug. If you don't like a pull request close it or ignore it. But disabling accidental and “drive-through” pull requests sounds very bad to me.
- chr1 9y ago
  Sometimes people use compare view and accidentally create pull requests without description from branches on which they do not have any commits. On popular projects this happens often enough to become annoyance for maintainers. I don't see any case when opening a pull request from someone else's branch and without a description could be done intentionally.
- handbanana 9y ago
  If I understand the changes correctly, I agree.
- TheDong 9y ago
  If you wish to create a pull request, you can always push the content you wish to PR to your fork of the repo and create one. It does add an extra step if you wish to PR someone else's code (you now have to fetch it from their remote, push it to yours, and then make the PR vs directly cross-repo PR between two repos you don't own). It's not a heavy extra step though and I don't see this as removing the ability for any number of small PRs.
pietroalbini 9y ago
As far as I understood this means you can't create pull requests of branches you don't have push access to (for example other people's forks) unless you're a project collaborator. It shouldn't affect your own branches.
9y ago

dfabulich 9y ago

The main thing I want to hide in minimized comments are "+1 fix this plz!" comments on bugs, comments that add nothing above and beyond a thumbs-up reaction. The "reasons" Github offers for minimizing comments are: Spam, Abuse, Off Topic, Outdated, and Resolved. "+1" isn't exactly any of those. (I guess they're kinda "Spam" but they're not unsolicited commercial messages.)

ocdtrekkie 9y ago
Maybe the missing feature here is that GitHub should "just" automatically minimize +1 comments. Or even better, delete them without sending a notification to maintainers/watchers, and automagically have the user who posted it add a thumbs up to the original issue. (Personally, I would consider them spam.)
- reificator 9y ago
  I think they were valuable back when you couldn't react to a specific comment. I also think they're still valuable when you have Github and another VCS host, where one mirrors the other automatically.
- joshfriend 9y ago
  > automagically have the user who posted it add a thumbs up to the original issue. I was astonished that they didn't do this when they introduced the emoji reactions feature.
  - michaelmior 9y ago
    Part of the problem is deciding what the +1 should be attached to. Some people comment +1 just because they want to see a PR merged. Some +1s are intended to be associated with a specific comment.
    - Cthulhu_ 9y ago
      But there's other systems for that; what you're describing are 'bumps' that have been in forums and such for forever now, and I'm sure that e.g. an upvote system (or sort by +1 reactions) would replace that system. I think it could be done on a per repository basis, like, basic behaviour rules just like at forums and other such communities. It's then up to the maintainer / moderators / whatever to allow or disallow +1-style comments, and what the 'punishment' would be. They could then also tweak a setting that auto hides comments if they're shorter than X characters.

kazinator 9y ago

I get all this by not using github. Minimized comments: I run the mailing list and can enable moderation at any time. Retire namespace: I control the web server and so every aspect of the URL after the domain name. Unwanted pull requests: no different from unwanted anything else.

codetrotter 9y ago
As someone that frequently makes small issue reports and occasional pull requests I am incredibly glad that people are using GitHub. As a contributor it makes things much simpler that all projects use one system instead of everyone inventing their own that works in different ways. Furthermore GitHub is great for quickly looking over a project when trying to determine if it suits my needs and for getting an impression of how complete it is, how maintained it is and what the code is organized like. I love GitHub, it is the single best thing that happened in software development for a long while. GH is not perfect, but it is awesome nonetheless.
- reificator 9y ago
  Furthermore the serious concern with a VCS hosting monopoly is portability, but as long as Github uses git, portability is a non issue. Cloned the repository? You can now declare yourself the canonical source for that repo instead of Github, host it from your own machine, and let others pull directly from you. Not that you'd usually want to do that, but it's available as an option if you do. If Github closed down tomorrow, we'd lose a lot of code. If Github announced that in one year they were going to close down, then we'd only lose private repositories that no one bothered to clone. There is the issue of, well, issues. And pull requests and wikis and all that. But wikis are, as far as I know, just git repos themselves, so that's not too bad. Issues and pull requests and all of that sort of data probably has to be pulled out through the API into some format that's hopefully useful in other places. Could easily lose a lot of work here if Github went poof. Not that I think they will or that I want them to, just something that's important to consider when a service becomes a monopoly becomes critical infrastructure.
- kazinator 9y ago

benatkin 9y ago

This comment hiding is a good feature. For judicious use, it greatly enhances the experience for both collaborators (people with write access to the repositories) and viewers. When overused, it allows collaborators to do what they want, as they should be able to, because GitHub provides tools for organizing communities* rather than communities themselves. For astute viewers, it provides a chance to observe the way that the collaborators manage their communities. * For an alternative of having shared ownership of open source, see Zed Shaw's post about Launchpad https://web.archive.org/web/20120318224723/http://sheddingbikes.com/posts/1299555462.html https://web.archive.org/web/20120318224723/http://sheddingbi... https://news.ycombinator.com/item?id=2299748 https://news.ycombinator.com/item?id=2299748

mattbierner 9y ago

I really hope they add some sort of "highlighted" or "closed by" comment feature as well. I've occasionally had to lock closed issues to stop a flood of "+1" comments from crowding out the comment that fully addressed the originally reported problem. Manually hiding or deleting all new "+1" comments would be a lot of work in these cases

raimue 9y ago

> [...] The author is not a bot account [...] How does GitHub identify "bot accounts"? I thought there is just one type of user accounts. You can give the API tokens generated on that account to a bot. But there is no flag in the settings to make it a "bot account".

dflock 9y ago
I think when GitHub says bit, they mean app.