Allow assignment of issues to non-collaborators

[patcon]

Context: https://github.com/drush-ops/drush/pull/88#issuecomment-24595732

Currently, if a potential contributor want's to publicly assign themselves to a particular issue, they apparently must be granted push access to the repo. This makes it difficult for a potential contributor to "bookmark" an issue for later effort, making full use of this issue listing: https://github.com/dashboard/issues/assigned?direction=asc&sort=updated&state=open

(Alternatively, "push" access collaborators should also be able to assign issues to themselves. Specifically reticketed this is #153)

cc: @greg-1-anderson

(Sent an email to support@github.com. Will publish response here. Whoop whoop!)

[jadonk]

grrr

[colonelpanic8]

Please stop writing new comments with +1 and , you notify dozens of other people about your wordless opinion. Put your finger up in the first comment, that's enough.

While I agree with the sentiment here, I have to leave a comment here because of #283 (or else I won't be able to easily find this issue later)

[AlexWayfer]

While I agree with the sentiment here, I have to leave a comment here because of #283 (or else I won't be able to easily find this issue later)

Thanks, I'll know.

(GitHub resolves issues veeeeery slow, it's awful).

[SteveALee]

Now people can find issues labled 'Help Wanted' and offer help they need to be assigned the issue even if can only supply a PR

[kkm000]

This issue started its long life in 2013, and has been open for 2013 days as of today (just a little over five and a half years). Happy birthday utterly irrelevant numerical coincidence, our dear senior feature request! 🍾🍾🍾 Hope your life is comfortable on the internal feature list--you must have hundreds of friends there!

I sincerely wish you be taken care of during the next 5.5 years! If you and #1131 are both fixed before the Sun engulfs the Earth, we'll even be able to track our issues on GitHub, not on napkins, grocery receipts and banana peels, as we do it now!

[clarkbw]

We're looking into this. Being able to assign anyone randomly is an abuse vector because I can create an issue with an abusive title and assign a person to it to harass them. To prevent this we're likely to require that a person has interacted with repository in some fashion via commits or commenting in an issue; a low enough bar that limits abuse.

[kkm000]

@clarkbw, thank you, I think this is a great idea! No additional setup, no need to add collaborators to a list, or do anything at all. Super!!! I would love to see it implemented this way!

[yatil]

@clarkbw That would be incredibly useful for us at @w3c. Maybe just allowing it for organizations and not for individual repositories could be another way to limit the abuse vector. (Thanks for thinking about that, btw., it is an important consideration!)

[bazzilic]

@yatil Bulletproof plan. These stupid spammers and abusers will never figure out how to create an organisation!

@clarkbw Great to hear that you guys are working on this! If a person follows/starred a repository, wouldn't this be enough for the repo owner to be able to assign issues to them?

[TPS]

@clarkbw I don't quite understand how that abuse potential isn't easily averted: Wouldn't a simple invitation system solve it? (That's not saying the backend would be easy!) E.g., a user w/ rights assigns whomever. Said whomever receives UI/e-mail invite to accept assignment to issue. If declining, can do so semi-permanently (like "Block Users" UI, easily reversible) per inviter/repo/org/whatever.

[clarkbw]

@tps that system is elegant even through it takes some backend work. The issue is then with notifications. Imagine I keep creating issues with the title “TPS is stupid” and you get those in your inbox. You could imagine a 1 step abstraction where we notify you of an invitation without the title. But eventually you’ll need to see the title or content to know it’s valid. Blocking at this stage is valid and means you should only see this thing once. But our research so far shows that assigning to someone who has never participated in the repo at all is a very low occurrence event. It seems like a good compromise to ask that someone participate even a little before they can be assigned. Perhaps later we’ll find you’re right and we need to expand it, but that’s ok; we can do that after. Or further research could change our minds now. Still investigating.

[TPS]

@clarkbw I agree an assignee should've had some interaction w/ the repo/org/assigner/whatever. But I believe that invitation system is necessary on top of that, perhaps w/ Settings toggles:

• [ ] Automatically accept all assignments w/o invitation {default OFF, please}

• [ ] Allow invitations to assignment when I

  • [ ] Open PR/issue
  • [ ] Comment in
    • [ ] reply to [usergroup w/ appropriate rights, whatever's that's called 🤔]
    • [ ] PR/issue
    • [ ] repo
    • [ ] org
  • [ ] Have no relationship whatsoever {default OFF, please}

[kkm000]

@TPS, an invitation system is a non-starter. With it, instead of tracking issue assignment to non-members on banana peels, I would be tracking (a) invitations to non-members to become "assignees" sent/responded/unresponded on banana peels, and also (b) issues assigned to non-bemebers who blocked the invitation with your battery of checkboxes. Look, you just stabbed the whole idea in the heart.

As I understood @clarkbw's idea, I would be able to assign the issue the guy who said "Ok, I'm taking it" so I do not lose track of the ticket. If the guy never said anything in my repo, I won't be able to assign the issue (nor do I want to).

Besides, I would call someone who first posts a message "ok, I'll do that" and then cuts all communication not an “extraordinarily privacy-conscious user”, but rather “a windbag.” I do not think we need a special checkbox for this.

[TPS]

Well, @kkm000 & @clarkbw, IMHO, you can't have absolutely both @ the same time: either this will be convenient (for assigners) or protecting from abuse (for assignees). I'd advise defaulting those suggested settings above as y'all mentioned for assigner's convenience, but notifying assigners immediately upon assignment if the assignee's preferences prevent such (since I expect most folks to leave defaults mostly as-is). (N.B.: I added an additional toggle to the above settings mockup for those who'd like willy-nilly assignment! 🤷🏾‍♂️)

Besides, @kkm000, assigning an issue shouldn't prevent an assignee unassigning themselves, nor does it ensure that they'll actually accomplish the assignment! Any which way, the assigner still has the responsibility to check on progress, even if they're not actually expecting to do whatever themselves!

[mekarpeles]

Been hoping for this for months: 1) request to be assigned to an issue (without having read / write access) 2) ability to assign someone to an issue (or at least invite assignment w/o them having read / write access)

We're looking into this. Being able to assign anyone randomly is an abuse vector because I can create an issue with an abusive title and assign a person to it to harass them.

I don't buy it. Such abuse can and likely does happen anyway as one can tag anyone in such issues as described. People who abuse the system should be labeled as abusers and this shouldn't be a limiter on effective user experience for the "rest of us".

To prevent this we're likely to require that a person has interacted with repository in some fashion via commits or commenting in an issue; a low enough bar that limits abuse.

This doesn't prevent any attack vectors. The reason a person is getting assigned to a task is presumably an admin on the project is vouching for the user (unless the user is attempting to assign themselves, which perhaps would require approval).

I think the egregious case is where a user doesn't want to be associated with a project or an issue, in which case there should be a separate feature for a patron to block a project or an account and sidestep this problem completely. Again, this doesn't seem very different from if a user were to be tagged in a comment (rather than assigned). e.g. Facebook allows a user to "untag" themselves from a post. It would be absurd for Facebook to prevent tagging (unless perhaps a user had configured such a setting). These two use cases (perceived abuse vectors, project management affordances) shouldn't be conflated together -- both problems should be solved independently and not to each other's exclusion. Security not at the expense of making it easy for new patrons to meaningfully contribute and feel welcomed in a community.

Idea: Why not pending Assignees? Show "User Assigned [pending]".

Right now one can work around this by creating Assigned-to: @person labels which ~feels like~ is a complete hack.

[alallier]

GitHub now allows you to assign issues to issue commenters

[scottcwilson]

It would be great if we could go just a bit further and be allowed to assign issues to anyone who has contributed to the project. Right now it's three steps (ask them to comment, they comment, you assign); would be better if it was one step.

[mistercrunch]

Looks like giving the Read role allows assigning issues to them.

source

Not the ideal solution in all cases, but it may work for some of the people who commented here.

[TPS]

@mistercrunch Sadly, this seems available only among members of the same org, so no cross-/non-org assignment via this read permission. It'd be great to have this ability expanded globally!