# 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 3 groups that will have ownership of the Website:

1. The VPs of Technology will create an internal team and assign ownership of the website to that team **(Website Team)**
2. The VP of Design and Design Team will also be assigned ownership **(Design Team)**
3. The VP of Marketing will also be assigned ownership **(Marketing Team)**

- All pull requests (PRs) should pass the automated checks (build, tests, linting/formatting)
- All 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 **1 member of hte Marketing Team** and **1 member of the Website Team**

##### Implementation

- **Create Teams on the Blueprint Organization GitHub**. For teams we should follow a standardized naming schema with kebab case: i.e ("team-latte"). This will make it easier to assign code owners through GitHub. Add all members of the respective team, including the VPs as approving members.
- **Add a CODEOWNERS file**: The CODEOWNERS file can be placed in the .github directory of a repository. You can specify individuals or teams to own different parts of the code. Read the [CODEOWNER](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) docs for more information.
- **Add a branch protection:** Create a branch protection rule that targets the *main* branch. Enable the option "Require review from Code Owners" to enforce the ownership you created in the CODEOWNERS file.
- **Discord Channels:** At some companies, they have a private channel for the team to communicate and a public channel for any members of the organization to discuss changes, bugs, or raise issues. For example, say "team-latte" owns the Blueprint website. There would be a *\#team-latte* channel for the team to discuss things like assigning issues, reviewing PRs, etc. There would be also be a *\#team-latte-public* channel for any members to mention bugs or bring up potential recommendations.

##### Design Guidelines

<span style="background-color: rgb(251, 238, 184);">TODO: Design Team should review and write out these guidelines</span>

The website was designed with 3 Audiences in mind:

1. **Stevens Students**
2. **Non-Profit Organizations**
3. **Coporate Sponsors/Partners**

Assets, Color Schemes, and fonts can be found on the Figma