Move OSPS-AC-02 to level 3 based on level criteria

[evankanderson]

OSPS-AC-02 states:

The project's version control system MUST restrict collaborator permissions to the lowest available privileges by default

Our maturity levels are defined as:

• Level 1: for any code or non-code project with any number of maintainers or users
• Level 2: for any code project that has at least 2 maintainers and a small number of consistent users
• Level 3: for any code project that has a large number of consistent users

Given that Level 1 projects may be single-maintainer (at which the collaborator permissions are "admin everywhere"), it seems this should be at least level 2. For code projects with a small number of maintainers and users (for example, 2 maintainers), I'd argue that "both maintainers are admins" is also fine. For projects with a large number of maintainers (probably at least 5), restricting permissions seems more reasonable.

[funnelfiasco]

I understand your reasoning, but I disagree. The examples you gave not violate the criterion. But if I come along as a new person who hasn't interacted with your project, I should have limited permissions, even if you're at level 1.

The better criticism of this criterion is that every VCS that I'm aware of does this already: newcomers can (unless the admins have configured otherwise) clone, create issues, submit pull requests, etc, but cannot write to the repo. It's a "no duh" kind of criterion, but worth keeping in because there exists a theoretical VCS that is globally writable by default.

[evankanderson]

According to our lexicon, a collaborator is not "a new person who hasn't interacted with your project":

Collaborator

A user with a role on the project's version control system who can approve changes or manage the repository settings. Collaborators may have varying permission levels based on their role in the project. This does not include contributors whose changes only originate through a request from a repository fork.

[funnelfiasco]

Good catch on the lexicon. I'd still argue that there's no reason to change this from level 1, though. Level 1 projects may be single maintainers, but don't have to be. A project that's primarily "content" (docs, art, etc) could reasonably stay at level 1 regardless of size. We'd still want this criterion to apply at that level.

[evankanderson]

I'm struggling to figure out how to quantify compliance with this criteria at the single-maintainer level. Do you have a suggested way to determine whether a project has met this criteria?

[evankanderson]

(For a project with >5 collaborators, I'd be willing to ask the question "does there exist a collaborator with less than maximum permissions")

[funnelfiasco]

(I feel like I'm moving goalposts here a bit, but that's only because I was half-way looking at it earlier 😅 )

I don't have a good way to programmatically evaluate it, other than "is it running on a service that does this?" As the criterion is written, it doesn't matter what any individual's privileges are, only that when a new one is added, they get the lowest level by default. The size of the project is irrelevant.

That said, what you're getting at probably ought to be an additional criterion about having collaborator permissions set to the lowest appropriate level, but this is about the system default. We currently don't have anything about that, or about lowering/depriviliging inactive collaborators (which we probably should). I could definitely see that as at least a level 2, maybe a 3.

[evankanderson]

That said, what you're getting at probably ought to be an additional criterion about having collaborator permissions set to the lowest appropriate level, but this is about the system default. We currently don't have anything about that, or about lowering/depriviliging inactive collaborators (which we probably should). I could definitely see that as at least a level 2, maybe a 3.

I see where you're coming from, but I'm trying to apply this to the common case of using hosted software like GItHub, and every time you add a collaborator, you have to explicitly indicate what permissions they have. Maybe that means that public GitHub / GitLab are implementing this automatically, but it feels like we need something to indicate that this applies to custom custom hosting setups in that case.

---

On somewhat of a tangent (since it's not in the text of the criteria), in a GitHub organization, you can set the access level for organization members, but the lowest level (read) is no different on public repos than the general public, and you may want collaborators (for example) to be able to manage issues (but not approve commits). This actually hard to do on GitHub, in my experience.

---

Finally, this could be suggesting something like a CODEOWNERS file, but that seems like unnecessary duplication for the common case at maturity level 1 (single-maintainer OSS).

[funnelfiasco]

I'm trying to apply this to the common case of using hosted software like GItHub, and every time you add a collaborator, you have to explicitly indicate what permissions they have. Maybe that means that public GitHub / GitLab are implementing this automatically, but it feels like we need something to indicate that this applies to custom custom hosting setups in that case.

You're right that it means hosted services are implementing it automatically. Maybe we add something to the implementation like "Most hosted services are configured in accordance with this criterion"?

[evankanderson]

That would certainly help clarify for me.