Live data from Hacker News

New tools for open source maintainers

blog.github.com

31–40 of 67 posts

Re: New tools for open source maintainers

#31

Earlier quoted context omitted.

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

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

Re: New tools for open source maintainers

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

Re: New tools for open source maintainers

#34

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.

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.

Re: New tools for open source maintainers

#35

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

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

Re: New tools for open source maintainers

#36

Earlier quoted context omitted.

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

Re: New tools for open source maintainers

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

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

Re: New tools for open source maintainers

#38

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.

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…

Re: New tools for open source maintainers

#39
post #29

Earlier quoted context omitted.

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.

Re: New tools for open source maintainers

#40
post #34

Earlier quoted context omitted.

Downside: Holy shit fuck mailing lists. They're terrible . Major downside: You miss a huge percentage of possible contributors.

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

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?

Post reply on HN