I'm the GitHub employee that fixed the bug. I usually try not to get involved with stuff like this but I feel like I'm in a unique situation to correct the record here.
"They purposefully allow this glaringly obvious mechanism for insulting and annoying their members and are actually involved in the joke."
I've never heard of the joke. I've never heard of anyone at GitHub being involved in one of these jokes.
There has been one case that I'm aware of where someone mass added people to a repository in order to fill up activity feeds. That person was banned. It's an issue we'd like to address more generally.
"Until I broke their server they were all laughing at my 'testing' then they were pissed when they had to fix the bug I found."
I fixed the bug without being aware of any of this. I check our exception monitor every day. It was there. It was obvious. I fixed it.
It was a simple bug triggered by branch names that look like commit SHA1s. Here's the commit:
> It's an issue we'd like to address more generally.
I wish you would. I'm apparently not the only one who's had this "joke" played on them, and it'd be nice if it was ended.
Here's how you do it: If someone adds me to a project, either I can reject that add, OR I can block a project and they can never say anything to me again.
Pretty easy.
Also, you should talk with Tom about this joke, I'm sure he knows allll about it.
As a first measure I think we could make it so that once you removed yourself as a collaborator from a project, it would not be possible for the person to re-add you. I realize that's not ideal but would be much more trivial to implement than UI / additional server state for confirmation before being added.
That'd be a good moderate solution. It'd keep the simplicity of your collaborator UI intact, but let me avoid this kind of abuse. You might want to make it a "remove" and a "remove and block" so that people don't get into a bad state on accident.
That seems a bit stateful. For every project you'd have to remember the set of people who've removed themselves. What if a person later removes themselves and then changes their minds?
Maybe a simpler solution is: you can't add people, you can just send them an invite. The person can then choose to accept the invite or not.
If I suspect someone at github is in on the joke, then submitting a ticket to have them fix the problem wouldn't work. They'd just laugh at me and ignore it like they've done with other people.
Did you at least try to contact their support? If "someone is in on it" and they're all laughing at you already, yea, nothing would happen. But what if you're just making assumptions about them for no reason? it's hard to cry that they hate you and won't do anything if you didn't try official channels to get shit fixed.
"They purposefully allow this glaringly obvious mechanism for insulting and annoying their members and are actually involved in the joke."
I've never heard of the joke. I've never heard of anyone at GitHub being involved in one of these jokes.
There has been one case that I'm aware of where someone mass added people to a repository in order to fill up activity feeds. That person was banned. It's an issue we'd like to address more generally.
"Until I broke their server they were all laughing at my 'testing' then they were pissed when they had to fix the bug I found."
I fixed the bug without being aware of any of this. I check our exception monitor every day. It was there. It was obvious. I fixed it.
It was a simple bug triggered by branch names that look like commit SHA1s. Here's the commit:
https://gist.github.com/88bc774d0c97e6c955c0
It affected only branch list pages with branch names matching [0-9a-f]{40}.
"If you don't believe me, look at the HackerNewsTips twitter account, which I know is astroturfed by a github employee."
That is not a GitHub employee. We don't hire anyone that witty as a rule.