Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New tools for open source maintainers

blog.github.com

Post reply on HN
Print view View original

41–50 of 67 posts

Re: New tools for open source maintainers

#41

Post by archi42 »

fourthark wrote: post #26
quiq wrote: 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.

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

Re: New tools for open source maintainers

#42

Post by kuschku »

codetrotter wrote: post #27
kazinator wrote: post #18

Earlier quoted context omitted.

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…

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

Re: New tools for open source maintainers

#43

Post by kuschku »

fake-name wrote: post #19
kazinator wrote: post #12

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.

Solution: gitlab, gitea and gogs exist.

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

Re: New tools for open source maintainers

#44

Post by 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".

Re: New tools for open source maintainers

#45

Post by raarts »

Mashimo wrote: post #35
dfabulich wrote: post #7

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.

Why not create a category 'redundant'?

Re: New tools for open source maintainers

#46

Post by tuespetre »

Cthulhu_ wrote: post #36
michaelmior wrote: post #31

Earlier quoted context omitted.

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

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

Re: New tools for open source maintainers

#47

Post by andrewmcwatters »

fake-name wrote: post #19
kazinator wrote: post #12

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

Re: New tools for open source maintainers

#48

Post by falanjito »

dfabulich wrote: post #7

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

If you see the users of your library as SPAM you might as well kill yourself.

Re: New tools for open source maintainers

#49

Post by kazinator »

comex wrote: post #38
kazinator wrote: post #22

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.

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.

Re: New tools for open source maintainers

#50

Post by daeken »

falanjito wrote: post #48
dfabulich wrote: post #7

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

If you see the users of your library as SPAM you might as well kill yourself.

'dang: Suggestion in light of this comment: Maybe users should be autobanned if they have N flags within M minutes of account creation. This is an obvious troll account, but as of now it'll take way too long (IMO) for them to be banned. Something to think about!
Post reply on HN