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 annoyingly added to projects. They'd just be rejecting invitations instead of rejecting access.
As it stands, when you are added as a collaborator to a project it shows up in exactly one place — your private, logged in dashboard. It doesn't show up publicly anywhere.
Bypassing confirmations keeps the workflow simple for the professionals who use GitHub and want to collaborate with ease.
I would disagree. If I happened to be in the job market, and my potential employer were to look at my github profile (yes, we do look at your github profile) and find "bigdicksucker" as one of the repos I'm apparently a "contributor" on, well, that wouldn't look too good, would it?
As it stands, when you are added as a collaborator to a project it shows up in exactly one place — your private, logged in dashboard. It doesn't show up publicly anywhere.
You must make a contribution to a project before you show up in any kind of public fashion.
Wouldn't it be possible for the troll to temporarily set his username to the same as yours in his git config, make a few commits, and then push them, thereby making it look like you had made a contribution to the project? Would this make your "membership" in the project appear publicly?
Or does Github track pushes by the pusher's Github username?
I think it tracks everything with the public key that you use to push to github. The username will look the same, but will not be linked to your account.
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 account creation, project creation, and marking someone as a collaborator. As such a troll could simply automate the process of creating accounts and junk projects and then add the victim as a collaborator to them. The result is a useless dashboard full of crap that the victim has to manually remove themselves from. The troll succeeds in screwing with the victim by wasting lots of time. If permission had to be explicitly granted there would be no change to the dashboard and all of the confirmation messages could be ignored, or ideally bulk deleted from the incoming message queue. I don't have any idea if there's flood prevention mechanisms built into github to prevent this, but with unlimited public projects on the free accounts it seems like an avenue of abuse for trolls.
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.
> 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.
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.
So in this case, you're not talking about making the software easier to use, you're talking about about making a cleaner legal audit trail. Which I'll still argue makes the application in question harder to use and is a worse software choice.
But a worse interface that makes the software easier to code is one thing; a worse interface that makes the software more easily comply with the law is an entirely different trade-off.
> you're talking about about making a cleaner legal audit trail.
Not exactly, the legal audit trail can be messy and it doesn't matter one bit so long as it's accurate. In the case described change one is logged and the undo constitues a second change which is also logged. Change one incurs liability for the user and change two simply increases the liability for the user (sorry I can't go into specifics) even though it's correcting a problem. In my experience it's very difficult to create a user interface where the "undo" action clearly indicates the consequence of the change in these scenarios. Preventing unnecessary changes via a combination of up front documentation and confirmation provided the better user experience, and legal liability reduction, in my experience and based on some user feedback.
> But a worse interface that makes the software easier to code is one thing; a worse interface that makes the software more easily comply with the law is an entirely different trade-off.
Believe me, not confirming user actions would have been less code and easier to build and maintain in this case. Legal compliance on my part would have been maintained in either case. Allowing my users to quickly and easily build up liability would be doing them a disservice however. Adding some friction to those transactions was agreed to be the better option by everyone involved.
I think the idea that confirmation vs undo is subjective. We can go on and on for hours and come up with examples and counter examples. The particular context of the action likely determines which provides the better user experience in total (not just on that one screen or interaction but via the consequences of the action as well). I would certainly prefer that if I'm using a system like facebook that it confirm I really want to make my home address and phone number public before it does so rather than letting me check a box and it's done. The same goes with a money transfer where an undo may not even be possible after some amount of time. Not prompting for confirmation certainly makes the transactions move faster (less friction) and undo is easy enough in many cases, but does that frictionless transaction have the best outcome for my users? Not always. The blanket statement that "undo > confirmation. Always." is just plain wrong, not that you made it of course.
Given the choice between a private dashboard vs a public repo list being spammed, I'll take the former, any day. I don't want either, but the former is an annoyance to me and only me. The latter is something that can (potentially) give a bad impression of me to others.
I'm not sure how many times I have to say it: Adding someone as a collaborator is not publicly visible until you collaborate (make commits) on the project. At that point we show the activity on your public profile.
This is, however, kind of counterintuitive for most people. Principle-of-least-surprise suggests you could do something about this; split the dashboard, say, into projects you participate in (indicated by having committed) and projects you've been invited to. You don't need the separate approval step there, so the workflow's the same, but it'd feel much more obvious.
Also; with the "professionals" thing - I totally get what you mean, and it's abundantly clear you guys are doing things for the right reasons, but the tone kind of jarred with me a little bit there. Nothing drastic, but I'm a person first, a professional second...
Up until just now, I didn't know that. And if you didn't reply to my comment just now, I still wouldn't know it.
And you explicitly telling people about how being a collaborator works isn't a scalable way for people to find out. And it sounds like this question/issue has come up before. Perhaps it can be made clearer somehow?
In any case, thanks for clarifying when you become visible as a collaborator, even if only in this one comment to me.
For me, it was pretty obvious because it doesn't show up on the profile under 'Public Repositories', only on the dashboard in a list of projects you have access to.
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 know it you've got hundreds of preferences, and then people will be complaining that there's too many options and it's too confusing (a-la facebook privacy settings). Honestly, GitHub's preference pages already need some work, so I for one am glad they don't add drop downs for every person's pet feature.
Regardless, it doesn't matter now. Now you just remove the project and block the user (or, presumably, just blocking the user might remove the repo... either way), so that's that.
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.
Yea sorry I tangent-ed a bit there. Probably because I just think this is a non-issue. It's in the UI in that it's listed in your repositories you have access to, but not on your profile. I don't see what kind of UI change they could make that would make it clearer short of text or a tooltip or something, and I think that the %0.001 of users who would ever care is just not worth the time to even considering it. The reason kneath was wondering how many times he had to say it is because it's all over this thread -- including the direct parent of the asker in this case.
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.
I agree that I don't want to see confirmations in my GitHub, but you are incorrect about them being equivalent. The optimal way to use confirmations is often not hitting "Reject" to requests you don't want. Just do nothing. In most well-designed systems, as long as there's an outstanding request, they can't bug you any more.
You can't have "do nothing" mean both "do not accept (yet?)" and also "accept!"; if no action keeps you from accepting, it means it'll take an extra step to actually accept an invitation. If the common case is not trolling, that adds friction.
I'm not sure what you're arguing here. Obviously "do nothing" can't mean both. Obviously the entire point of a confirmation would be such that it would take an action to be "accept", so that means that "do nothing" would have to be "do not accept (yet?)". Obviously this is only useful for GH if trolling is the common case. And obviously I started my post by saying I did not want confirmations. So what exactly are you trying to argue against?
Upon rereading I'm not sure what I meant either. My guess is that I was responding to
> The optimal way to use confirmations is often not hitting "Reject" to requests you don't want. Just do nothing.
and didn't read carefully. I was probably pointing out that if trolling is not the common case then that system is not in fact optimal (which I think we agree on), without realizing you didn't claim it was the optimal system but only the optimal system-which-uses-confirmations. Sorry about that.
I tend to agree with this line of thinking. I was added to half a dozen projects today alone. It would have been a pain to have to confirm each one.
Your average professional developer isn't trolled on a regular basis, nor would they go about adding "tech stars" to their repos just to have a big name on there or because they wished that person was a contributor - it's unprofessional and rude. So just dismissing yourself from the projects you are maliciously or mistakenly added to seems much simpler than having to confirm each one.
As it stands, when you are added as a collaborator to a project it shows up in exactly one place — your private, logged in dashboard. It doesn't show up publicly anywhere.
Bypassing confirmations keeps the workflow simple for the professionals who use GitHub and want to collaborate with ease.