Notifications
One of my last projects at GitHub was prototyping a new notifications system.
The vision of the project was to become the central hub for a developers work — integrating with all the different tools they used in their day to day job building software:
We also wanted to turn GitHub's notifications into a more powerful tool, the existing page had grown outdated and difficult to manage — it was impossible to use it the way we use modern email or todo list software.
-
We built prototypes and had a small group of internal opt-in beta testers.
-
We were able to get buy-in from leadership to figure out how ot improve notifications with these sketches and early prototypes.
-
We ran into issues with performance on both frontend and backend. GitHub was still mostly avoiding real-time updates to UI. The backend for Notifications wasn't architected to be available on every page all of the time.
Protected Branches
As GitHub expanded to larger customers we were losing large deals because we didn't have tools that enterprise customers needed to satisfy regulatory and compliance requirements.
For example:
-
The ability to require certain tests to pass before code was merged.
-
Determining whether code review was required or not.
-
An audit trail of who modified, reviewed, or merged code.
As the Director of Product I managed the team that prototyped, researched, and built the first version of Protected Branches.
Our goal was to enable people to use the GitHub pull request workflow, but provide control to administrators to set rules on when things could merge.
We did multiple prototypes and research with beta customers before shipping the first version, working hard to build something that didn't frustrate developers but enabled administrators to satisfy regulatory and compliance requirements.