
New tools for open source maintainers - joeyespo
https://blog.github.com/2018-04-18-new-tools-for-open-source-maintainers/
======
dfabulich
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
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.)

~~~
joshfriend
> 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
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_
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.

~~~
tuespetre
You can sort by reactions on the issues list, if that’s what you meant.

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

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

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

------
benatkin
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://sheddingbi...](https://web.archive.org/web/20120318224723/http://sheddingbikes.com/posts/1299555462.html)

[https://news.ycombinator.com/item?id=2299748](https://news.ycombinator.com/item?id=2299748)

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

------
mattbierner
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
> [...] 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
I think when GitHub says bit, they mean app.

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

~~~
fake-name
Downside: Holy shit fuck mailing lists. They're _terrible_.

Major downside: You miss a huge percentage of possible contributors.

~~~
drej
This is fairly sad, because a lot of software is still maintained using
mailing lists. Often not because it's the best solution, but because it's the
least bad (for some). Also, if one wants to ensure that the whole lineage will
be with us 20 years from now, a mailing list is a better bet than all the
Gerrits and Githubs of the world.

I remember I wanted to check out what was happening in Postgres, since it's my
favourite database. But the sheer complexity of getting to the code diffs and
comments and all that... I quickly gave up, because the environment was rather
unfriendly to newcomers (actually, I didn't completely give up, I just browsed
the Github mirror, which was the only usable part of their version control).

And I'm not blaming them, it works well for the core devs, but they can't
expect many new contributors (and contributions are even things like
documentation, tests etc.!). Which is a pity.

~~~
anarazel
> (actually, I didn't completely give up, I just browsed the Github mirror,
> which was the only usable part of their version control).

What makes our git own git repo unusable?

[https://git.postgresql.org/gitweb/?p=postgresql.git;](https://git.postgresql.org/gitweb/?p=postgresql.git;)

I personally find that quicker to get around in than github.

~~~
kazinator
Man, why doesn't gitweb serve up the clone links as links that you can right
click and copy?

You have to swipe the cursor over
"[https://git.postgresql.org/git/postgresql.git"](https://git.postgresql.org/git/postgresql.git")
and copy; how lame.

CGIT is so much nicer. It also serves up tarballs out of tags. If you do a
"git tag foo-123" and push it out, then on your CGIT interface, there will be
a foo-123.tar.gz URL for download (as well as .bz2 and .zip), pulled right out
of the repo.

Still, either is light years ahead of github's presentation of repos.

> _What makes our git own git repo unusable?_

I know; WTF? From grandparent's comment I got the impression that Postgresql
must be using CVS, or just tarballs in a FTP directory or something (and that
someone kindly made a git repo and put it into GH).

