Accepting new members

[NeroReflex]

I think there is a need to outline the process of getting new members accepted: as of now my understanding is that a handful of people from each project is allowed in the OGC as members in github, but asus-linux has a developer that is active in cardwire instead of general asus-linux things, so I think it's good to have a process to understand how to get him on the org as a separate party instead of part of asus-linux.

[pastaq]

What do you propose as a solution?

[Ghoul4500]

What do you propose as a solution?

I have a bit of a vague direction to take this but I would like more input from others to properly solidify this plan

A members.yaml file is created in this repository with a separate "Independent" section for small projects that can't fully be considered part of any one particular major org.

On request to enter, a PR must be sent to edit the members.yaml file with adding their name in, with a predefined User Onboarding template. The tamplate should include things like "What I have contributed" and then we will have internal reviews on it, debating whether the user meets our expected standards or not.

We should still define a few paths for different cases. So a user who registers under a specific org can only require approval from that org's members and owners (say owner approval is immediately in while members can vote), while an independent project must require approval from at least 2 org owners. This can be done through PR approval flow. In the case that any org owner or member is against a certain user entering, they can discuss so privately amongst other members, and we can consider tying this with #24 in the case any member has a valid reason for rejecting someone. Then a voting can be held between owners. If nobody objects and the required number of approvals are received, we can admit them into OGC.

We should avoid lazy consensus the same way as announcements in this particular case. However, with approvals, we should hold a grace period during which any member can raise an objection against a particular applicant in which case the earlier mentioned scenario occurs.

Additionally, I think this is a good time for us to start making the Github Teams in this org properly so we have members properly defined for each team for access control. This needs to be done before the onboarding flow is established to ensure a malicious actor who gets in doesn't immediately get access to everything and we can this way also implement a probation period of sorts

[pastaq]

that seems reasonable. I'd like someone to take on that task, but they will need elevated status in the org to do it.