Adding folks as members about community-committee

[williamkapke]

I also think that being a member shouldn't really make much of a difference.

Not a major objection here- BUT at the same time- we should recognize that membership to ANY committee/working group/team:

• Gives a feeling of ownership & belonging
• Motivates people to get and STAY involved
• Is a way of showing recognition and appreciation for volunteers time
• ... even bragging rights. (resume material)

While we can certainly see the dark side of that last one, it's why the participation rules were so important... and well, if the Community is actually benefitting- then it's net positive.

[mhdawson]

My 2 cents is that we should look to enable anybody who is active and regularly contributing to become a member. I think the problem of having "too many" active contributors seems like a good place to be :).

If numbers become a problem then maybe the model in core where there are different kinds of members could be used (collaborators, CTC, and TSC members). My guess though is that it would not be a problem in the foreseeable future.

Agreeing with @williamkapke, key to making this approach work are the participation rules.

[bnb]

I'd happily be a guinea pig for this process 😁 (does that count as self-nomination?)

Not necessarily sure if a private forum would be an easy thing to implement and work into a simple GitHub workflow. I think two things that may be nice:

• Encouraging current members to actively Invite/onboard new members. I know as a part of the Website/Evangelism onboarding I was never quite sure about the definitions of merit.
• I think a good way to ensure there's a level of quality (new members will contribute and are engaged) and maintainability (not having a limbo of process around membership) is, as you mentioned, an observation period. This way they can be off-boarded if they lose interest after
  a few days or weeks (which happened a lot in the Evangelism WG).

[bnb]

@nebrius I think the history subject is important - don't require history, but have an on-boarding process that enables context, understanding, and history to be gained via experience and tangible interaction.

Tangible code contributions is what Open-Open Source hints at, but the concept in the intro paragraph is super solid. We did apply this to the Evangelism WG. Purely discussion, action, and engagement based, and there were always people that were interested and engaged - even in times of otherwise seeming inactivity (@JungMinu, @vdeturckheim).

I don't see a huge barrier with having an on boarding process if it's friendly, welcoming, and open - by no means should it scare people off, but simply inviting to engage and join would be key. Nominate those who current members think have merited membership, and have a process for those interested in membership to become engaged and participate in the project.

[nebrius]

Yep, totally agree w.r.t. onboarding and making that context easy to understand.

It should be easy to become a member, but I also think that being a member shouldn't really make much of a difference. Ideally we won't need to vote on much, and ideally voting would be the only real privilege to being a member. My ideal vision for this group, and other Node.js groups, is that becoming a member simply means you're willing to tackle a bit of paperwork but are otherwise just like observers :)

adding to what we discussed in today's meeting (and we forgot to talk about) - should we define an independent process while we're still in our early stages? should it be easier to become a member during the times where we're actively looking for them to build our initial lineup?

[nebrius]

I'd really like to find a good solution to this. Some thoughts/reflections on how we handled this in the old inclusivity WG.

In the Inclusivity WG, we realized we couldn't follow the open open source policies that a lot of the Node project uses because we didn't have code. We ended up creating a self-nomination process and membership policy, which has since been deleted.

There were some good things about this approach we may want to borrow from, but we did see one issue: people would usually apply to become a member without any prior history in the Node.js project (including within the Inclusivity WG). My suspicion is that people thought they had to become members before they could participate, although I don't have any evidence to back this up. Either way, we'll probably have to deal with this again if we go with a self-nomination process.

[nebrius]

adding to what we discussed in today's meeting (and we forgot to talk about) - should we define an independent process while we're still in our early stages? should it be easier to become a member during the times where we're actively looking for them to build our initial lineup?

I lean towards no, myself. We already have a lot of members, and the charter specifies (and I agree with), that the target size is 6-12 people. We might even be bigger than the TSC, even though the TSC oversees a lot more.

That said, I think the real thing we should be asking ourselves is why are we trying to add a lot of members, specifically? Does this indicate a flaw in our process where people can't contribute if they're not a member? Are we giving off the perception that you can't contribute if you're not a member?

Members really shouldn't be anything special, the only thing members should be able to do that observers can't is vote, and we shouldn't be voting much at all to begin with. If people need to become members to contribute, then I think that indicates a flaw in how we've structured things and we should be addressing that problem instead.

[nebrius]

Re-reading my comment, I realize I maybe didn't make this explicit. The answer to the two questions I asked are probably "yes," and I'd love for people who are watching this repo and aren't members to weigh in on this with the barriers to entry you've noticed with CommComm. I think I can safely speak for everyone when I say we want to fix this and make things better! What do you think?

@nebrius i get what you mean and i agree with it wholeheartedly - anyone should be able to contribute to commcomm without having to go through a long process. in that case, i believe that fact should be more clearly outlined in the readme or anywhere else where it could become a question. like, there should be a general explanation that you don't need to be a member to contribute in the README.md's Governance and current Members section, because the GOVERNANCE.md file can be quite hard to skim through. something like:

## Governance and current Members

The Community Committee is an autonomous committee that collaborates alongside the TSC 
and whose governance is strongly influenced by the TSC's example. Members of this committee
are not granted any special status other than being able to vote on issues concerning this group. 
Contributions can come from any person without having to be a member.

See GOVERNANCE.md to learn more about the group's evolving structure and 
CONTRIBUTING.md for guidance about the expectations for all contributors to this project.

also, there should be more information about how to contribute other than just

Please contribute! The best way to do that right now is watching this repo, participating in the 
issues, and asking questions in TSC meetings as they help to advise the formation of this 
autonomous committee.

ideally, i'd love for there to be an exhaustive list of things you could do and the ways in which you can do them. not everyone knows how to join a tsc meeting

[nebrius]

also, there should be more information about how to contribute other than just

Agreed. Sounds like a good PR for someone to make hint hint. ;-)

ideally, i'd love for there to be an exhaustive list of things you could do and the ways in which you can do them. not everyone knows how to join a tsc meeting

🤔

I'm wary of creating an exhaustive list, they tend to end up being prescriptive and can imply "if you want to do something that's not one of these, tough luck," which is absolutely not what we want. (also, I don't think anyone knows what that list is)

That said, leaving little to no direction and can also discourage people from contributing due to indecision paralysis.

¯_(ツ)_/¯

I'm wary of creating an exhaustive list, they tend to end up being prescriptive and can imply "if you want to do something that's not one of these, tough luck,"

oh yeah, now that you mention it, i agree. maybe settle for something inbetween the two extremes?

[nebrius]

oh yeah, now that you mention it, i agree. maybe settle for something inbetween the two extremes?

Something yeah. I don't really know what that is yet though (I doubt anyone does, we're new after all!). I'm all for iterative improvement. Make tweaks, see how they work out, make more tweaks.

[flickz]

@williamkapke Totally agree with you

[nebrius]

🤔 good points

[hackygolucky]

@nebrius @bnb was this ever PRed in any way to our documentation?

[nebrius]

@nebrius @bnb was this ever PRed in any way to our documentation?

AFAIK we have not

[bnb]

I believe we did merge this in #101 - going to close for now. Please feel free to re-open or create a new issue if we need to discuss further ❤️