Here’s everything you need to know if you’re even thinking about contributing to Great Expectations.
If you’re brand new to open source contributions, our processes will walk you through every prerequisite and step you need to take.
And if you’re a veteran, you’ll learn exactly what steps will get your contribution queued up for integration into GX as smoothly as possible.
Contribution options
You can contribute to GX in four main ways: code, Custom Expectations, packages, and documentation.
Code
Code contributions modify or extend GX’s core functionality. We accept both new features and bug fixes from community contributors.
If you’re thinking of adding a new feature, we recommend letting us know in the #contributing channel of our Slack. We can let you know if there’s any other work on that feature that we’re aware of either in the community or within GX, and offer any other guidance that we have.
For both new features and bugs you’ve found yourself, please create a GitHub issue and assign it to yourself.
If you’d like to fix a bug someone else has reported, check out our GitHub issues list, especially the ones labeled help wanted. Assign yourself to an issue and you’re ready to go!
When joining an existing issue, be sure to comment to introduce yourself and let everyone else associated with the issue know that you’re working on it.
Here’s how to contribute a code change.
Custom Expectations
Custom Expectation contributions are how you add a new Expectation to the Expectations Gallery. No matter how niche your Expectation is, we encourage you to contribute it—your Expectation doesn’t need to support every backend to be part of the gallery!
In fact, the minimum required for a Custom Expectation is to run on one Execution Engine. Part of the beauty of an open source community is that someone might come along and extend your Expectation to support more.
Even if they’re adding support for a completely different Execution Engine, it’s still less work than if they’d needed to build that same Expectation from scratch.
To help gallery users identify the maturity of the Expectations, Expectations have one of three statuses: experimental, beta, or production. Our contribution guide will show you how to identify what status your Custom Expectation should have.
Here’s how to contribute a Custom Expectation.
Expectation packages
An Expectation package bundles up a group of Expectations for use together in a particular scenario.
Important: when you start developing your Expectations package, let our developer relations team know in the #integrations Slack channel! This makes our dev advocates aware of your plan so they can discuss your plans for your package, support your development process, and help you navigate publication and maintenance.
Expectation packages can also have associated domain experts. A domain expert is the package’s architect; they develop the blueprint for what kinds of Expectations the package needs in order to become the data quality standard for its domain.
If you’re interested in becoming the domain expert for a package—whether or not you contributed that package—post in the #integrations channel and a dev advocate will get in touch.
Here’s how to contribute an Expectation package.
Documentation
Documentation contributions generally fall into one of three categories: changes, how-to guide contributions, and integration guide contributions.
Changes are for when you find errors in or have suggested improvements for the existing documentation content. We welcome all changes, big and small—even fixing a single-character typo makes the docs better and more usable for others!
How-to guides explain how to replicate a specific process using GX. These make up the bulk of GX’s documentation. They’re a main priority for our technical writers, but we’re more than happy to accept contributions for processes that we haven’t gotten to yet!
Integration guides provide specific instructions for—as the name suggests—integrating GX with various third-party products and services. The integration guides we host in our docs are for technologies where we have the ability to create a test environment, so that we can keep the integration guide up to date as new versions of GX come out.
For technologies where we don’t have access to a test environment, we link to the integration docs hosted by the third party: since GX is free and open source, anyone who integrates with us has complete access to the latest versions for compatibility testing.
If you’d like to contribute an integration guide, let us know in the #integrations channel of our Slack and a GX developer advocate will get in touch to discuss whether we can maintain a test environment so we can host the docs internally. If we can’t, we’ll make suggestions for next steps.
Here’s how to contribute to documentation.
Technical prerequisites
Every GX contribution needs a GitHub account; if you don’t already have one, you can sign up here. The free version has everything you need to be a GX contributor.
GitHub’s all you need for a documentation contribution! You can do all the other steps in your browser.
If you want to contribute code, a Custom Expectation, or a package, you need a few extra items. It’s likely you have some or all of these already in place:
You’re now set for code contributions!
To contribute a Custom Expectation or a package, you also need GX installed and configured for your environment—and, of course, the Custom Expectation(s) you’re planning to contribute or package up.
Thank you to contributors past, present, and future
Community contributions are the lifeblood of any open source project, and GX is no exception. We’re extremely grateful for the time and energy that each of you has put in.
