Building Codidact Communities
ArtOfCode, the team lead for Codidact, recently wrote Building Codidact: Not Just Tech. It begins:
I’ve been working on Codidact for the last 18 months or so. We’ve built up from nothing, planned what we wanted to do, put systems up, started work, changed course, re-started work, switched systems, and welcomed and lost a whole load of team members along the way. We’ve served just under 5 million requests and 50GB of data in the last month — which is not vast scale, but it’s certainly much bigger scale than anything else anyone on our team has worked with. We’ve all learned a lot along the way: our team is still small, and we’ve all got other commitments; while everyone has things they’re good at, we’ve all had to learn bits of other areas to be able to support each other as well.
Art wrote about evolution of the platform and team, and of the things that happen to grand plans when they make contact with reality. In this post I’m going to focus on the community side — people and sites and features and evolving needs and what I’ve learned along the way.
I’m Monica Cellio, Community Lead at Codidact.
In the beginning
I found out about the Codidact project in October or November of 2019. We would spend the next few months talking about what we were going to build and how we were going to build it, but in the meantime, we had a community that desperately needed a new home.
Writing had been shattered by events at Stack Exchange. Community leaders wanted to move to Codidact, but Codidact was just an idea at that point. In December 2019, we set up some “temporary” software and imported most of their content, so they could continue their community here. We promised to host them on that temporary code until Codidact was ready and then move them over. We made a commitment to our communities from the start, setting the stage for our partnership in building Codidact.
Communities don’t migrate; they fragment
When we set up Writing we were thinking of it as “emergency evacuation”. Several top users had already quit Stack Exchange. We worried that if we waited, we would lose contact with even more people. When we set up the Codidact community, active users tried to spread the word.
Stack Exchange impeded that effort, which is their right as owners of the platform, but the larger challenge was inertia. A community isn’t a single organism; it’s a composite of all the people who are part of it. People reach their breaking points, when they’re ready to abandon sunk costs and overcome inertia, at different times. Unless something forces the issue (like the current host shutting down), communities don’t move together because people don’t move together.
Some people from SE moved to the Codidact community right away. Some waited and watched. Some quit the previous community but didn’t move to Codidact either — they’re just gone. I think a few participated on both, at least initially. A lot, I think, were less involved in the “meta” discussions about the community and even now don’t know about the Codidact community — they’re still back there, maybe wondering what happened to some formerly-prolific contributors. Reaching everyone was hard, and in retrospect we should have focused sooner on building the new community as a new community.
It’s easy to forget that the people actively discussing a community’s operation and future plans are a very small proportion of the community’s members. A community needs both active and casual members, ones who want to get into the nitty-gritty of operations and also ones who just want to know how to solve the problems they’re currently facing. We didn’t attract enough of the latter and that has hindered the community’s growth. We needed to focus more on new possibilities and less on rescuing all our old questions and answers.
Communities are partners in platform development
By June 2020, seven months later, we’d started half a dozen communities, had learned some lessons both technical and community-oriented, and had made a bunch of improvements to that “temporary” code that we had decided to adopt as our baseline. Two communities approached us at about the same time, and both of them had already rallied interested participants elsewhere. We were able to set up both in a matter of days and they remain active.
One of those two, Judaism, asked if we could build in a citation userscript they’d been using elsewhere. That turned out to be hard, but they then found a tool that we could plug in more easily. After we did a code review we were able to add it for them. A couple months later, when the Code Golf community asked us to support a different important userscript, we were able to add what they needed so everyone could use it. That’s how the table of contents for answers came to be. We worked with the communities to understand their needs, and they helped us find solutions.
We have ideas, based on our own experiences, of what will serve our communities and participants. And we’ve had broad input about key features from early on. But you can never anticipate everything. Our communities know that the platform is still being developed and still evolving; while that means not everything is done yet and that can be a little frustrating, it also means that we can work together with our communities to build the things we didn’t know were important.
Because we work with our communities, they cut us some slack and sometimes even contribute code. We’re partners, not provider and users. This collaboration helps us all build better tools and stronger communities. Fostering that spirit of collaboration is essential.
Rethinking data import
Because we thought of Writing, that first community, as an evacuation, we imported most of the posts from Stack Exchange and set up a way for people to claim their work on our community. We wanted people to be able to continue from where they left off. Two of our next three communities followed suit and also imported content. Communities that followed instead started fresh.
I, and I think most of the team, now believe these bulk imports were a mistake. Especially in the beginning, visitors saw a site that looked like mostly a clone; the new, local, original content got buried too easily. The people who joined Codidact and claimed their posts often improved them, which makes Codidact’s copy better than the original, but that doesn’t stand out enough. Meanwhile, a lot of people never created accounts, so we have lots of posts that nobody on Codidact is invested in. We were attached to the old when it would have been better to focus on the new.
A year after the mass import, Writing began deleting imported posts that no one had done anything with — claimed, edited, voted. When this is done, we hope the result will be fresher and more inviting.
I think there is still a place for selective imports, but there is value in a fresh start. If there’s a question on some other platform that you’d like to answer on Codidact, you can re-ask the question in your own words and then answer it. Or you can write a blog post or a wiki page, options available on Codidact. The posts on our communities should be the ones that the people on our communities are invested in.
Outreach and growth: our biggest challenges
We have over a dozen communities now, created through a somewhat-informal proposal process. We try to collectively evaluate when a proposal has a solid scope and “enough” participants to make a go of it, but this is very much a work in progress. We’re using judgement and sometimes gut feelings, not validated metrics. We don’t have validated metrics yet. We want to work with our communities to improve.
Our communities are doing some great things (and letting us know when we don’t quite have the tools they need). I’m getting good answers to my questions and trying to provide good answers for others. I’m watching our communities create informal challenges so people can share things even if they don’t exactly have questions. Our Electrical Engineering community has papers alongside Q&A, and Software Development accepts requests for code reviews. Cooking has recipes. I’m excited by these new ways of learning together.
Our communities are still small. A few people being more or less active can make a difference, especially in the beginning. Activity begets activity, and inactivity begets inactivity. We don’t have people with hundreds of thousands of Twitter followers or blog readers. Our communities grow one person at a time, often by personal outreach or word of mouth. We need to find ways of reaching more people, and we need to provide a good experience for the people who join us. How we do all of that is a problem that keeps me up at night sometimes.
Making Codidact better, one day at a time
We’ve accomplished a lot already and I am very proud of our team and our communities. We’ve still got a lot to do, on both the platform and in community growth, and we welcome help and input. We have active discussions on our network meta community, and we welcome contributors to our open-source project and participants on our communities.
We’re still learning. I’m still learning. Years of moderation experience elsewhere prepared me for some things, but in other ways I’m learning as we go. Some lessons transfer well, like how to give constructive feedback in a welcoming way. Other challenges are new, like helping small new communities get off to an active start.
I figure that if today is better than yesterday, and tomorrow might be better than today, then we’re on the right track — building together, by and for the community, learning together as we go.
