The Design Systems team welcomes contributions from all developers at Thumbtack. These contributions can range from small bug reports to brand new components and initiatives.
Here are a few ways to get started:
Providing feedback is the easiest way to contribute to Thumbprint. You can do this by creating an issue on GitHub.
If you're a Thumbtack employee, you can also post on #design-systems for quick help.
There are two ways to contribute code back to Thumbprint:
- Tackle open GitHub issues: Issues labeled as “good first issue” or “help wanted” are perfect for contributors that want to tackle small tasks.
- Propose and create a new React component: Creating a React component allows contributors to dive-deep into component API design, testing, accessibility, and documentation. Please create a GitHub issue to propose a new component. If the component is a good candidate for Thumbprint, we’ll schedule a kick-off meeting to discuss next steps.
Not sure if the component should be reusable? Take a look at the “Where should a React component live” RFC (internal only).
Use the following commands to run the Thumbprint documentation:
git clone [email protected]:thumbtack/thumbprint.git
cd thumbprint
node -v # This must be 16.x
yarn -v # This must be >= 1.4.2
yarn
yarn start
Then open http://localhost:8090/ to see the docs. Take a look at www/README.md
to learn more.
The Thumbprint codebase is a collection of packages that we version independently and publish to NPM. These packages live in packages/
. Take a look at the package's README.md
for specific information about that package.
To add or remove NPM packages from code in packages/
, cd
into the package's folder (cd packages/[package-name]
) and use yarn add
, yarn remove
, or yarn upgrade
. Thumbprint uses Yarn's workspaces feature to manage multiple package.json
files in one codebase.
Our documentation source code lives in www/
. Take a look at www/README.md
to learn more.
CODA_API_TOKEN
– This is an API token from Coda that we use to display the component statuses onthumbprint.design/components/overview
. It is not required for local development. To get it, message a Design Systems team member on Slack and store the value as an environment variable inwww/.env
.
Here are a few things to keep in mind when creating a pull request:
- Testing: Run
yarn verify
locally to ensure that the build will pass. If the command fails because of Jest snapshot tests, you will have to runyarn test -u
to update the snapshots. Review the changes to the snapshots to ensure that they are intended and include them in the code review. - Changelog:
- Most changes within
packages/
require updates to the package'sCHANGELOG.md
file. You can skip modifying the changelog if your commit only modifies this list of ignored files. - Our changelogs follow the “Keep a Changelog” specification. Our version numbers follow Semantic Versioning.
- You should not include the package’s new version number as part of your commit. That is done in the release process.
- Most changes within
Create a new folder in packages
with the following structure:
├── CHANGELOG.md
├── README.md
├── package.json
Thumbprint follows a traditional GitHub workflow. This means that you should work in a feature branch and submit a pull request when ready for code review.
Learn how to release the Thumbprint packages and documentation. This process is done by Thumbprint maintainers after your code has merged into master
.
As always, reach out to #design-systems (internal to Thumbtack employees) or create an issue if you have questions or feedback.