[bisq-network/roles] GitHub Admin (#16)

[Chris Beams]

## On the recent inability to assign issues to team members

### The problem 
An issue has cropped up several times recently in which I or other people have been unable to assign an issue to a given GitHub user ID. For example, see https://github.com/bisq-network/roles/issues/30#issuecomment-667965511. @wiz discovered that this was happening is because the would-be assignee did not have explicit read access to the repository in question.

### The cause
This was a non-issue until recently when I changed the default repository permissions for the bisq-network GitHub org. When creating the bisq-network/security repository, we wanted to have it be fully private and invite-only, such that only members of the @bisq-network/security team could see and interact with it. The only way to achieve this was to switch the default repository access for organization members from 'read' to 'none'. This worked well for the purpose, but had the side effect of making it impossible to assign issues to anyone that does not have explicit read access to the repository. This is a bummer.

### The 'solution' that doesn't really work
All organization members are (or should be) added to the @bisq-network/dao team via one or more specific sub-teams. This means that technically, we could assign read access to all repositories (except security) to the @bisq-network/dao team, and all members would once again be able to be assigned to any issue in any repository. Unfortunately, we have a lot of repositories, and GitHub's UI doesn't allow for doing this kind of thing in bulk, so, I've taken a 'best efforts' approach for now, see below.

### The current, imperfect solution

For now, I've just assigned the @bisq-network/dao team read access to the ops, proposals and roles repositories, as these are the ones that (IIRC) had issues lately. If any further repositories need the same treatment, just request that your friendly GitHub Admin to do so. It's probably only a small minority of our total set of repositories where this problem will manifest in practice, so this shouldn't be too much hassle over time.

### An idea how to eliminate this problem altogether
Thus far, the security repository hasn't seen much action (there's just one issue open there at present), and it seems like overkill to have to deal with everything I wrote above just to keep that repository private. One alternative would be to create a bisq-security repository outside of the bisq-network organization, and invite the members of the @bisq-network/security team to it individually. That localizes the 'hassle' to the team that needs and cares about the repository, instead of externalizing it on potentially everyone else in the org, as is the status quo.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/roles/issues/16#issuecomment-671527142
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200810/dbcb422b/attachment.html>