Our Contributors Rock
To be effective, data quality requires a workflow and collaboration. Great Expectations must be able to notify you when validating a batch of data succeeds or fails. Previously the only notification mechanism was Slack by enabling SlackNotificationAction in their Validation Operators' configuration, then Niall added PagerDutyAlertAction.
Mike's PR adds OpsgenieAlertAction- a class that creates and sends an Opsgenie alert in response to a validation result. This is the 2nd community-contributed notification action and we are very excited to have it. It uses the pluggable architecture of Great Expectation and can be used as an action in the list of actions of existing Validation Operators.
This is part of the 0.12.8 & 0.12.9 release and here is the PR
Here's our interview with Mike about the PR contributions:
What encouraged you to make this contribution?
"I'd been looking to contribute for a while and once I saw the contribution from Niall for the PagerDuty alerts I thought it would be a great point to jump in and add support for Opsgenie - a similar alerting tool. This is what we use internally for our alerts and it acts as
a great proxy for sending additional notifications to other services like Slack as well as us being able to provide SLAs around data quality alerts. We've started rolling out Great Expectations out in conjunction with these Opsgenie alerts and this makes the monitoring
of these models particularly friendly - and we're starting to integrate more and more metrics into this reporting (such as test suite times)."
What steps did you take to figure out how to contribute?
"I had a look at the existing codebase, as well as the contribution from Niall which achieved a similar action. I also had a look through the Slack alerting code for some inspiration as to how to put together a template to format and display this information in the Opsgenie request.
The documentation (contributing guide) was generally pretty helpful in getting started and the style guide was pretty helpful in figuring out what conventions to follow and what to avoid. Overall the documentation is really clear."
What kind of impact will this contribution make on your team’s (and other teams’) workflow?
"For our team, this means that it’ll now be easier and faster to receive notifications about when, what and how certain expectations are failing. These alerts feeding into our on-call system means that we can easily fan out to other monitoring systems which makes it easier to alert downstream consumers of data models that data quality issues may affect the build or consumption of this data."
Is there anything you would like to see to make contributing easier?
"The documentation overall is very good. I think it would be worthwhile adding a pull request template to Github that links out to some of the RTD documentation for folks who may have missed some of this documentation (before a PR is made). I'd also add some information about how tests are run (using Azure) so that for situations in which the builds fail it's easy for a user to know where to jump into view any build issues (and any common solutions)."
Thanks to Mike for not only the awesome contribution but for sharing your experience contributing with us! Hope you enjoy your Great Expectations Contributor coffee mug!
