When and how to invite new team members?

As we work on a clearer commitment/agreement (in the topic Individual/collective accountability / agreements for team members ), a tangential question:

How should the process of inviting new team members work?

Perhaps someone shows some diligence in other volunteering or participation first? We discuss or formally consent within the team to add another team member?

Some of this will get further clarified as the Board finishes our Bylaws and we then work out more co-op governance. But opening this up for discussion for now at least.

1 Like

Preface — I am a little skeptical of inviting people to become team members from or prior to their first contribution. I’m not saying it’s impossible, but I’ve never seen someone [successfully] join a volunteer project this way. By far the more common route is first making a small contribution or chiming in on an email list and gradually becoming more involved.

Let’s generalize these two questions:

At what point should we consider inviting someone to the team?

A couple years ago I read an article[1] with community management advice for maintainers of FLOSS projects. One recommendation was: If someone sends in one well-written merge request, give them commit access. Basically, the idea is that anybody who sends a MR is already at 99th percentile engagement. I think it’s good advice.[2]

That was for the typical FLOSS project (ie, single maintainer); Snowdrift is a little different. In particular, there are areas where we have more people than work to do (mray and msiep have design pretty much covered). In those area[s], I think adding more team members would probably be a mistake (more communication overhead), but also see below.

For the areas where we are lacking people (developers, legal/coop structure), I think it remains a good policy. For example, I think it’s past time to extend an invitation to @photm, if we haven’t already.

How do we decide whether to actually invite them?

At this point, I think it makes sense to do consensus, by our normal Process for consent decisions on the forum. It can happen in the #restricted:team category. Unlike the normal process, we might want to place extra weight on the opinions of anyone already on the team in that area (eg, Bryan’s opinions, if we’re talking about bringing on a new programmer). Or maybe even leave it up to them to propose inviting the new team member?

After the decision is made, we should convert the thread to a private message, to avoid drama in the case where anybody had concerns about the new team member. This needs to happen for each team member we bring on, even if there were no objections, otherwise the fact that the thread has been hidden signals that there were objections/concerns.


  1. It was a good article that I'd totally link, but I didn't save it at first and I haven't been able to find it since :confused: ↩︎

  2. I followed it for Red Moon and the person who I gave access followed up with several more PRs. It might have turned into more as well, but this was during a time when I was putting in barely any time, myself. ↩︎

2 Likes

Good thoughts. Is this ready to be formed into a proposal itself?

In that case, I did, and he wasn’t comfortable committing at this time.

1 Like

Yes, I will take this on, make a proposal, and then propose inviting @Adroit using that process, once it’s complete.

(Might not happen until the weekend, though. We’ll see.)

4 Likes

I decided to also write a driver statement. In particular, note that I’ve expanded the scope here to also cover onboarding. I can split that out into a separate proposal, but I think it makes sense to keep them together.

  • Situation: It’s unclear how we decide to invite people to the team and how to onboard anyone who has accepted an invitation.
  • Effect: Although we have the contact info of many potential contributors, skillset-hours are still a bottleneck.
  • Need: We need an effective process for inviting and onboarding new team members.
  • Impact: We will be more effective at onboarding new team members, and hopefully can fill the shortage of people to do the work we need to launch.

Below is a draft of a proposal to address this. After someone reviews it, I’ll propose it :slight_smile:


Process for onboarding new team members

Who starts the process and when?

Any team member can propose that we invite someone new to the team.

This can happen at any time. However, some recommendations:

  • Don’t propose inviting people who have not made any contribution so far. Instead, encourage them to make a one-time contribution as a regular volunteer.
    • This is a filter for people who are interested in contributing but don’t actually have the time to be a team member.
  • If we have a shortage of the potential team member’s skill set, propose inviting them immediately after their first material contribution.
    • For example, we are currently short on developers. We should consider inviting anybody who writes code that we merge to master.
      The design equivalent of this might be, anyone who submits a design that we decide to use.
  • If we have no shortage of the potential team member’s skill set, leave it to current members with a similar skill set. For those members, propose inviting someone when you start asking for their opinion before making decisions.
    • For example, we currently have plenty of designers. So, leave it to @mray and @msiep to decide when to invite someone.

How to propose inviting someone?

How to invite someone if the proposal is accepted?

  • Send them a message asking whether they’d like to accept the team agreement.
    • Open question: who should do this?

How to do onboarding if they accept


  1. The purpose is to prevent awkwardness where new team members are brought on and the first thing they see is a bunch of concerns about bringing them on to the team! If there is a specific reason it should stay visible, this step can be skipped. However, hidden should be the default, because otherwise seeing it hidden makes it obvious that there were concerns. ↩︎

4 Likes

This is great, thanks so much!

1 Like

Edited driver (we don’t need pedantically-strict 4-step driver statements):

We currently lack a clear invitation and onboarding process for new team members. If we clarify that, we can better grow the team.

On the suggested proposal

Everything I see is good. But it’s missing some key items. We want to make sure that team members understand and support the overall mission. We already have a general commitment statement focusing on maintaining a minimum communication standard. But we’d want to make sure people review the core documents (CoC, values, etc) and understand how team membership relates to filling of roles… I’d also think we’d want some process of human understanding, getting to know people beyond just their contributions.

At some level, that’s all onboarding. But I suggest we not recognize someone as a team member until onboarding is complete.

2 Likes

Since it’s tempting to skim these (and you guys put so much work into making them concise and readable) we should probably have a way of verifying this.

One idea: fully automate it, with a micro-quiz. Perhaps 3-5 random questions relating to the documents, different each time you take it (100% to pass, unlimited takes).

Good for future scalability, too.

another idea

User level 2 on this forum (“member”) seems like a good milestone to require, and kind of takes care of the time/participation filters discussed above.

1 Like

In verifying core docs, automating something is interesting to consider for other reasons but not needed for team members. We’re talking about such a small number of people, I’d rather make it a human trust thing. We should have a policy that team members should have read and understood that stuff. When we’re inviting someone, we have a human conversation about these things with them. I just want consensus on what the priorities / requirements should be.

I’m okay with TL2 as an idea but maybe more like we expect team members to reach TL2. So anyone not already there who we otherwise want to invite, we just tell them that doing this is an expected part of being on the team. Maybe we check in after a while with new team members and see how they are doing on participation like this?

I guess I’m distinguishing between onboarding and invitation. These items above seem like good onboarding items.

2 Likes

Yeah, but consider how easy it is to get TL2. I’ve had it for a while now, it arrived shortly after I ramped up my participation. Whereas getting to TL3 (200 threads read, etc) without manual override seems like a lot of work to me, and I’ll probably never satisfy it. But TL3 could definitely be a good candidate for your “aim for this” idea.

Seeing how TL2 would be an easily-achievable requirement, I still think it can be used not as an eventual goal but as an actual prereq to teamhood.

Here’s a possible mental exercise to test this out: think of some real people, right now, who qualify (or will soon qualify) for you wanting to invite them onto the team.
Then, look up their trust levels. Are any of them still below 2?

2 Likes

I checked the current team at least, and the only ones not at 2 are @david (original co-founder who gets honorary team status regardless) and @h30 who has gone AWOL/ghosted/disappeared (so basically need to start fresh as a team member if he ever shows up again, but I’d love to hear from him).

I guess we could say that TL2 is a requirement, but it’s okay to say “we’d love for you to join the team” if we have such a reason for a non-TL2 person, and we’d maybe not accept that they are a team member until they are at TL2.

2 Likes

Agreed. I would be open to an “interview”, ie just a chat about whatever things they find most interesting in those docs. Could be live or matrix, forum, etc.

1 Like

Fair enough. I assumed the reason we were here formalizing this stuff was so that it doesn’t have to stay at “such a small number of people”. A.k.a. for scalability. If we leave it to “a human trust thing”, why not leave the rest of it to that as well?

1 Like

Formalizing is about consistent expectations and understanding of the meaning of being a team member. There’s nothing in that requiring any technical (computerized) enforcement.

So, there’s no automated acceptance or enforcement of the team commitment. The point is that we have an agreement (in a human sense) on a specified set of expectations. They can include the communication commitment and reading the core docs etc.

I think this can still scale in that we don’t need everyone on the team to validate everyone else.

Should team membership be done for a certain term and then reviewed? I think being on the team for a limited duration would be a lower commitment and thus an easier decision for many prospective team members.

Should we invite new team members to review everything they find interesting in the governance repo, and raise any objections they may have?

What happens if someone declines the offer to be on the team, or leaves the team – should they be able to initiate the process, so that declining/leaving is an undoable action? If this should happen informally, maybe an invitation to do so should be made when they decline/leave, e.g. “If your circumstances/decisions/[depends on how they explained why they decline/leave] happen to change at some point, feel free to tell us :)”.

1 Like

I think clear expectations about review and moving on should be established. I want a feedback-rich environment that celebrates continual iteration and growth. We can have some review points, but better to build an even more regular pattern where we can efficiently give one another constructive feedback. Done well, this would be an incentive for people to join (and probably anyone who would not want this would not be as good a fit).

I think we should have some clarity about succession-planning. The goal is that as any team member takes on roles, they continually document well enough so that they feel free to move on if need be. I would emphasize that if a new team member is unsure about committing beyond a limited time, that’s fine.

Perhaps we have a list of topics to discuss with new members, including time-frame, but it’s just to make sure to touch on all such concerns. We could do a brainstormed audit of all the questions, concerns, fears, etc. that we imagine a potential team member might have. We then make sure to bring them up when inviting someone to assure all concerns are mentioned in advance.

That makes sense, but along with so much else to cover, I would want this to be part of onboarding after they’ve basically accepted the invitation. And onboarding needs to be step by step, not overwhelming.

I’m looking forward to thoughts from others, but my inclination is to just be totally flexible and case-by-case aiming to have full candor. I agree that anyone leaving could be emphasized that they will be welcomed back, given meeting all the commitments.

1 Like

This issue needs to get consolidated, cleaned, and opened as a new consent-decision process. Opened task here: https://gitlab.com/snowdrift/governance/-/issues/70