helping members retire

[ashleygwilliams]

as we continue to add more members to the team, it's customary to also discuss how members are removed, or retire from the team. some initial thoughts on the topic:

• members should be expected to attend a certain number of subteam or general team meetings, we can make this a very very low number, but i think participation is important
• all members should be a member of at least one sub-team

in my experience this tends to go best if instead of counting attendances or other metrics, that members who feel that their participation is dropping off voluntarily opt to retire.

there is always the option of rejoining as a member, and none of this process is meant to shame anyone <3 :)

feel free to share your thoughts here or in private email or other communication, we'll be discussing this at our next meeting

[ghost]

So, in my opinion it'd be ideal if the Community team was almost purely a representative team, representing its subteams. That means it should only include:

• The subteam leads
• The Community team lead, if not also a subteam lead

This means the responsibilities of the community team would be to do administrative things that a top-level team has to do, to represent the subteam members to the larger Rust project, and funnel people that show interest in the community side of things to subteams they might be interested in contributing to.

Apart from that, I also think that the Community team should implement policies that the subteams can and should adopt. One of those should be a policy regarding attendance and retiring. Now, there's obviously multiple ways we can implement this, and I don't want to decide on one thing quite yet, so here's some inspiration on how other projects I've been a part do this:

• We could keep an attendance sheet (which we do already iirc) and every X months, carry out a review to identify members who haven't been active. Then, we could and should have multiple ways of responding based on what the circumstances are (maybe they're just on parental leave) and how long they've been inactive for. Most people who we previously used this process on agreed on what we proposed them. In general, asking people first works nicely 😉
• We could also use a simpler method, which is just asking everyone every once in a while to see if they have continued interest in contributing, or if they have anything coming that would make them unable to contribute for a while.

This is by no means a complete list, but it is based on things that I've tried in other projects, all of which worked well in their respective circumstances. All in all, I think the most important thing to take away from the meeting should be that we need a method of gauging a team member's continued interest in contributing, as well as figuring out how to act on it.

[edunham]

I did the thing and also wrote words about the thing: rust-lang/prev.rust-lang.org#1112, http://edunham.net/2018/05/15/team.html

Retiring oneself is sorta hard and I would suggest as best practices that upon removal, ex-members treat themselves to some reassurance that it was a good idea and also a nice snack.

Edit: My views from how others should handle the retirement process are hidden in the middle of the big pile of words:

I think establishing turnover in a healthy and sustainable way is one of the most essential tasks for the team to build its skills at. The best way to get a healthy amount of turnover – not too much, but not too little either – is for every team member to step up to the personal challenge of identifying the best time to retire from active involvement.

I think if someone's actions are actively harming the team, like if they consistently break promises or something, that's kind of a different issue and should be addressed separately to avoid any implication that retirement is a form of punishment.

I almost wonder if it's worth considering a "term" system to reduce burnout -- joining the team means committing to 6 months or a year on it, and after that period people re-assess whether they would join the team again if they weren't on it already to get a better perspective on whether they're sticking around because they want to or just out of inertia.

[ghost]

@edunham I think the idea of a loosely defined "term" system for the team and perhaps also its subteams sounds really good! It gives members enough time and opportunity to reflect on their own ambitions and commitment. We just have to be sure about this, as with the establishment of such a system comes a bit of administrative overhead.

[bstrie]

I like this suggestion by @oe:

So, in my opinion it'd be ideal if the Community team was almost purely a representative team, representing its subteams. That means it should only include:

• The subteam leads
• The Community team lead, if not also a subteam lead

Back before the subteams existed, I used to be of a mind that the nature of the community team should be utterly maximalist, in order to accommodate anyone with their own local Rust community and keep anyone from feeling second-class. But in the face of the realities of human life--uncertain time commitments, major life changes, the simple desire to move on--I think making the community team instead be only the subteam leaders, and then making it clear that the subteams are open to community participation is a strategy that both lets us get things done efficiently while also not excluding anyone. The "community team" has always had a very broad and vaguely-defined mission, and actually achieving goals is better served today by the subteams anyway.