Back to Blog

Code review for non-technical users

Carlos Aguilar
Carlos Aguilar
July 18th, 2024
Code review for non-technical users

Move fast and don't break things

Data teams face an existential question. Do you let end users update dashboards and metrics — risking inevitable breaks — or do you restrict access and let the requests for tiny tweaks pile up into an endless backlog? 

Non-technical users face an existential question, too. You want to see what it would look like to update colors or fix a few metrics, but you don’t want to impact downstream resources or disrupt other users while you explore. Is there a way to collaborate on dashboards without breaking into a cold sweat?

We built project drafts to answer for both. By creating a fork of your entire project, project drafts enable everyone to simply see “what if…” or coordinate large updates safely. 

You can think of drafts as a pathway for all users to propose changes without opening up edit access — a sort of code review for non-technical users.  

Coding and non-coding workflows working together

Hashboard is unique in supporting technical users and non-technical users alike with every workflow. You can define metrics and dashboards either with formulas and a point-and-click GUI or with code.

For every resource, the data team can choose to manage that resource with code or not. This is really powerful! A lot of people will use code to manage their most important Hashboard resources and keep them aligned with their dbt pipelines, for example.

There is one downside, though. Historically, once something is code-based it’s hard for people without knowledge of technical tools to collaborate on it.

Project drafts allow non-technical users to propose changes so that they can be reviewed and merged by technical users. The feature allows the technical developers to turn changes that are created in the GUI into code-based changes that can be reviewed with code diffs integrated right into the UI.

Coordinating large changes

Project drafts allow you to propose changes across an entire project. You can queue up multiple changes across multiple metrics, dashboards and explorations. Let’s say you want to add a new business line across several metrics, dashboards and reports. You can stage all of those changes in a single project draft so people can compare before and after and see all of the changes in one place. The project draft is a standalone version of your project that you can review, analyze and interrogate. A clear orange banner bordering the entire application lets you know that you’re drafting, not deploying.

While this workflow feels familiar for people that use our code-based deployments, project drafts bring code review-like workflows into the GUI so that anyone can propose small or large and complex changes.

How project drafts works

Let’s take someone on the marketing team who wants to stage several changes for review. Maybe they want to filter out internal users from a new accounts metrics or quickly change a color on a dashboard.

Here’s how this user could stage changes and send them to the data team for review:

  1. Anyone with permission can create a project draft on the drafts page.

  2. This draft creates a fork of your entire project. Inside the draft you can safely create a set of changes without affecting your project.

  3. Edit, delete, merge, refactor everything inside the project draft.

  4. From the draft summary page, you can see the exact changes that you’ve proposed including a code-based diff view of what has changed.

  5. You can send over this draft for others to review your changes.

  6. People with permissions can merge changes into your project.

With drafts, anyone on your team can explore and suggest changes without having to create different versions of dashboards or other heavyweight workflows. 

We’re continuing to iterate based on feedback. Please let us know if you have any suggestions or if there are workflows you want us to support.