Assigning People to Tickets / GitHub Permissions

Hi all,

An issue was brought up by @Zia_Fazal at last retro (Core Contributor Sprint Retro - March 4-18th):

I’m difficulty assign something from BTR board to myself or moving issue assigned to me from in progress to Done. How we can improve these how I can perform these tasks myself?

The reason for this is GitHub access control. You can only assign the following people to GitHub Issues:

  • People who have “write” access to the repository (meaning they can merge code and otherwise change the contents of that repository)
  • People who have previously commented on an issue.

This is a GitHub limitation to prevent spam, abuse, and harassment that could (and has) entailed by making a bunch of obscene issues and assigning them to unsuspecting people.

My position is that we should respect this behavior by GitHub and not grant everyone write access to a repository just so issues can be assigned to them. This can create a situation where it is assumed everyone has write access so newcomers feel left out. It then also puts us in the situation of deciding to add someone to the Core Contributor program just to get write access just so issues can be automatically assigned to them. (Yes, legally you must join the Core Contributor program to gain write access to a repo; no, I do not wish to create a carve out designation for a new type of “write access” user as that quickly becomes difficult to keep track of).

I’m requesting that people wishing to assign someone to a particular issue do the following:

  1. Comment on an issue, Hey @user, do you mind if I assign you to this issue?
  2. They reply affirmatively
  3. Now that they have commented, you can assign them to the issue.

I believe @kmccormick has followed this without issue recently.

People wishing to be assigned to an issue should comment and indicate they wish to pick it up.

I’m willing to say that leads of WGs should likely have write access to their wg repo to help manage this, but we’ll have to determine how that overlaps with the Core Contributor program. At this point I believe the main people in the BTR are all also CCs so it would be reasonable to ask to extend permissions to that repo.



How about we create a bot (or sort of github action), such that when someone (i.e. a trusted community memeber with no write access) comments on an issue like, “@communitybot assign me to this please”, now then bot get tirggerd with the following flow:

  1. A comment by a user lets call them “human_relaxed” containg “@communitybot assing me to this pelase” triggers the bot,
  2. Let’s assume what I called communitybot has access to a list of users who we trust that can be assigend to issues (but are not with right access).
  3. Next the bot check if “human_relaxed” is in the list, if yes, the bot assigen them.

Also we can add more commands, like “@communitybot move this to done please”…etc.
I think it should be fairly simple to implment this and it will give community memembers with no write access some sort of autonomy, in a nutshell or IMHO* it should make life of everyone involve in the process easier.

Okay, as always someone already thought about it Issue Volunteer Assignment · Actions · GitHub Marketplace · GitHub


Hi @sarina

Thanks for looking into it. Yeah that flow you mentioned for assigning someone an issue makes sense. However, what if some one is already assinged an issue but he/she is unable to move it from one stage to another?. i.e moving from “To do” to “In progress”. In my case I got assigned the issue but was not able to move it from “In progrees” to “Awaiting review” column.

@Zia_Fazal good question. Perhaps someone can spend a bit of time to find a GitHub Action as Ghassan did for the assignment (that’s a good idea, thank you).

Note that BTR runs on old-style projects; I anticipate eventually you’ll need to migrate to new-style (“beta”) projects. I know how to write the automation we’d need for beta projects, but not old-style.

@sarina I’ve found that your proposal works for assigning folks who are responsive, but it breaks down when people don’t see and/or ignore notifications on GitHub issues, as they can’t be assigned to the issue until they reply. (Perhaps, though, unresponsiveness is a separate issue that we shouldn’t tangle into this).

no, I do not wish to create a carve out designation for a new type of “write access” user as that quickly becomes difficult to keep track of

What about setting the openedx base role to Triage? Everyone in the organization (including all core contributors) would be able to assign issues, manage labels, etc.

However, what if some one is already assinged an issue but he/she is unable to move it from one stage to another?

I think creators of project boards have the ability to manage access to issue stages (note: stages are associated with the project boards, not with the repository issues themselves). This is true for at least new-style (“Beta”) projects. I would not be opposed to deciding that working group chairs have the prerogative to manage access to their project boards; for example, they would be able to give project write access to everyone in their working group, whether or not they are CCs.

This is what I meant by

GitHub write access is write access regardless of repo purpose. Thus giving everyone in a WG project write access would mean they all, legally, enter the Core Contributor program. And keeping track of what write access people have (do they have “Working Group Write Access” or “Core Contributor Write Access”) is hard to keep track of and scale especially given WG membership in flux and how much bigger WG membership may be over CC program. Re-read my post with that clarified.

Will need to review what permissions that grants and inquire with Legal. But you’d need to be in the openedx org to get the “Triage” status, right? The whole community is not currently in the org. Then we’d need provisions of when to remove those people from the org, too.

On a quick Google I can’t find any blog or article or anything that describes how other Open Source projects handle this issue. I’d love to go “best practice” if possible. Anyone have any ideas?

I’m not suggesting that WG chairs would grant write access to the repositories that hold projects’ issues. I’m suggesting that WG chairs would be able to manage access to their WG’s own organization-level project board. For example, the chair of DEPR WG might allow a some non-CC “Alice” to add issues to the DEPR project board, add metadata, and transition them between DEPR states. Since she wouldn’t necessarily possess triage or write permissions on the issue’s underlying repositories, though, Alice still wouldn’t be able to create issues, manage issue labels, push branches, and change any repository’s settings.

I don’t know where the line of “we need a legally binding agreement in order to grant these permissions” exists. What I’m proposing above assumes that project board permissions are exempt since they don’t grant you any ability to modify repositories.

@kmccormick that makes sense and I’m fine with that. However I believe most WGs are not using beta style org-level project boards. My responses all are specifically addressing BTR, which uses old-style projects at the repo level, and require those permissions.

As you mention, DEPR uses a beta-style org-level project board and yes, if you all have the need go ahead and grant that board-level access to someone.