4 ms·

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

by ktsmith 15y ago

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.

kneath 15y ago
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.
- Zev 15y ago
  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. Remember that reputation is important. Always.
  - kneath 15y ago
    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.
    - Zev 15y ago
      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.
      - thenduks 15y ago
        Your comment [1] is a direct reply to one where kneath explicitly states it [2]. [1]: http://news.ycombinator.com/item?id=2606063 [2]: http://news.ycombinator.com/item?id=2605804 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.
        phaylon 15y ago
        I think he means making it clearer in the UI. It would be weird for Github to depend on HN to inform users.
        thenduks 15y ago
        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.
- ktsmith 15y ago
  > 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.
  - teach 15y ago
    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 http://www.alistapart.com/articles/neveruseawarning
    - ktsmith 15y ago
      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.
      - teach 15y ago
        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.

by ktsmith 15y ago

kneath 15y ago

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.

Zev 15y ago
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. Remember that reputation is important. Always.
- kneath 15y ago
  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.
  - Zev 15y ago
    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.
    - thenduks 15y ago
      Your comment [1] is a direct reply to one where kneath explicitly states it [2]. [1]: http://news.ycombinator.com/item?id=2606063 [2]: http://news.ycombinator.com/item?id=2605804 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.
      - phaylon 15y ago
        I think he means making it clearer in the UI. It would be weird for Github to depend on HN to inform users.
        thenduks 15y ago
        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.
ktsmith 15y ago
> 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.
- teach 15y ago
  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 http://www.alistapart.com/articles/neveruseawarning
  - ktsmith 15y ago
    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.
    - teach 15y ago
      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.