Description
Current Problem
Permissions are currently set up in such a way that you assign a TEAM one of either Read, Write or Administer and then select the sections that permission applies to. The problem with this system is that you can only have one permission choice per team. This means that if I want to give someone read access to certain sections and write access to others, I have to add them to two teams. This is not only inefficient but can also reduce workflow compatibility.
Case Study (Using current system)
Alice is writing a project that depends on Bob's API. For security reasons, the repository is private. Bob wants Alice (and other users of the API) to have read access to the source code, PRs and releases however Bob also wants everyone to be able to read and write issues. To accomplish this, Bob must create two teams - A "Read" team and a "Write" team, and assign users to both teams.
This results in confusion as issues/PRs cannot easily utilise teams at this point due to a large number of teams being formed. In addition, Additionally, it can result in a headache for administrators due to the fact that multiple teams may exist which need different abilities on a single repository or organisation, which means there would be a significant number of teams created.
Proposed Solution
My proposal is to create a different system, such that a team has a grid-style permissions layout. I mocked up an example in Google Forms, and enclose it here for you all to review.
Case Study (Using proposed system)
Alice is writing a project that depends on Bob's API. For security reasons, the repository is private. Bob wants Alice (and other users of the API) to have read access to the source code, PRs and releases however Bob also wants everyone to be able to read and write issues. To accomplish this, Bob creates a team called "APIUsers" or similar and assigns the appropriate checkboxes on the grid. Bob then assigns Alice and all other users of the API to the "APIUsers" team.