Runtime: Announcement: Removal of read-collaborator access

[terrajobst]

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.

| Public Repo | #collaborators with read |
|----------------------------|---------------------------|
| arcade | 1 |
| BenchmarkDotNet | 11 |
| cli | 2 |
| command-line-api | 14 |
| coreclr | 18 |
| corefx | 180 |
| corefxlab | 4 |
| corert | 7 |
| core-sdk | 1 |
| docs | 3 |
| interactive-window | 1 |
| machinelearning | 1 |
| machinelearning-samples | 1 |
| msbuild-language-service | 1 |
| runtime | 128 |
| spark | 5 |
| standard | 1 |
| windowsdesktop | 1 |
| winforms-datavisualization | 1 |
| Grand Total | 381 |

[vcsjones]

This is an understandable change, but on the topic of CI, being unable to interact with AzDO is a bit troublesome. I have no preference what the solution is, but being able to 1. restart failed builds and 2. start outerloop was something I regularly used. Many of the S.S.Cryptography tests are outerloop, which is where the bulk of my contributions have gone. Running outerloop tests locally is doable but hard to do for all platforms. S.S.Cryptography tends to have a lot of diverging behavior by platform.

[MarcoRossignoli]

CI command privileges are also useful to save ms team members time(avoid "run my ci pls" ping) in case of tmp CI issues and speed up merge time.

[4creators]

I do second @vcsjones remarks. Essentially it would be impossible for me to work on Hardware Intrinsics without access to CI commands. All significant tests are outerloop with special environment configurations which are unaccessible from standard PR hooks. With CI health far from perfect almost all the time it is usually necessary to restart different tests multiple times. Counting on fellow developers to help is major pain point as they are usually very busy with their own work. IMHO there has to be some solution to allow interaction with CI or large areas of the code base will become off-limits to the community.

[qmfrederik]

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.

It is indeed a bit odd you don't desire PR authors to be able to trigger CI commands for their own PRs. What's the rationale for allowing internal contributors to trigger CI reruns, but not external contributors?

If a particular CI leg fails, options now are dummy commits (here's to dummy commit to trigger CI), or nagging team members?

[terrajobst]

@vcsjones Thanks for your feedback! We have decided to give folks like you access to the CI system on a case by case basis. I'll add @vcsjones @marcelaldecoa @4creators and @qmfrederik.

It is indeed a bit odd you don't _desire_ PR authors to be able to trigger CI commands for their own PRs. What's the rationale for allowing internal contributors to trigger CI reruns, but not external contributors?

In general, we don't desire anyone to trigger reruns and instead fix the flakiness of the system. I'm joking (but only a bit). The primary reason is that we only have the option to make it publicly accessible or grant access case-by-case. Public is bad because it can be misused/overused and CI runs aren't exactly cheap (in aggregate).

[MarcoRossignoli]

I'm not able to run CI yet I get access error Commenter does not have sufficient privileges for PR 1052 in repo dotnet/runtime, @vcsjones @qmfrederik does it work for you?

[vcsjones]

No.