Defining the Scope of a Core Collaborator

[devsnek]

(continuation of nodejs/discussions/collaborators#18)

while discussing the nomination of someone to be a core collaborator the topic came up of what the scope of that role means in the org and what defines a good candidate.

Currently we nominate based on code contributions to the project but people wiggle by for other reasons which is fantastic, but awkward while trying to nominate. I think a lot of people feel nervous about nominating someone in general, much less nominating someone who hasn't contributed code, while that person may still be of huge benefit to the community.

The second issue that got brought up was about the permissions granted to a collab when they aren't the kind who contributes code. A commit queue was brought up as one solution and while that might not become the thing we settle on it would probably be necessary to add some sort of automation.

@nodejs/collaborators

[joyeecheung]

One potential workaround for the lack of finer commit access control in the GitHub permission model: if we implement the subteam idea proposed in #20367 , then collaborators who don't need commit access for the time being will not have it. This partly removes the connection between the collaborator status and the active commit bit. In my opinion the collaborator status is more about trust: we trust that the individual will make good use of the commit bit when necessary (that is, when they inform the admins that they need it, if their commit bit already expires because it's not been exercised in a certain amount of time).

With this an inactive collaborator will still be listed in the README and receives notifications to the collaborators team. The difference (other than the commit bit and the CI access) is that their reviews will not be colored and they cannot edit issues/PRs, but they can get those back when they inform the admins (a post in the team discussion page will do). If they don't use it after certain amount of time, the permissions will expire again.