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 component: Creating a 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.
You can create a pull request using the standard gh pr create
command. Here are a few things to keep in mind when creating a pull request:
-
Tests: Our suite of tests will run automatically on the creation of a pr but you can also run them on your local branch by running
./gradlew check
. -
Creating a local maven .AAR: If you want to test your changes locally before creating a PR, you can publish your .AAR locally by running
./gradlew publishReleasePublicationToMavenLocal
. Make sure to add the maven local repo to the application that is importing thumbprint so it is fetched from there and not JitPack. If you are a Thumbtack employee add it to BaseModulePlugin like this:
BaseModulePlugin.apply(...) {
project.repositories{
// Add here
mavenLocal {
content {
includeGroup("com.github.thumbtack")
}
}
}
}
If you're having issues, try changing the version number to one that isn't currently used by JitPack and importing that version locally.
This will be done by a member of the Thumbtack Android team when code has been merged and is ready for release.
- Go to release workflow: In GitHub, go to the repo's Actions tab and select the Release Thumbprint workflow.
- Open dialog: On the righthand side of the blue banner labeled "This workflow has a workflow_dispatch event trigger.", click "Run workflow."
- Update version: Enter a version number for the release (e.g.
1.2.3
). We follow semantic versioning, so look at the changes that will be included in this release and increment it accordingly. Leave "Branch" asmain
. - Start action: Click "Run workflow" to start the release process.
- Manual step: The script will create a PR that bumps the version in the thumbprint/build.gradle.kts file. This PR must be merged manually, as GitHub Actions do not have write access for the
main
branch. - Manual step: Update the description of the GitHub release created by the action with the changes included in this version.
This action (a) creates the version bump PR mentioned above (b) creates a tag for the release (c) creates a release in GitHub tied to this tag
- Update version: Update
version
inthumbprint/build.gradle.kts
. We follow semantic versioning, so look at the changes that will be included in this release and increment it accordingly. - Commit: Commit the change you made in step 1 with the subject "Release " (e.g., "Release 1.2.3"). Create and merge a pull request with this commit.
- Checkout main: Return to the
main
branch and pull to get the commit you just merged. - Tag release: Run
git tag '<version>'
(e.g.,git tag '1.2.3'
) to tag this commit, and then rungit push --tags
to push the new tag. - Create a new release in GitHub: On the Releases page for the repo, click "Draft a new release". Set "Tag version" to the name of the tag you created in step 3 (e.g.,
1.2.3
). Set "Release title" to the same value as the tag version. In the description field, give an overview of the changes going into this release. When all fields have been filled out, click "Publish release."
As always, reach out to #design-systems (internal to Thumbtack employees) or create an issue if you have questions or feedback.