Add some scope (aka: stake your claim!)

[williamkapke]

The TSC went through a long process of deciding what its scope is. I'd post reference links here... but it spanned so many issues & PRs- it's too much to follow.

This was the final solution: https://github.com/nodejs/TSC/pull/144/files

In it, we decided it was appropriate to define what repo's were within the TSC's domain. There are a few in there that may belong to the CC, so take a look and lets discuss.

Here are the ones I have my eye on:
https://github.com/nodejs/code-and-learn
https://github.com/nodejs/education
https://github.com/nodejs/help
https://github.com/nodejs/summit
https://github.com/nodejs/evangelism (whether to move Evangelism under CC is a new topic)
https://github.com/nodejs/inclusivity (def lots to discuss on this still)
https://github.com/nodejs/inclusivity-slack-inviter
https://github.com/nodejs/live.nodejs.org
https://github.com/nodejs/moderation (private.. well except to >500 people in the org)
https://github.com/nodejs/members

Obviously, https://github.com/nodejs/community-committee should be.

Having "under the CC's scope" doesn't mean the CC needs to do much. It's just the body of people that things could bubble up to if needed. For instance, if help was under CC.. the CC would get pinged when someone wants/needs people added to the help team. Or, sometimes a README needs to be updated and no one has commit access to the repo-- this would delegate it to the CC to go hit the Merge button.

I don't believe I'm 100% correct on this list... it's just some suggestions.

[nebrius]

Thanks for putting the list together @williamkapke, I think this is a great step to take! I think we should go through each one, and have a discussion with the appropriate stakeholders, usually the TSC, to get a smooth transition to existing under the CC (if the stakeholders so choose to do so).

• https://github.com/nodejs/code-and-learn: TSC
• https://github.com/nodejs/education: TSC
• https://github.com/nodejs/help: TSC, with administration delegated to Evangelism WG
• https://github.com/nodejs/summit: TSC. I'm a little more on the fence about this one coming under the CC, as it tends to be focused on the direction of core. That said, maybe we should have two, one for the TSC, one for the CC?
• https://github.com/nodejs/evangelism: TSC, with administration delegated to Evangelism WG
• https://github.com/nodejs/inclusivity: My understanding is this is already under the CC, is that correct? It's not under the TSC anymore.
• https://github.com/nodejs/inclusivity-slack-inviter: Delegated to the Inclusivity WG, although I suspect this repo is now obsolete. It's definitely buggy and usually not working correctly, and is also impacted by Central communication medium for chatting in Node.js #11
• https://github.com/nodejs/live.nodejs.org: It's not immediately obvious to me who owns this, but given that @ashleygwilliams ran it before, I'd guess it's under the board directly?
• https://github.com/nodejs/moderation: TSC, and this one will be a can of worms. I can see valid arguments that this should remain under the TSC.
• https://github.com/nodejs/members: unclear. It's not under the TSC, so maybe the board?

This does raise a bit of a procedural question: can a group be under both the TSC and CC? I would guess not, but if it does, how would that work and what would it look like?

Obviously, https://github.com/nodejs/community-committee should be.

Funny enough, the TSC repo isn't listed as under the scope of the TSC explicitly. Perhaps it's implicit?

[Fishrock123]

https://github.com/nodejs/summit

This is for collaborator summits IIRC. We could use it for both but it may be easier to have separated repos for a community-oriented one.

https://github.com/nodejs/inclusivity

My understanding is that this group does not currently exist. Anyone could re-form it as they see fit.

https://github.com/nodejs/member.
https://github.com/nodejs/live.nodejs.org

Board, I guess.

[nebrius]

My understanding is that this group does not currently exist. Anyone could re-form it as they see fit.

I don't think there's a definitive answer to this question right now. I have opinions, but even I don't have an actual answer to "what is the state of the Inclusivity WG?"

[williamkapke]

Reading through the proposed charter- I guess the vision/scope for the Community Committee isn't crystal clear to me yet. I, personally, hope to see the Community Committee include our "community" here within the foundation too. So, things like summit, help, evangelism, membership are all non-Code and Docs things we participate in.

My fear is that if we DO NOT include our internal (for the lack of a better word) community- we're heading towards a world where the TSC and the CC have conversations with the terms us and them. I'm very firm on there just being us. NOTE: The current list of CC members looks a lot like a list I'd see under the TSC.

I see the CC as a separation of skill sets (or interests) rather than a separation of Communities.

So, when I reviewed the list of repos-- I made my assessment based on whether the repo was for "Code and/or Docs" related things of Node Core (or adjacent projects).

[nebrius]

I see the CC as a separation of skill sets (or interests) rather than a separation of Communities.

I want to challenge this a little bit. I think this is a useful view, but I do think it's a bit limiting. The TSC has a very specific and limited scope, and is, for lack of a better term, internal only. This committee, however, has a strong external focus in addition to an internal one, so the TSC and CC are partially disparate communities by design. We want, e.g. NodeBots and NodeSchool to be a part of the CC, but they won't be a part of the TSC because the TSC's scope prevents it (rightly so IMO).

To me, moving evangelism and membership in here is uncontroversial, help is somewhere in the middle (I view it as an interactive extension of docs, but arguments can be made either way). I'm wary of moving summit though because it's purpose is explicitly to facilitate the TSC's operations and scope. I think moving it here would, if nothing else, add some unnecessary process headaches since everything would ultimately have to pass through the TSC anyways (e.g. travel funding requests).

I'm very firm on there just being us

I would like this to happen too, but it is tricky. I don't think we currently have an us between the TSC and marketing, legal, or finance committees either. The us that is the CC and TSC needs to include them too IMO, and, at the same time, there is a certain amount of autonomy between them that's important not to sweep under the rug in the process. I don't really have an answer to this, just reflecting on the divisions between the different committees currently.

[williamkapke]

My understanding is that [Inclusivity] does not currently exist.

There are 2 ways for the group to officially cease to exist: 1) Vote by TSC 2) Vote by the Inclusivity members. Neither has happened.

There was a request to migrate the group (by @nebrius)... which the board agreed to investigate. The investigation yielded a Community Committee proposal that includes a new home for Inclusivity... which is still in-progress.

Soooo, the documented answer: Yes. It still exists... under the TSC. However, the group, informally, decided to pause while waiting for governance changes. I would prefer to have the Inclusivity members vote to dissolve rather than have the TSC vote to do it... but I'm not sure if there would be enough responses to pass the vote. I guess I'd like to see that scenario first before asking the TSC to do it.

[nebrius]

I think we'll probably have to have the TSC decharter the Inclusivity WG, since many of those members are not otherwise involved in the Node project, and wrangling votes could take a while. That said, I want to make sure we have a plan in place for the future Inclusivity WG under the CC before we take action with the current Inclusivity WG.

[Trott]

@williamkapke wrote:

I would prefer to have the Inclusivity members vote to dissolve rather than have the TSC vote to do it..

@nebrius subsequently wrote:

I think we'll probably have to have the TSC decharter the Inclusivity WG, since many of those members are not otherwise involved in the Node project, and wrangling votes could take a while.

If https://github.com/nodejs/inclusivity is to be believed, there are 8 members of the WG at this time. It would take 5 votes to dissolve it. In this thread, we have @nebrius and me already. Getting votes from @hackygolucky and @thefourtheye seems do-able. That would mean just one more person. I think it can be done.

@nebrius also wrote:

That said, I want to make sure we have a plan in place for the future Inclusivity WG under the CC before we take action with the current Inclusivity WG.

That, on the other hand, I don't have an answer for.

[rachelnicole]

hey everyone, i'm chiming in to say i'd like to start helping out if anymore help is needed. i already told @hackygolucky & @ashleygwilliams but i figured i'd pop in here and say that as well.

I'm still trying to go through and read a lot of issues & threads so I have a lot to go through -_-

[nebrius]

Yay @rachelnicole! More help is always needed, especially at this formative stage.

I feel that right now the biggest thing we need is voices. There's not a lot of work to do in terms of creating PRs and issues, but we need lots of input on what's here so we can really figure out our scope/focus/just what in the heck we're actually going to do.

[hackygolucky]

@Trott @williamkapke @nebrius In terms of the Inclusivity WG activity, the conclusion we came to(as far as I recall) at Collaboration Summit was to pause doing anything to it until we formed the CC. As the current Inclusivity WG repo exists, it will be archived. Those who were present in this Collaboration Summit meeting did not wish to hold onto the history of the past repository, but also did not want to jeopardize the creation of the CC by munging it with a concurrent move of the Inclusivity WG. We will surely need help from the TSC to understand how this works, as the folks who were in the Inclusivity WG meeting then were not past members but new people wanting to become active. We didn't want to walk through adding all of them to the repository that was going to be archived because it didn't make sense to us at the time to do so.

Again, this may be that we weren't understanding the process as it currently exists to do something like this, as we were talking about an as un-yet chartered new org(the CC) to transfer to.

[ashleygwilliams]

what's the action item to close this issue? happy to help move it forward. a lot of the convo here is about the inclusivity working group now, but i imagine this issue has more scope (is literally about scope!).

would the artifact end up in the charter? i feel like it should probably be (at least partially) a second document given the length of the charter. thoughts?

[nebrius]

what's the action item to close this issue? happy to help move it forward. a lot of the convo here is about the inclusivity working group now, but i imagine this issue has more scope (is literally about scope!).

Great question! I think there are three action items:

1. For all WGs/teams listed above except Inclusivity our action item is to reach out to them and see if they want to switch to the CC once it's ratified. This would be in the form of a GitHub issue filed in the appropriate repo.

2. For the Inclusivity WG, we need to decharter the WG from the TSC, and the recharter it here.

3. This ties into below, I think the third thing is to codify our scope.

would the artifact end up in the charter? i feel like it should probably be (at least partially) a second document given the length of the charter. thoughts?

The TSC has a scope section in its README that details what its scope is, and we should look to it for inspiration and have a CC Scope section of our README.

[rachelnicole]

I'm interested in:

https://github.com/nodejs/code-and-learn
https://github.com/nodejs/education
https://github.com/nodejs/evangelism
https://github.com/nodejs/inclusivity

[mikeal]

https://github.com/nodejs/code-and-learn

The confusingly named "Code and Learn" is actually specific to educating and onboarding people to be Node.js Core contributors. It has a direct relationship with people tagging issues in core and improving the education and onboarding docs for Core so it should probably remain under Core. It may need grow into a bigger WG but I wouldn't recommend breaking it off from Core.

[williamkapke]

We did get a chance to discuss this in our meeting.

One thing I pointed out is that everything that CommComm does can have a line drawn to Node Core. So how do we categorize things?

MY line is drawn based on whether the repo/team's purpose is targeted towards general community activity (which code-and-learn is). All other repos are used to collaborate on the direct technical production of an asset or governance.

Also, we emphasized that groups that make the list only get invited to join CommComm. It is up to them to decide if it is something they want to do.

[mikeal]

Sorting things into a topic hierarchy misses some of the importance of collaboration and skill development we need to support with these groups.

My criteria would be "is the next logical step for contributors in this space to take on more responsibility in the community committee or the core project."

For instance, NG is a discussion repo about core, but the members of that repo are discussion moderators that could naturally level up into CommComm. github-bot is for managing the org, which falls under CTC, but the contributors there may have a more logical path to CommComm than core since they do workflow automation.

For Code and Learn it's a bit tricky. The effort is targeted at outreach, which is CommComm, but the organizational work happening in the repo is about improving the process of learning and contributing to Core. We definitely want to see anyone who grows in that project and makes a big impact to find their way onto the CTC.

Another thing to keep in mind is that the project is in a constant need of additional leadership. The growth of overall contributors means that more people are needed to lead efforts and maintain the structural integrity of the project. If we push everyone that is good at broader community work into CommComm we'll end up with a deficiency across the rest of the project leadership. This isn't an immediate concern at all because we've mostly recruited people to participate in CommComm from the broader ecosystem but it could become an issue if we start to funnel anyone with an aptitude for community organizing away from Core.

[williamkapke]

You opinion seems skewed towards categorizing people- which I'm not willing to get onboard with. I think we should focus on segmenting topics and promote people working on many different disciplines that fit their interests.

CommComm people will most likely be the same people as CTC people- I hope we do not cause a CTC === elite or CommComm < CTC view in the Foundation.

[nebrius]

Is there anything we need to discuss in the next CommComm meeting regarding this issue? Or can I remove the cc-agenda label?

[williamkapke]

removed 👍

This issue will probably just stay open for a while and be referenced from time to time.

[nebrius]

FYI: nodejs/evangelism#294

[rachelnicole]

@bnb we need to revisit this / this might be something good to add to the README for whatever things are under our jurisdiction

[bnb]

@rachelnicole Agreed. I know there are several projects that we share collaboratively with the TSC. Admin, Getting Started, Help, Education, and Summit could all be added today in that capacity. I know there are ongoing discussions around Code and Learn and its scope that may need to resolve first.

[bnb]

I'm going to remove the cc-agenda label - it looks like we've got some forward moving progress in #167, and are generally aware of what needs to be done.

Additionally, I think we can close this issue out - older issue that's served its original purpose. If we want to discuss the topic more, creating a new issue with more up to date context is probably going to be a more effective path for us. Please, don't hesitate to do so! 👍