New tools for open source maintainers | Hacker News Reader

New tools for open source maintainers

blog.github.com

164 pointsjoeyespo65 comments

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

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

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.

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

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.

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.

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

> Or even better

Well then the user would learn nothing. A better solution would be to notify them that this is wrong, delete their comment, and then prevent them from commenting on github.com for a period of time (1 hour? or more?)

They don't contribute to the topic, I would mark them as Off Topic.

Why not create a category 'redundant'?

Is there a way for users to easily demonstrate the need/desire for an issue to be fixed to developers? Do developers actually pay attention to how many reactions there are on issues?

If you don't have anything more to add to the discussion, but it seems like the issue is not being considered, a "+1" comment seems like the most effective way to communicate the need to the devs.

Ideally a thumbs up reaction would do the same thing, but does it? Do devs use the sort by "reaction" feature in real life?

I have not yet had the chance to be on the other side. I'm pretty sure I'd check that list occasionally, but I bet I'd forget a lot of the time. Especially if I had a busy project. Sorting by "most recent" or "number of" comments would be more likely. And that would make a "+1" comment more effective.

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

Maintainers were always able to delete comments. Minimization doesn’t do anything worse that what was already possible.

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

I think they meant, when the contributor is also not the author of the changes. At least I hope this is what they meant.

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.

That makes much more sense, I was a bit confused by that section.

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

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

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

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://news.ycombinator.com/item?id=2299748

Can someone explain the Pull Request restrictions?

What does: "the changes are not explained in the commit body" actually mean?

Is this opt in?

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.

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.

If I understand the changes correctly, I agree.

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.

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.

I believe it's an attempt to stop PRs like this: https://github.com/woocommerce/woocommerce/pull/19545

We get at least one of those a day and they are user error, spam or something. Definitely a useful feature for popular open source projects.

That one (in your URL) looks like the result of a PR between mismatched branches. eg instead of being the intended/correct source and destination branch, it's between two branches fairly far apart.

Thus a shed load of commits to try and resolve the difference.

Hopefully this new behaviour does fix the problem. On the other hand, I have a feeling it might alienate potential contributors who just aren't that familiar with git yet and could instead do with some guidance (ie how to use the correct branch to base changes on).

I guess we get to find out. :)

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

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

I think when GitHub says bit, they mean app.

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.

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.

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.

I didn't invent git, cgit or e-mail, all of which predate Github.

Github imposes a Terms of Service; I don't have to agree to any Terms of Service to use my own site. I am the Terms of Service.

There is all sorts of cruft in the ToS. Here is something I just spotted: "GitHub does not target our Service to children under 13, and we do not permit any Users under 13 on our Service." If a good programmer has produced a good patch, I want it, whether they are twelve or 92; and they are welcome to post it to a mailing list or send it to me directly. GH have to have this kind of rule because they can't 100% control what goes on their site, 24/7. (Really, if they were smart, they would make that 18.)

Another: If you believe that content on our website violates your copyright, please contact us in accordance with our Digital Millennium Copyright Act Policy. No spectre of DMCA hanging over my own site.

Abuse or excessively frequent requests to GitHub via the API may result in the temporary or permanent suspension of your account's access to the API. I can hammer my own server with as many requests as I want.

GitHub has the right to suspend or terminate your access to all or any part of the Website at any time, with or without cause, with or without notice, effective immediately. GitHub reserves the right to refuse service to anyone for any reason at any time. No comment required. Today, you have a bustling project; tomorrow it's gone.

> GH have to have this kind of rule because they can't 100% control what goes on their site, 24/7. (Really, if they were smart, they would make that 18.)

The age restriction is 13 years because of COPPA. It is there because of (sensible) Federal law.

https://en.wikipedia.org/wiki/Children%27s_Online_Privacy_Pr...

> No spectre of DMCA hanging over my own site.

A C&D could be sent to your hosting provider, your ISP and/or the registrar of your domain.

> A C&D could be sent to your hosting provider, your ISP and/or the registrar of your domain.

All of whom have a contract stating that they'll pass off all DMCA and Abuse messages to me, and I let my lawyer handle them directly.

Downside: Holy shit fuck mailing lists. They're terrible.

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

I don't want to deal with people who think e-mail is terrible, or contributors who can't copy a URL from a page served up CGIT, do a "git clone" on it, and then mail off the results of "git format-patch" when they are done. This stuff is incredibly easy.

It's not about email being easy. It's that I don't want my email getting out (spam and all that - you send one email to a bad behaving mailing list, and your email is all over the internet forever for spambots to harvest.)

Realistically if you've got commits in a public git repo, your email address is public no matter how they got there.

Realistically, people concerned about that (or just being lazy) don't put real e-mail addresses in there.

You can post using a fake or cloaked From: address to my mailing lists. I don't require a subscription for posting. You can always check the mail archive for replies to your post, if you care. I don't allow mail archives to be downloaded in the raw format. I added extra patches to the archiving software to conceal addresses better.

Mailman just replaces @ with "at" which spam harvesters could easily reverse; I made it better for my users; see below.

Kazinator's got your back!

  0:webserver:/var/lib/mailman# quilt applied
  privacy
  pipermail-to-lurker

  0:webserver:/var/lib/mailman# cat patches/privacy
  Index: mailman/Mailman/Archiver/HyperArch.py
  ===================================================================
  --- mailman.orig/Mailman/Archiver/HyperArch.py        2012-11-29 21:26:57.000000000 -0800
  +++ mailman/Mailman/Archiver/HyperArch.py     2012-11-29 22:27:51.000000000 -0800
  @@ -93,6 +93,8 @@
       True = 1
       False = 0

  +def hide_domain(s):
  +    return re.sub(r'([\w])([-+,.\w]+)([\w])@([\w])([-+.\w]+)([\w])[.]([\w]+)', '\g<1>...\g<3>@\g<4>...\g<6>.\g<7>', s)

   def html_quote(s, lang=None):
  @@ -281,10 +283,9 @@
               try:
                   i18n.set_language(lang)
                   if self.author == self.email:
  -                    self.author = self.email = re.sub('@', _(' at '),
  -                                                      self.email)
  +                    self.author = self.email = hide_domain(self.email)
                   else:
  -                    self.email = re.sub('@', _(' at '), self.email)
  +                    self.email = hide_domain(self.email)
               finally:
                   i18n.set_translation(otrans)

  @@ -412,9 +413,7 @@
                   otrans = i18n.get_translation()
                   try:
                       i18n.set_language(self._lang)
  -                    atmark = unicode(_(' at '), Utils.GetCharSet(self._lang))
  -                    subject = re.sub(r'([-+,.\w]+)@([-+.\w]+)',
  -                              '\g<1>' + atmark + '\g<2>', subject)
  +                    subject = hide_domain(subject)
                   finally:
                       i18n.set_translation(otrans)
               self.decoded['subject'] = subject
  @@ -466,7 +465,7 @@
               d["in_reply_to_url"] = url_quote(self._message_id)
               if mm_cfg.ARCHIVER_OBSCURES_EMAILADDRS:
                   # Point the mailto url back to the list
  -                author = re.sub('@', _(' at '), self.author)
  +                author = hide_domain(self.author)
                   emailurl = self._mlist.GetListEmail()
               else:
                   author = self.author
  @@ -574,10 +573,8 @@
           if mm_cfg.ARCHIVER_OBSCURES_EMAILADDRS:
               otrans = i18n.get_translation()
               try:
  -                atmark = unicode(_(' at '), cset)
                   i18n.set_language(self._lang)
  -                body = re.sub(r'([-+,.\w]+)@([-+.\w]+)',
  -                              '\g<1>' + atmark + '\g<2>', body)
  +                body = hide_domain(body)
               finally:
                   i18n.set_translation(otrans)
           # Return body to character set of article.
  @@ -1049,7 +1046,7 @@
           author = self.get_header("author", article)
           if mm_cfg.ARCHIVER_OBSCURES_EMAILADDRS:
               try:
  -                author = re.sub('@', _(' at '), author)
  +                author = hide_domain(author)
               except UnicodeError:
                   # Non-ASCII author contains '@' ... no valid email anyway
                   pass
  @@ -1221,7 +1218,7 @@
                       text = jr.group(1)
                       length = len(text)
                       if mm_cfg.ARCHIVER_OBSCURES_EMAILADDRS:
  -                        text = re.sub('@', atmark, text)
  +                        text = hide_domain(text)
                           URL = self.maillist.GetScriptURL(
                               'listinfo', absolute=1)
                       else:
  Index: mailman/Mailman/Utils.py
  ===================================================================
  --- mailman.orig/Mailman/Utils.py     2012-11-29 21:26:57.000000000 -0800
  +++ mailman/Mailman/Utils.py  2012-11-29 21:26:58.000000000 -0800
  @@ -438,9 +438,9 @@
       When for_text option is set (not default), make a sentence fragment
       instead of a token."""
       if for_text:
  -        return addr.replace('@', ' at ')
  +        return 'address-hidden'
       else:
  -        return addr.replace('@', '--at--')
  +        return 'address-hidden'

   def UnobscureEmail(addr):
       """Invert ObscureEmail() conversion."""

Personally, I just feel more socially intimidated when sending email than opening a GitHub pull request. In an email I feel like there's more of an expectation of at least basic pleasantries, whereas on GitHub I feel like I can get away with writing a good, matter-of-fact commit message and just leaving that as the PR message. Of course, most people are not as inhibited as I am…

Would it help if there is a dedicated mail alias for patches? As in <project-patches@example.com>.

Niceties are off-topic there by definition so you don't have to worry.

Git writes e-mails out of commits: see the "git format-patch" command. You can practically send that straight to the mail command.

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.

I'd argue that if one wants to ensure that the whole lineage will be with us 20 years from now, the first step is to make sure that the software is still alive 20 years from now. And using a mailing list is a good way of starving your project to death, if you're not Git or Linux or Postgres.

And I'm even worried about those... what will happen in a few years/decades from now, when the generation of devs that are using mailing lists is not active anymore?

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

Unfortunately, email lists are not easy to browse if you're not subscribed and browsing past messages from before you described isn't that easy. The easiest way I've found around that problem is to use an email to NNTP gateway like gmane. Though that makes me wonder why project discussion isn't managed via a newsgroup as opposed to an email list.

Postgres' archives aren't that bad. You can find things via $search_engine, view by time, thread view crosses months etc: https://www.postgresql.org/list/pgsql-hackers/

It apparently doesn't present a threaded view like a mail/news client would and downloading the mbox file requires one to authenticate with the server.

> It apparently doesn't present a threaded view like a mail/news client would

Not the same as a mail client, but once you opened an individual email there's threaded structure.

> and downloading the mbox file requires one to authenticate with the server.

It does, but also says “Please authenticate with user archives and password antispam” - it's just to make automated extraction of email addresses a bit more work.

> Not the same as a mail client, but once you opened an individual email there's threaded structure.

Yes, but it's much more cumbersome to navigate the thread compared to using an actual mail client. If web pages of mail archives could present an overview pane for navigating messages, it would go a long way to making them usable in a browser as opposed to just posting links to the immediate parent and the set of children for a given message.

Though I wish that having a NNTP gateway (or using NNTP as a primary method of communication for a project) was the standard as opposed to using a mailing list since it would make viewing past messages before subscribing to a newsgroup trivial.

> Yes, but it's much more cumbersome to navigate the thread compared to using an actual mail client. If web pages of mail archives could present an overview pane for navigating messages, it would go a long way to making them usable in a browser as opposed to just posting links to the immediate parent and the set of children for a given message.

It does, although discovery of the feature as well as the feature itself could use some improvement. In the header there's "Thread:" and the associated button displays the structure. You can also open a whole thread, but I don't find that particularly useful. The download mbox link inside a message will give you the whole thread as well.

Not all mailing list archivers are created equal.

For my own site, I rejected the awful Pipermail (default archiver with GNU Mailman) with its brutally ugly presentation format and text-only.

I found an alternative called Lurker, with a better web interface and some of the features you're mentioning, like threading.

I further customized Lurker. I gave it a button bar with custom icons, and hacked it to support in-line HTML (when people post HTML to the mailing list, it is integrated into the archive as HTML). Because that is dangerous, of course, I wrote a comprehensive HTML cleaner for that.

I welcome HTML in my mailing lists; it's time for mailing lists to retire "text only" rules. It improves the formatting of text, letting you use typewriter fonts, italics and bold appropriately, and real bullets.

Here is an archive message with in-line images, another benefit:

http://www.kylheku.com/lurker/message/20131110.004036.5ed128...

Here is discussion where you can see a branched tree view:

http://www.kylheku.com/lurker/message/20121127.210005.0ca78d...

Lurker mods: http://www.kylheku.com/cgit/lurker/

HTML cleaner: http://www.kylheku.com/cgit/hc/tree/

This lexically analyzes the HTML and filters out all unwanted tags, or unwanted attributes of otherwise wanted tags.

mbox archives reveal people's e-mails; you have to control access to those.

By the way, here is the Lurker author's response to my changes:

https://sourceforge.net/p/lurker/mailman/message/31487163/

TL; DR: Irrationally against all HTML in mail archives, even if properly cleaned. Thanks for Lurker, though!

> http://www.kylheku.com/lurker/message/20121127.210005.0ca78d....

That does look better compared to other web interfaces I've seen in the past (though you still have to hover over the icon to view details of a message like the author and subject).

One decent interface I've seen is public-inbox (https://public-inbox.org/git/). It presents an overview with the subjects and threading and allows for downloading mbox files or using an atom feed link.

The nice thing is that these can be used in parallel. Using Lurker doesn't preclude me from also setting up public-inbox as an alternative presentation of the same archives.

> (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;

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

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

Solution: gitlab, gitea and gogs exist.

Same advantages of self hosting, simple UI for inexperienced users, all the ability to control your own stuff.

I love mailing lists. They're a natural filter and get rid of a lot of the demographic you don't want in the first place.

> Holy shit fuck mailing lists. They're terrible.

What do you find terrible about them? When browsing email lists like the one used for developing git itself, I find it very easy to go through various patch sets and follow the discussion they have on each commit. My client makes it easy to search for subjects, expand or collapse threads, search for authors, etc.

The emails themselves are easy to read and don't require an excessive amount of scrolling to go through even if the patch set has multiple commits. It's quite easy to see comments on a patch set inline with the patch itself.

Reply on news.ycombinator.com