Live data from Hacker News

GitHub: Block the Bullies

github.com

121–130 of 151 posts

Re: GitHub: Block the Bullies

#121
post #51

Earlier quoted context omitted.

I guess he felt that others besides the troll were having a laugh at his expense, (i.e., the HN Tips guys comments, other penis-oriented repos connected to employees of aforementioned companies) and were, if only indirectly, in on the joke.

Yep, that's what people seem to gloss over when they think I just overreacted. I knew for a fact that several Ruby people considered this hilarious, and that one or more of them worked at github. In that situation, it's either I leave silently (which everyone thinks I should have done), or bring the issue up and make sure everyone knows what's going on. I prefer the latter because it at least lets others come behind…

You and others which may have been trolled before and did not "make a fuss". I see many here with a bully mentality, saying that one should just keep their head down and endure the trolls crap and they will go away. Except they won't.

Re: GitHub: Block the Bullies

#122
post #61

Earlier quoted context omitted.

Come on, admit that Zed is funny with style. He's bragging, too, but it's never condescending. That's the difference between a gentleman and dandy, and an ugly troll.

No, I won't admit that. His writing just makes me sad.

Grow a sense of humor.

Re: GitHub: Block the Bullies

#123
post #61

Earlier quoted context omitted.

Come on, admit that Zed is funny with style. He's bragging, too, but it's never condescending. That's the difference between a gentleman and dandy, and an ugly troll.

No, I won't admit that. His writing just makes me sad.

I'm sorry for you. Many of his rants made me laugh to tears. And more generally, did "Learning Python the hard way" make you sad, really ?

Re: GitHub: Block the Bullies

#124
I'm surprised that this feature wasn't in there to begin with. All social networking (which is primarily what Github is about - the source control really isn't anything new) should include bilateral confirmation.

What they've implemented is adequate, but I'd rather see something much stronger, like active confirmation from both parties before being added to a project.

Re: GitHub: Block the Bullies

#125

Earlier quoted context omitted.

I think he means making it clearer in the UI. It would be weird for Github to depend on HN to inform users.

The thing is that this is amazingly rare. The handful of times it's happened, the 'victim' most likely just removes the repo (which has always been possible) and that's the end of it. Others might say to their friends on IRC "Hey, can you see dongml in my projects list on github?" and sure enough the answer will be 'no'. It's easy to say "oh just add it to the UI", but to actually do it is another story. Before you k…

I'm not sure we're talking about the same thing. I mean making it more clear in the UI that there's a separation between projects where you're a committer, and where you're just invited (to use another poster's words). If an (apparently) Github employee feels the need to wonder how often he's going to have to explain it, it seems that there exists a common confusion in the distinction.

Re: GitHub: Block the Bullies

#126

Earlier quoted context omitted.

I'm still trying to figure this out myself. I think it's just built up over time. I've never met Zed. I don't quite understand how he's built such a following -- it's quite possible it's because he's a nice guy who helps people. It strikes me from what I've read by him and about him that this SEEMS unlikely, but again, I do not know him. The opinion that drove my response was that this was a monstrous waste of resour…

I am pretty sure that you are overplaying the 'poor github bullied by Zed' angle.

I'm not saying they were bullied, but Zed forced them to respond. He did it in a juvenile way, and it truly wasn't unreasonable for him to handle it in a more mature way. Email them. He's criticized me for not emailing him and meeting him face to face, so why didn't he waltz on over to GitHub HQ in town here and talk to them?

Oh, because then he wouldn't get any publicity. Doing support and keeping a startup in a good position despite outspoken users (who don't pay for the service) is a completely thankless job. I give github a ton of credit for responding well over a holiday weekend to what amounts to a screaming child. Not many other companies would do that.

That's why github rocks.

Re: GitHub: Block the Bullies

#127
post #41
post #39

Earlier quoted context omitted.

I think the number of steps isn't really that important. For me I care more about permission being explicit and not implicit. I prefer systems where other users have to get my permission to interact with me rather than automatically having permission to do so. It matters more on systems other than github but I think there's still an avenue for abuse with the current set up. It should be fairly trivial to script accou…

You'd just have a dashboard full of invites instead of a dashboard full of add notices. I have a feeling people just recoil to confirmation systems because it's comfortable. But remember that Undo > Confirmation. Always.

> You'd just have a dashboard full of invites instead of a dashboard full of add notices.

I don't participate on github so I did't think you'd just stuff all of those notices on the dashboard. That sounds like a pretty broken UI IMHO.

> But remember that Undo > Confirmation. Always.

That's your opinion and it's very clear from this thread that a significant number of people strongly disagree with it. I will concede that Undo in this context has much less friction, likely for most github users. I wouldn't necessarily agree that it's better and certainly not always.

Re: GitHub: Block the Bullies

#128
post #9
post #2

Is this due to the recent drama with Zed Shaw being invited to the "DongML" project? Very entertaining as an observer, but very annoying for Zed I'm sure. Sad that they still haven't added a requirement that you accept an invite to become a collaborator, or at least a profile setting on your account that requires that confirmation.

It's interesting to me that so many people want confirmations. You can remove yourself from any repository you wish at https://github.com/account/repositories (yes, I know — this is a confusing place. It's something I'd like to improve). But the idea is that "Confirm? Reject." is the same number of steps/interactions as "Added. Reject." Confirmations wouldn't make the experience any better for someone being annoyingl…

Except that when you are added, you start getting e-mail for commits, the subject line of which for dongml was an ASCII art penis. I'm a mongrel2 contributor and I received a half a dozen ascii art penises in my inbox towards the end of last week. Those were easy enough to filter out, since the subject line contains the project, but then the same guy also initiated a couple pull requests against mongrel2 with ascii art penises. This was clearly abusive behavior, and I'm glad that there are now tools to help prevent it.

Re: GitHub: Block the Bullies

#129
post #41

Earlier quoted context omitted.

You'd just have a dashboard full of invites instead of a dashboard full of add notices. I have a feeling people just recoil to confirmation systems because it's comfortable. But remember that Undo > Confirmation. Always.

> You'd just have a dashboard full of invites instead of a dashboard full of add notices. I don't participate on github so I did't think you'd just stuff all of those notices on the dashboard. That sounds like a pretty broken UI IMHO. > But remember that Undo > Confirmation. Always. That's your opinion and it's very clear from this thread that a significant number of people strongly disagree with it. I will concede t…

I would argue that in almost all cases, a confirmation is far inferior to undo from a usability standpoint.

I must admit to having been persuaded by Aza Raskin, in his widely-read article "Never Use a Warning When You Mean Undo".

[0] http://www.alistapart.com/articles/neveruseawarning

Re: GitHub: Block the Bullies

#130
post #129

Earlier quoted context omitted.

> You'd just have a dashboard full of invites instead of a dashboard full of add notices. I don't participate on github so I did't think you'd just stuff all of those notices on the dashboard. That sounds like a pretty broken UI IMHO. > But remember that Undo > Confirmation. Always. That's your opinion and it's very clear from this thread that a significant number of people strongly disagree with it. I will concede t…

I would argue that in almost all cases, a confirmation is far inferior to undo from a usability standpoint. I must admit to having been persuaded by Aza Raskin, in his widely-read article "Never Use a Warning When You Mean Undo". [0] http://www.alistapart.com/articles/neveruseawarning

It depends on the context. In the last two years I've worked on apps where undo would mean incurring liability or potentially losing money immediately following a change. In the first example where liability would be incurred allowing the user to undo a change would actually mean that two changes were made and both have to be tracked, with full audit trail etc. By prompting users for confirmation you have an opportunity to ensure that the user understands the consequences of their decisions. That may not matter for adding a contributor to a github project but it does when changing a federal form or legal document for example.
Post reply on HN