Fishtown Analytics’ Director of Consulting, Erin Vaughan, just published an article on the dbt blog on how to review analytics pull requests. This is a topic that has come up a few times in dbt Slack, once recently focused more on the people side (who reviews) vs. the step-by-step checklist.
I’m opening this thread in case others in the community have advice to add on how your team manages the PR process–whether that’s advice on writing better PRs, how to coach and give feedback on PRs, or the people involved in the process.
One thing that I love to add as a PR submitter is a link to a dashboard that is built on top of the model I’ve been working on! Something like this (for anyone following the health of our company, don’t worry – this is fake data ):
I’ll also include any queries that I ran as part of my own validation to save the reviewer from doing the work themselves, like this:
(If I’m being extra good, I’ll also include the results of the query)
Erin’s hot tip about adding a PR template has been an absolute game changer for the projects I’ve been working on – definitely recommend that people adopt this practice in their own projects!
At the company I work for, we list this Slack article on empathy and pull requests under the strongly suggested reads section of our software engineer onboarding process, and most of it is applicable to any type of pull request workflow. Erin Vaughan’s article and @claire’s reply above do a good job transcribing into dbt and analytics terms what the post below talks about more generically.
I would be super interested to hear what automated pull request checks teams are using (or would like to use if available) in the review process.
):
