Skip to main content

Change Approval Process and Website Ownership

Introduction

As our organization grows, so does the number of internal services we maintain. The Stevens Blueprint website is one of these services. Now that the website has reached a stable version, we need a lightweight approval process to ensure future changes align with our design principles, organizational messaging, and technical standards.

In software development, the concept of service ownership is commonly used—where a team is responsible for building, maintaining, and supporting a service. We propose adopting this model within Blueprint, starting with the website.

This document introduces a formal approval workflow for website changes. It ensures changes reflect our design values, maintain technical stability, and uphold our public-facing brand. It also adds accountability and reduces the likelihood of breaking the website.

Approval Process

There are three groups involved in the approval process:

  • The VPs of Technology will create an internal team and assign ownership of the website to that team (Website Team)
  • The VP of Design and Design Team will also be assigned ownership (Design Team)
  • All pull requests (PRs) that involve visual changes to the website must be approved by 1 member of the Website Team and 1 member of the Design Team.
  • All PRs that that do not involve visual changes (i.e analytics or documentation) may be approved by 1 member of the Website Team
  • All PRs that involve changes to the Blog must be approved by the VP of Marketing and 1 member of the Website Team
Design Principles
Tests
Analytics
Tangible Things

Add branch protection that mandates approvals from the respective teams for PR approval.

https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners 

Discord Channel for #website team and a #public-website channel for any Blueprint members to raise concerns or discussion.

Steps:

  1. Create a team in the org and add members (follow lowecase kebab case: "team-cappucino")
  2. Create a branch protection set and mandate review from codeowners
  3. Create a CODEOWNERS files in the .github directory of the repository
Back to top