Live data from Hacker News

New tools for open source maintainers

blog.github.com

21–30 of 67 posts

Re: New tools for open source maintainers

#21
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

Re: New tools for open source maintainers

#22

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.

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.

Re: New tools for open source maintainers

#23
post #5
post #4

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.

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.

Re: New tools for open source maintainers

#24

Earlier quoted context omitted.

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

Re: New tools for open source maintainers

#25
post #4

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

Re: New tools for open source maintainers

#26
post #20

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 corr…

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.

Re: New tools for open source maintainers

#27

Earlier quoted context omitted.

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…

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 g…

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

Re: New tools for open source maintainers

#28
post #20

Earlier quoted context omitted.

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.

Re: New tools for open source maintainers

#29

Earlier quoted context omitted.

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.

Re: New tools for open source maintainers

#30

Earlier quoted context omitted.

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

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...\g@\g...\g.\g', 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' + atmark + '\g', 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' + atmark + '\g', 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."""
Post reply on HN