Setting up a healthy, thriving open source community around a design system
To make any system work that relies on collaboration we first have to admit that what we are asking for is charity. Yes, there are great benefits when working closer together, many of which are long term gains and big picture wins. In this article however I’d like to focus on the thought process we must go through in order to create a healthy and productive collaborative environment.
The great Nathan Curtis has written about how you might structure a design system team. If you haven’t already, give it a read; it’s well worth your time. I‘ll focus here on the federated team model.
Communication is key
The success of a design system built for collaboration and in the open source space asks people to donate their time and effort to the project. This is a big ask and we have to be humble as to what that means for contributors. We must ensure that effort and time is not wasted because of lacking communication. Expose as much information as possible about what your goals are, how contributions are made and how one might learn and ask for the skills necessary. Create issue/PR templates if you’re using GitHub and publish your roadmap. Decisions need to be well reasoned and documented to avoid confusion and disagreements later down the track. Make sure your channels are open and you capture common questions. Create success criteria on how long it takes you to respond to issues/PRs. Get better over time by looking at feedback and do your part in user research. Take notes of all questions and expose your answers on an FAQ accessible to all.
Treat contributors as an extension to your team
When deciding on a new component or a new direction, make sure you include the community. Be mindful of hallway chats as they are not accessible to your team members that are not in the same location. Use platforms like Discourse to enable and log those discussions. GitHub also just recently announced team discussions. I personally see the contributors in a FOSS(Free Open Source Software) project as colleagues who work remotely and are infrequently on and off. This by itself comes with challenges. Always remember though that the ask is big and your job as the maintainer is to enable and empower.
The mood is fragile and needs constant care
In open communities people often bring the stress of their jobs and life with them. This can and will impact the tone and mood of your community and can be a make all, break all sort of deal. We are all humans and have bad days. A healthy community needs to build that fact in right from the start. Not everyone will always be happy but the respect and productivity of your community needs to balance that. The best thing you can do here is to be humble. Create clear channels for productive discussions and curate what doesn’t belong into the appropriate places. Most often people just want to be heard. Make sure your ears/eyes are genuinely open. Take all feedback serious and catch bad behavior early. A secure way to complain about abuse makes all the difference. Expose those channels clearly and write up what is considered bad behavior and how it will be dealt with. Capture all that in a code of conduct document; a great starting point here could be the Citizen Code of Conduct or the Contributor Covenant.
People don’t like change
When working on a design system you want to be able to make changes and adapt to your environment as quickly as you can. With a community you want to do the opposite.
People don’t like change; be sensitive to that and give enough head space and time when making changes. This does not mean you can’t make changes to your design system. It means when you make a change, think about how this might impact your contributors. Communicate why things change and have productive discussions. Listen to the feedback and sometimes going slower is more stable than running fast. Setting up your community to rapidly release components might help with the expectations here.
Give ownership to the contributors
Particularly in a design system we need to make sure a big picture approach is maintained. Someone needs to own the design language so that each component is aligned visually. The same is true for the engineering part. Code should have a consistent style and use the same API and deprecate old architecture. Those might not be the best roles to outsource as they require constant attention and rigor. But there are a lot more things to own that can be given to contributors. Embrace all skill levels when giving out ownership. Some might be great at code/design, others great at explaining things. Let contributors own their part so they have skin in the game. Make sure you have a process in place to make the nomination of ownership transparent. That could be an election, or just an informal hand raising but in the end it needs to be documented so new contributors can see how it all happened. A contributor coming to you wanting to own their bit is the best thing that can happen to an open source community. It’s on you to shape and empower those who are willing.
The Australian Government Design System team are currently working on how we might enable greater collaboration in our design system. In the coming weeks we’ll be launching our documentation site and a platform to bring our community together in one place.
