6 ms·

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

by getsat 15y ago

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.

latch 15y ago
Sad that they still haven't added a requirement that you accept an invite to become a collaborator That's one way to look at it..the other way is that they just designed coded, tested and rolled out a feature a day or two after a fairly hostile and accusatory customer complaint.
josegonzalez 15y ago
It was. But he is technically a "customer". More eyeballs == more potential conversions. Zed happens to give that, fortunately or unfortunately. But they were able to please a potential customer, and just give a better product overall. So maybe its because of something bad, but it's great product iteration.
kneath 15y ago
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 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.
- kellishaver 15y ago
  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.
- masterzora 15y ago
  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.
  - omaranto 15y ago
    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.
    - masterzora 15y ago
      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?
      - omaranto 15y ago
        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.

by getsat 15y ago

latch 15y ago

Sad that they still haven't added a requirement that you accept an invite to become a collaborator That's one way to look at it..the other way is that they just designed coded, tested and rolled out a feature a day or two after a fairly hostile and accusatory customer complaint.

josegonzalez 15y ago

It was. But he is technically a "customer". More eyeballs == more potential conversions. Zed happens to give that, fortunately or unfortunately. But they were able to please a potential customer, and just give a better product overall. So maybe its because of something bad, but it's great product iteration.

kneath 15y ago

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

kellishaver 15y ago
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.
masterzora 15y ago
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.
- omaranto 15y ago
  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.
  - masterzora 15y ago
    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?
    - omaranto 15y ago
      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.