search

bazel-contrib / SIG-rules-authors

Governance and admin for the rules authors Special Interest Group
https://bazel-contrib.github.io/SIG-rules-authors/
Apache License 2.0
28 stars 12 forks source link

Document how members join or leave the group #1

Open alexeagle opened 2 years ago

alexeagle commented 2 years ago

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 commented 2 years ago

To kickstart the discussion, here is a proposal.

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

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 commented 2 years ago

+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 commented 2 years ago

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 commented 2 years ago

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: