The Loop: Our Community department roadmap for Q4 2021
It’s time once again for the ritual that I know we’ve all come to love: the quarterly update on Community team projects. This quarter’s projects are constrained by a lack of available technical/engineering resources on our Public Platform team, so you’ll see that we are focusing on projects that don’t require assistance from them. They’re focusing on hiring for some roles in the immediate future, so we hope that we’ll be able to go back to business as usual for Q1.
In the responses to my series of questions to the community on Meta Stack Exchange, a fairly consistent theme was a desire for more information more frequently, but also a desire to see how all the pieces fit together. How does the work of the Community Team, for instance, tie to work happening across the organization? I’m going to make a concerted effort over the next year to bring you more of that explanatory flavor.
A few months ago, I presented our roadmap for Q3, and Q4 was very… missing. So here’s the modified Q3/Q4 community roadmap:
Essentially, we’re taking on five new projects for Q4, and wrapping up a couple of stragglers from Q3. We’ve also temporarily shelved a project (Mod Lifecycle and Tenure—the “emeritus” program) for want of the development resources that we need. We’ll revisit it early in 2022.
Three of these projects are community-facing (my “standing offer,” the Mod Quick Start Guide, and the Winter Bash), but you will notice that the other two are specifically called out as research programs with no programmatic changes. For those programs, you will not see any changes in policy or practice—as it says, they are for our own research purposes only.
Let’s take a look at the projects one by one:
- My standing offer: Today I released details to the mod teams (on their private team) about my “standing offer.” I am committing to meet with any mod team that wants to talk to me, and to discuss issues of importance for them or to update them on the work of the Community team. There are some pre-conditions: more details in the teams post. This project is being coordinated by the Curator Support team.
- Moderator’s Quick Start Guide: We envision that this will present practical advice on how to use moderation tools and moderation theory for a mod who’s just taking up this role. This is not envisioned to be a comprehensive handbook on moderation: it’s a concise version for a new mod who doesn’t have much time. This is also a Curator Support project.
- Winter Bash: We’ve already begun ramping up support for Winter Bash. This is a fun project that the team looks forward to each year. I can’t wait to see what they come up with this December. If you aren’t familiar with Winter Bash, check out last year’s post. This is a Community Operations team project.
- Research: Weighted Close Votes: Catija will be driving a project on whether or not to provide extra weight to votes to close and reopen when they are from certain contributors, or those meeting a particular set of qualifications – similar to gold tag badges and duplicate closures. The first question is whether we should do this or not and, if so, the second question is how. This is an information-gathering project so that we can talk about it in a data-driven way and will rely heavily on discussions and feedback from the community. This is also a Community Operations team project.
- Research: Dependencies on Chat: I’ve been amazed at the amount of things that are integrating into our chat systems. So we’re going to make a comprehensive list of systems that integrate to chat. This is everything from my team’s own escalation and work handling bots up to the Charcoal spam-fighting network’s systems. This project will be run by Slate, who is temporarily seconded to the Trust and Safety team for this project (which ordinarily would be run by Trust and Safety, but we haven’t quite completed the hiring and onboarding process for their new team members yet).
Project work like this ideally takes up about 20% of the team’s time. Most of the remaining 80% is taken up in handling tickets from mods, some regular ongoing work (the mod survey, onboarding new team members, interviewing, etc.), and providing internal consulting to the rest of the organization.
So that’s the plan for Q4, and since it’s now done and published (and early at that!), I suppose that means it’s time to get started on planning for 2022! I welcome your feedback, of course, and any ideas that you have for 2022, either here in comments, in answers on Meta, or by email to me: [myfirstname] [at] stackoverflow [dot] com.Tags: community, roadmap, the loop
I have a solution for your lack of resources: Become More Agile.
It is a not too well-kept secret among the software community that sometimes reducing the number of participants in the software development process speeds up those processes. It’s not hard to understand why: the more participants you have, the more consensus you need, the more complex communication gets, and the less stuff gets done.
Case in point: Unpinning the checkmark from the top of the sort order. It took years of cogitation, research and analytics to get that done, and I’m glad it finally got done; thanks for that. But in another era (say, five or six years ago), someone would have just thrown the switch, seen what happens, and then put the candle back if it didn’t work out.
You’re not wrong. I’ll point out that the resourcing constraints are not with the community team, but with the public platform engineering team, but also that the resource constraints in this case are caused by an understaffing of engineers, for a variety of reasons. It doesn’t really matter how agile we are, when we’re as under-plan and under-staff on engineers as that team currently is, stuff is going to have to get dropped.
Isn’t that your own fault (not yours personally) but not too long ago they laid off a LOT of engineers. It was all over social media. Maybe you shouldn’t be so quick to the gun. You complaining about not having the manpower means nothing when you got rid of the manpower that was there. BTW a lot of those employees were very bright people.