Contribute to the code

Spor is a design system aimed at helping us develop consistent and cohesive digital interfaces for our users. The finished components you find in Spor are universally designed, work in all modern browsers, and are crafted to be as easy to use as possible – both for developers and designers.

Although Spor is centrally maintained by a small core team, we expect the majority of new development to be carried out within the various product teams. Need a new component? Create it yourself and submit a pull request to the codebase to have it integrated into the component library. Found a bug but don't have time to fix it right now? Create an issue on GitHub so others can tackle it. Think the documentation was confusing or lacked some examples? Let us know, or even better, make the changes yourself!

All developers and designers at Vy can and should contribute to Spor, so that the efforts of one benefit the entire organisation. If you have any questions about this, please contact us via the #spor channel on Slack.

There are many ways to contribute to Spor. Here are some of them:

• Conceptualize and design new components
• Develop a component, feature, or bug fix
• Submit proposals and design changes via design sync meetings
• Increase test coverage by writing tests
• Enhance the documentation page
• Improve documentation with more examples or proofreading
• Report bugs and improvement opportunities via GitHub issues
• Provide feedback on design and developer experience
• Give feedback on pull requests on GitHub

As long as you assist us in the work of further developing and iterating on our design system, the medium really doesn't matter much. All contributions are valued, and no contribution is too small.

Let's specify a couple of the contribution methods we outlined above. This can help lower the threshold for doing it yourself for the first time!

Let's say we've decided that we want a new type of notification – called toasts – to be implemented. Since you're the first one needing this specific component, it's your team's responsibility to develop it (just as if we didn't have a design system!).

After confirming with the designers that the sketches are approved enough to start development on them, you notify that you're working on it (either via the #spor channel on Slack or by creating a GitHub issue).

The way you'll work on developing the new component will vary based on the platform you're implementing it for. We'll cover the technical approach in another article.

Remember to test your code thoroughly. That doesn't necessarily mean countless unit tests, but check that everything works where it should. Here are a few things you should verify:

• Check that the component works in Chrome, Safari, and Firefox
• Check that the component works on different screen sizes
• Check that the component works as expected with keyboard navigation and screen readers

The component can be tested live using the playground.

When you're done with the technical implementation, it's time to create a pull request. Write a good description, preferably with some screenshots and gifs of how things look. Tag relevant technical resources (they're often automatically suggested), and add the correct labels.

Tip: If you don't have direct access to push code to our repo, request access via Slack, or create a fork.

Experience-wise, you'll receive feedback on your work shortly. Iterate on your code until the pull request is approved, and then you can let the core team publish a new version of the relevant component library with your code included.

Our documentation is stored in the content platform Sanity, which is currently not accessible on the internet.

To contribute to the documentation, ask if you can get access via Slack. Then you can run our Sanity studio locally and make your changes there.

Our content is structured into different content types (called "schemas"), which include articles, components, and categories. Navigate through the tree structure, or search to find the content you want to edit.

Once you've made the changes you want, you can press Publish to have it published on the page. The new content will be made available automatically.

The world isn't perfect, and neither are the people who have worked on Spor so far. There will be bugs, small errors, and other annoyances that one wants to get fixed – even if you don't necessarily have the expertise or the opportunity to do it yourself right now.

In such cases, you can add cards to our Trello board, or create an issue on GitHub.

Try to be as specific as you can, making it as easy as possible to reproduce the error for the developer or understand the challenge for designers.

One of the ways we collaborate is through a common meeting place we call the Design System Forum. Everyone interested in using and contributing to Spor in some form is encouraged to join.

During these meetings, we showcase work happening within the various teams to avoid potential duplication of effort. Internal working groups are formed and disbanded, and we discuss and iterate on the goals of the design system as a whole.

The Design System Forum is an internal meeting place for Vy. If you'd like an invitation, please contact us via the #spor channel on Slack.