Document how members join or leave the group

[alexeagle]

Should we have some criteria for who participates?

This could help avoid the "too many cooks" problem of large meetings.
We can also ask more of participants if we ask for some time commitment at the time they join.

What is the process for new member onboarding? What happens when a member is no longer active and we need offboarding?

[cgrindel]

To kickstart the discussion, here is a proposal.

I wonder if an HOA mechanism would work. It sounds like we need the following:

• Board/steering committee - Drive meetings and initiatives
• Voting membership - Elect the Board/steering committee
• Subcommittees - Made up of Board members and/or membership; report back to the Board on their efforts

If we think about it this way, there are a couple of items to consider:

1. Deciding who are members?
2. What are the terms for Board meetings?

Membership

Options:

1. Anyone can apply.
2. Anyone who has participated in the n meetings over the past m months.
3. Hybrid - Anyone can apply, but you would come off of the membership rolls if you have not participated enough (see option 2).

In short, I think that the SIG should be inclusive, but expect participation from its membership.

Board

Size: 5-7 (Treat 7 as an absolute max)

Elections: Annual, unless a vacancy occurs

Thoughts?

[alexeagle]

+1 to the requirement that along with membership should come a commitment to do concrete work for the SIG or for some ruleset (maybe in addition to attending meetings?)

I'd prefer to have the minimum required structure, since no one has much time for organizing. What would it look like if there was just one layer, which is "members", and we use a rough consensus of members to make decisions?

[cgrindel]

When I wrote my post, I was kind of thinking about how Swift is managed. It consists of membership and a core team. The difference from what I was suggesting is that the Board/core team would be elected by the membership. From what I can tell, the Swift core team is appointed.

If we opt to have the membership vote on all decisions, we will need to determine how that will work. You will probably want to require a quorum to keep things fair. To keep it as lenient as possible, let's assume that a quorum will be 50% of the membership plus one member.

How big do we anticipate the membership being? I forget how many folks jumped on the meeting on Friday. At least initially, I suspect that the membership will be somewhere between 70% to 100% of the folks on the video conference. Let's assume that the membership will initially be ~30 people. So, for ratification events, we would need 16 members to vote. This is probably doable especially if we implement an asynchronous voting mechanism (i.e., collect votes online over a certain period of time).

With regard to keeping the structure flat to minimize the overhead of organizing, I don't think that will actually happen. Even with a flat structure, the success of the group will rest upon the shoulders of select folks in the membership who will move things forward. Having a Board/core team merely clarifies who those people are. It helps internal and external folks know the points of contact.

[alexeagle]

Discussing in SIG meeting:
Maybe it's sufficient to allow anyone to observe meetings, and if they come "regularly" and make contributions, they are a de-facto "member". It could only become a problem if we get to a larger scale.

Add to the readme:
To become a member:

• attend some meetings and/or contribute to our projects/repos
• ask to be members of https://github.com/orgs/bazel-contrib/people, by creating an issue
• next SIG meeting, we click the buttons in github to add them as a member of the org, and then determine about them joining the rules-authors team as well to approve PRs - https://github.com/orgs/bazel-contrib/teams/rules-authors/members