We need to create and make public a process for adding new members

[nebrius]

Like all working groups, this working group needs to publish specific processes and guidelines for admitting new members.

So far, we do not have anything in place, and people have been added in a very ad-hoc manner. We've also told people they can't join yet for various reasons. These reasons may be valid, but it's still a problem that this wasn't done through any sort of well structured, transparent process.

We need to fix this, and soon IMO.

[ghost]

are there any diversity/inclusion WG-esque groups from other open-source projects that have a structure for accepting new members? if anyone knows any, we might find some inspiration there.

[mikeal]

For reference, policies across working groups are pretty divergent around this. Here's a few:

• Core
  • Liberal contribution agreement leads to onboarding new "committers" with a CTC that handles disputes
• Website
  • Liberal contribution agreement leads to commit bit and addition to WG, no on-boarding. Most contributions land, disputes handled by the whole WG.
  • "Admin" group is elected subset of the working group. Can land stuff without review.
• HTTP, Streams, and a few others:
  • Anyone who asks is added to the WG
• Most i18n groups
  • Initially anyone who asks is added. Once established people are added to WG after initial contribution or participation in reviews.

The most interesting have been the website and i18n. The 18n groups just organically grew and adopted policies but they are all relatively similar from what I can tell. The website is optimized for getting contributions in quickly without ever having meetings.

[ghost]

@mikeal: what's CTC in this context?

I believe that this WG should have a more thorough 'addition' process, since we can't just accept everyone regardless of their beliefs and ideals. Ideally, it might be something like a form to fill out that's reviewed by all current WG members. Once there are enough votes (not too sure about the voting part, might have to be discussed seperately), the member should be added and given an onboarding of what this WG is about, etc., so basically a rundown of the Charter proposal.

Then again, I'm not too sure, but that looks like one feasible way to do it.

[mikeal]

@sup there may not need to be a "CTC" in this context. What I was trying to do was just give an overview of the range of structures people have put in place to bring people into different groups related to the work they are doing.

The problem we have here is that working groups tend to tailor their admission process based on the work they are doing. Since this group is still figuring out it's scope of work and the things it needs from contributors it will have a difficult time defining this. As you can see, most WGs simply leave admission almost entirely open in their early phases while they figure that out.

[ghost]

@mikeal oh no, I meant what the acronym meant in the context of working groups and everything. Sorry for the confusion.

[mikeal]

@sup oh, haha. CTC == "Core Technical Committee." They are the people who make final decisions around node core code and policies when they are controversial (meaning that anyone objects to the change being made). Most changes to core are un-controversial an land after they are reviewed but a small portion need the CTC to make a final decision.

[nebrius]

Thought: the acceptance/rejection should be private. It sucks being told "no," and is 1000 times worse when the whole world sees it.

[ghost]

maybe we can do something like a typeform (http://typeform.com) or google forms as a medium of application? it'd be relatively private and can be shared amongst WG members

[nebrius]

Resolved with 4a346e3. We can continue to iterate on this process as we begin vetting more applications.