TL;DR: We’ll remove collaborators with read-only access from our public repos on December 16th. This means some folks will lose their Collaborator badge and the ability to interact with the CI system.
Over the years, we’ve added a bunch of folks as collaborators with read permissions to our public repos. The rationale was that we wanted to be able to assign issues to community members because GitHub only allowed assigning issues to users with an explicit permission grant for the repository. However, they changed this in June 2019. Now, we can assign issues to all users with explicit permissions as well as to users that have commented on the specific issue.
Also, we recently started to audit and tighten the permissions for our organizations. As a result, it became clear that large number of repo-specific permission grants are hard to review and audit. Internally, our goal is to grant all permissions via teams instead.
Hence, we plan to remove all collaborators from public repos that only have read permissions (folks with triage permissions will remain). The full list of affected repos is listed below.
This shouldn’t impact your ability to work with us, but losing explicit read-only has the following implications:
You’ll lose the collaborator badge. We understand that this is visually appealing and for some people it might have been a badge of honor. But given that GitHub also shows a Contributor bade for folks whose PRs got merged, we don’t think it this will be a major take back.
You lose the ability to interact with the CI system. As a collaborator, you can use comments to send commands to the CI system. While this can be useful at times, we generally don’t expect (or desire) contributors to do that. Of course, anyone can still access the CI logs.
You might lose the ability to interact with the CI system. Based on your feedback we have decided to give externals access to interact with the CI system on a case by case basis. If you believe you need to have that ability, please leave a comment like Kevin's.
TL;DR: We’ll remove collaborators with read-only access from our public repos on December 16th. This means some folks will lose their Collaborator badge and the ability to interact with the CI system.
Over the years, we’ve added a bunch of folks as collaborators with read permissions to our public repos. The rationale was that we wanted to be able to assign issues to community members because GitHub only allowed assigning issues to users with an explicit permission grant for the repository. However, they changed this in June 2019. Now, we can assign issues to all users with explicit permissions as well as to users that have commented on the specific issue.
Also, we recently started to audit and tighten the permissions for our organizations. As a result, it became clear that large number of repo-specific permission grants are hard to review and audit. Internally, our goal is to grant all permissions via teams instead.
Hence, we plan to remove all collaborators from public repos that only have read permissions (folks with triage permissions will remain). The full list of affected repos is listed below.
This shouldn’t impact your ability to work with us, but losing explicit read-only has the following implications:
You’ll lose the collaborator badge. We understand that this is visually appealing and for some people it might have been a badge of honor. But given that GitHub also shows a Contributor bade for folks whose PRs got merged, we don’t think it this will be a major take back.
You lose the ability to interact with the CI system. As a collaborator, you can use comments to send commands to the CI system. While this can be useful at times, we generally don’t expect (or desire) contributors to do that. Of course, anyone can still access the CI logs.You might lose the ability to interact with the CI system. Based on your feedback we have decided to give externals access to interact with the CI system on a case by case basis. If you believe you need to have that ability, please leave a comment like Kevin's.
Discussion
To discuss this, please comment on the corresponding issue at https://github.com/dotnet/runtime/issues/718.