From 3f4d8fdd489166e819dd78ceb30a809624cb0615 Mon Sep 17 00:00:00 2001
From: Kylee Fields <43586156+kyleecodes@users.noreply.github.com>
Date: Tue, 17 Sep 2024 15:39:35 -0400
Subject: [PATCH] Docs: Update OSS community directions and env vars (#1143)

---
 .github/pull_request_template.md |  21 +--
 BLOOM_USERS.md                   |  72 +++++-----
 CONTRIBUTING.md                  | 123 ++++++----------
 CYPRESS.md                       |  69 +++------
 README.md                        | 237 ++++++++++++++++---------------
 5 files changed, 235 insertions(+), 287 deletions(-)

diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index a34818a8..a76650b1 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -1,21 +1,22 @@
-### Issue link / number:
+### Resolves #enter-issue-number
 
-### What changes did you make?
+### What changes did you make and why did you make them?
 
-### Why did you make the changes?
+### Did you run tests? Share screenshot of results:
 
-### Did you run tests?
+### How did you find us? (GitHub, Google search, social media, etc.):
 
-<!---IMPORTANT NOTE ABOUT RUNNING TESTS: ->
+<!---ABOUT RUNNING TESTS :->
+- Directions for running tests are in the README.md.
+- Tests are not required to pass. 
+- Run unit tests
+- Run Cypress tests if required for contribution.
 - Some tests may require multiple runs before success.
-- Some test failures may not be due to your contribution and can be ignored.
-- If tests fail without resolution, please let us know here.
-- Directions for running tests are in the README.md 
+- Some test failures may not be due to your contribution and can be ignored. We are always upgrading testing performance.
 
-<!--- PR CHECKLIST: PLEASE REMOVE BEFORE SUBMITTING —>
+<!--- PR CHECKLIST: —>
 Before submitting, check that you have completed the following tasks:
 - [ ] Answered the questions above.
-- [ ] Read Chayn's Contributing Guidelines in the CONTRIBUTING.md file.
 - [ ] Enabled "Allow edits and access to secrets by maintainers" on this PR.
 - [ ] If applicable, include images in the description.
 After submitting, please be available for discussion. Thank you!
diff --git a/BLOOM_USERS.md b/BLOOM_USERS.md
index 3715d01a..266afdde 100644
--- a/BLOOM_USERS.md
+++ b/BLOOM_USERS.md
@@ -1,46 +1,65 @@
-# Guide to setting up bloom users
+# Local Bloom User Set-Up Guide
 
-## Setting up a public user
+Creating local Bloom users is required for testing full functionality of Bloom and running local Cypress tests. Here are the types of Bloom users:
 
-- Go to the home page of bloom and sign up with the general user sign up flow
+- Public User (default)
+- Super Admin (public user with enhanced permissions)
+- Partner Admin (partner user with enhanced permissions)
+- Partner User (public user created through one of our partner programs)
 
-## How to set up a super admin
+### Prerequisites
 
-**Assumptions for this to work:**
+- Backend is running, and database populated with test data.
+- Frontend is runnning.
+- You have manual access to your database, either through the postgres command line or database manager, like [PGAdmin](https://www.pgadmin.org/).
 
-- You have imported the DB dump above into your database and you have a partner entry in your partner table in your database
-- You have manual access to your database through the command line or through PG Admin
+## Create Public User:
 
-**Steps**
+Run the app locally, from the home "/" page, navigate to "Getting Started with Bloom" to sign up as a new user.
 
-- Create an account that you have access to (or use one you already have)
-- Go into the database and make that user a super admin. You do this by changing the isSuperAdmin column to `true` on that user. You can do this with a statement such as
+You can verify this user was created in the database by running a query such as:
+
+```
+SELECT * from public."user" users where users."email" = '[insert email]'
+```
+
+## Create Super Admin:
+
+- Create a public user account (or use one you already have).
+- Go into the database and grant super admin permissions. You do this by changing the isSuperAdmin column to `true` on that user. You can do this with a query statement such as
 
 ```
 UPDATE public."user" users SET "isSuperAdmin" = true WHERE users."email"='[insert email here]'
 ```
 
-## How to set up a partner admin
+## Create Partner Admin:
 
-**Assumptions for this to work:**
+**Prerequisites**
 
-- you have access to a super admin user account
+- Existing super admin user account.
 
 **Steps**
 
 - Log into bloom with the super admin account
-- Go to /admin/dashboard
-- You should see a form where you can create a partner admin. You can create a partner admin account by typing a new email and selecting a partner in the drop down . Note that you can use the same email as before but just type in (+1) on the end. For example my email is test[@chayn.co](mailto:ellie@chayn.co), so I will make a new account with the same email and call it test[+1@chayn.co](mailto:ellie+1@chayn.co).
-- Once you have created the new partner admin, sign in as that partner admin. You will need to reset the password so you will need access to the email account. Note that if you used test+1@chayn.co, it will send the email to test@chayn.co.
+- Navigate to /admin/dashboard
+- Create partner users using the form:
+  - **Important:** Make sure the emails are aliases of your own email. You need access to this email to create partner admin passwords. For example, if my email was 'test@chayn.co', I need to make accounts with emails `test+bumblepartneradmin@chayn.co`, `test+badoopartneradmin@chayn.co`. You will need to reset the password through the UI as Firebase provides a random password for you.
+- Set password:
+  - Reset the passwords for both partner admin accounts. Navigate to `localhost:3000/auth/login` in the frontend UI. Click on the password reset button and reset both passwords by following the email instructions.
 
-## How to set up a partner user
+## Create Partner User:
 
-**Assumptions for this to work:**
+**Method 1. Use a partner admin**
 
-- For method 1: you have manual access to the database
-- For method 2: you have access to a partner admin user account
+- Go to Navigate to `/partner-admin/create-access-code`
+- Create an access code - you need to select the level of access. For example, select therapy if you want the user who receives this code to have access to therapy
+- Save this access code to use later.
+- Create a new account e.g. test+2@chayn.co.
+- In the top right corner you should see a profile icon. Click on it and you should see the option to “apply a code”.
+- Proceed to apply to code to your account.
+- If you have therapy access on that code, you should be able to see “Therapy” option in the nav bar
 
-**Method 1: Manual entry into the database (recommended)**
+**Method 2: Manual entry into the database**
 
 - Create a generic public user by going to the homepage and creating an account. You can re-use an existing public user if you have one already.
 - Get the userId of the user by going into the database.
@@ -64,14 +83,3 @@ VALUES ('[insert user id]', null, '[insert partner id]', true, true, 6, 0, true,
 ```
 
 - Log in as that user and see if “Therapy” is available in the nav bar.
-
-**Method 2. Use a partner admin**
-
-- Create a partner admin (see How to create a partner admin below)
-- Go to /partner-admin/create-access-code
-- Create an access code - you need to select the level of access. For example, select therapy if you want the user who receives this code to have access to therapy
-- Save this access code to use later.
-- Create a new account e.g. test+2@chayn.co.
-- In the top right corner you should see a profile icon. Click on it and you should see the option to “apply a code”.
-- Proceed to apply to code to your account.
-- If you have therapy access on that code, you should be able to see “Therapy” option in the nav bar
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index b8c0c80a..2ad062a4 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -2,55 +2,39 @@
 
 Thank you for taking the time to contribute!
 
-We ❤️ our contributors and strive to give back more than we get. Have feedback on how we can improve? Questions, insight, or other concerns? We invite you to share in our [this anonymous form](https://forms.gle/v2whmf4XX3du4Y3t9).
+Have feedback on how we can improve? Questions, insight, or other concerns? We invite you to share in our [this anonymous form](https://forms.gle/v2whmf4XX3du4Y3t9).
 
-Do you want to make a greater impact with Chayn and receive special access to our organization and volunteer opportunities? Please visit our [visit our Getting Involved Guide](https://www.chayn.co/get-involved) to get started! Don't forget to star this repository ⭐ so we can find more contributors like you!
+## Support Our Work
 
-# Table of Contents
+Chayn is proudly open-source and built with volunteer contributions. We are grateful for the generosity of the open-source community and aim to provide a fulfilling experience for open-source developers.
 
-- [Prerequisites](#prerequisites)
-- [Where Can I Get Help?](#where-can-i-get-help)
-- [What kind of contributions does Chayn want?](#what-kind-of-contributions-does-chayn-want)
-- [Chayn's Spam Policy](#chayns-spam-contribution-policy-)
-- [The Contribution Process Guide:](#the-contribution-process-guide)
-  1. [Read the README and Code of Conduct](#1-read-the-readme-and-code-of-conduct)
-  2. [Claim an Issue](#2-claim-an-issue)
-  3. [Fork the Repo and Create a New Branch](#3-fork-the-repo-and-create-a-new-branch)
-  4. [Commit Changes Using Open-Source Standards](#4-commit-changes-using-open-source-standards)
-  5. [Sync Fork if Needed](#5-sync-your-fork-if-needed)
-  6. [Push Changes to GitHub](#6-push-changes-to-github)
-  7. [Make a Pull Request to Chayn](#7--make-a-pull-request-to-chayn)
+**Please give this repository a star ⭐ and follow our GitHub profile 🙏 to help us grow our open-source community and find more contributors like you!**
+
+Support our mission further by [sponsoring us on GitHub](https://github.com/sponsors/chaynHQ), exploring our [volunteer programs](https://www.chayn.co/get-involved), and following Chayn on social media: - Linktree: [https://linktr.ee/chayn](https://linktr.ee/chayn) - Twitter: [@chaynhq](https://twitter.com/ChaynHQ) - Instagram: [@chaynhq](https://www.instagram.com/chaynhq/) - Youtube: [@chaynhq](https://www.youtube.com/@chaynhq) - Facebook: [@chayn](https://www.facebook.com/chayn) - LinkedIn: [@chayn](https://www.linkedin.com/company/chayn).
 
 # Prerequisites
 
-If you are new to GitHub and git version control, here are some resources to help you get started:
+- Git version control
+- a GitHub account
+
+**Additional Guidance:**
 
 - [Getting Started with First Time Git Setup](https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup)
 - [Learn the GitHub Flow](https://docs.github.com/en/get-started/quickstart/github-flow)
 - [Git Basic Branching & Merging Guide](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging)
 - [How to Collaborate with Pull Requests](https://docs.github.com/en/github/collaborating-with-pull-requests)
-- [Git Cheatsheet](https://education.github.com/git-cheat-sheet-education.pdf) _(we highly recommend saving this for future reference!)_
-
-Here are prerequisites you should meet before contributing to Chayn's GitHub:
-
-- git version control configuration
-- a GitHub account
-- fundamental knowledge of the GitHub and git version control flow (fork, clone, push, commit, branches, etc.)
+- [Git Cheatsheet](https://education.github.com/git-cheat-sheet-education.pdf) _(we highly recommend)_
 
-**It is not required that you have experience contributing to open-source projects on GitHub!** Chayn aims to be a safe space for contributors of all skill-levels to build their skills while making an impact in digital public goods. If this is your first contribution, we recommend saving the cheatsheet linked above for future reference, learning how to navigate the GitHub and git version control docs, and in general -- _learn as you go._ The Chayn team is here to help. You got this! 💪
+**Previous open-source experience not required.** If this is your first contribution, we recommend saving the cheatsheet linked above for future reference, learning how to navigate the GitHub and git version control docs, and in general -- _learn as you go._ Happy coding! 💪
 
 # Where can I get help?
 
-Chayn maintainers and developers are here to help! We aim to give a safe space for contributors of all skill levels to build their skills while making an impact. 🤝
-
 You can ask Chayn team members questions at any point during your contribution in the following places on GitHub:
 
 - Issue discussions in an issue you're assigned to or interested in.
 - Pull request discussions for your contribution.
 - Or, create a new issue with the `type: question / suggestion` label.
 
-Chayn team members usually respond within 3 business days.
-
 # What kind of contributions does Chayn want?
 
 Chayn is open to all kinds of contributions, such as:
@@ -61,7 +45,7 @@ Chayn is open to all kinds of contributions, such as:
 - accessibility and language support.
 - no-code (documentation, translations) \*see spam policy below for accepted documentation changes.
 
-# Chayn's Spam Contribution Policy 🚫
+# Chayn's Spam Policy 🚫
 
 **Chayn will reject contributor pull requests if they are defined as spam or not associated with an issue.**
 All pull requests need to be associated with an issue. If you open a pull request without claiming an issue, you will be asked to create an issue for your pull request.
@@ -75,6 +59,22 @@ Documentation contributions will only be accepted under these circumstances:
 
 Unwanted documentation changes, such as summarizations, white space edits, or minor grammatical edits will be DENIED (unless there is evidence provided that these changes are for accessibility).
 
+# Issue Policies
+
+### Issue Limit Policy:
+
+To ensure we give a fair opportunity to everyone, Chayn maintainers may limit the number of issues you can be assigned. This allows us to manage our open-source contributions at a sustainable pace and ensure there are always open issues for everyone.
+
+- **Only 1 issue of a specific complexity level in a single repository may be assigned to a contributor at a time.** To be assigned another, you must complete or close your previous issue. For example, a contributor can have 1 beginner issue, 1 intermediate issue, and 1 complex issue open in a single repository at a time. But they cannot have 3 beginner issues open, or 2 intermediate issues open at once in a single repository.
+- **Beginner issues may be capped** at any time to reserve for current events, such as volunteer programs or Hacktoberfest.
+
+### Abandoned Contribution Policy:
+
+We understand that life happens! If you can no longer finish a contribution, please comment to let us know so we can swiftly reassign.
+
+- After 60 days of no activity, your issue or pull request will be labeled `stale` and you will be prompted to respond in the discussions.
+- If there is no response, we will unassign the issue and close your pull request.
+
 # The Contribution Process Guide
 
 ### Directions for Contributing to Chayn:
@@ -93,62 +93,35 @@ First, read the project's [README](/README.md) for project-specific directions o
 
 Contributing means you have agreed to our [Code of Conduct](/CODE_OF_CONDUCT.md).
 
-**Note: For no-code contributors,** if you are editing the `README` file or any other markdown / text files, it is NOT required to set up environment variables, run the app locally, and pass tests. You can make your changes entirely in the GitHub UI (in the web browser) after forking the Chayn repository you are working on and creating a new feature branch.
-
 ## 2. **Claim an Issue:**
 
 To claim an issue, either create an issue to be assigned to OR ask to be assigned an existing issue.
 
 - If multiple people ask to be assigned before a Chayn maintainer can respond, the person who asked first will be assigned.
 
-- Multiple people are welcome to collaborate on a single issue.
-
-**Important!: All pull requests MUST be associated with a claimed issue. We may deny your pull request if it is not associated with an issue that you're assigned to. Please make sure you are assigned an issue BEFORE making your contribution.**
+- Multiple people are allowed to collaborate on a single issue.
 
 ### Create Issue:
 
 Have an idea for a contribution? Create your own!
 For more guidance see [GitHub Docs: Creating an Issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue).
 
-Steps to create an issue to be assigned to:
-
-1. Check that your issue doesn't already exist.
-2. Follow our issue templates for creating new issues.
-3. If your issue is complex, consider breaking it into multiple smaller issues.
-4. Ask to be assigned your issue in the discussion.
-
-See [What kind of contributions does Chayn want?](#what-kind-of-contributions-does-chayn-want) for contribution ideas.
-
 ### Claim Existing Issue:
 
-To claim an existing issue, comment in the discussions and ask to be assigned. Ideally you should tag the issue author / Chayn team member.
+To claim an existing issue, comment in the discussions tag the issue author / Chayn team member to be assigned.
 
 ### How to Select Issues:
 
-Scan our issue `labels` to find issues that suit you:
+Scan our issue labels to find issues that suit you:
 
-- The `good first issue` and `first-timers-friendly` labels are best for new contributors.
-- The `help wanted` label indicates that Chayn is inviting contributors to help. While contributors can contribute to any unassigned issue, issues with this label are specifically looking for help outside of Chayn's dev team.
-- The `complexity: beginner` label is for issues that take less than 1 day to complete, and require little to no prior experience with the codebase.
-- The `complexity: moderate` label is for issues that may take 1-2 days to complete, and will require some knowledge of the codebase.
-- The `complexity: advanced` is for issues that may take more time, possibly 3+ days. These will require more in-depth knowledge of the codebase. **Contributors are strongly encouraged to report progress while working on complex issues.**
+- `good first issue` and `first-timers-friendly` labels are best for new contributors.
+- `help wanted` label indicates that Chayn is inviting contributors to help. While contributors can contribute to any unassigned issue, issues with this label are specifically looking for help outside of Chayn's dev team.
+- `complexity: beginner` label is for issues that take less than 1 day to complete, and require little to no prior experience with the codebase.
+- `complexity: moderate` label is for issues that may take 1-2 days to complete, and will require some knowledge of the codebase.
+- `complexity: advanced` is for issues that may take more time, possibly 3+ days. These will require more in-depth knowledge of the codebase. **Contributors are strongly encouraged to report progress while working on complex issues.**
 
 We suggest starting with issues labeled `good first issue` or `complexity: beginner` to get comfortable with the codebase before moving onto more complex issues.
 
-### Issue Limit Policies
-
-**To ensure we give a fair opportunity to everyone, Chayn maintainers may limit the number of issues you can be assigned.** This allows us to manage our open-source contributions at a sustainable pace and ensure there are always open issues for everyone.
-
-- **Only 1 issue of a specific complexity level in a single repository may be assigned to a contributor at a time.** To be assigned another, you must complete or close your previous issue. For example, a contributor can have 1 beginner issue, 1 intermediate issue, and 1 complex issue open in a single repository at a time. But they cannot have 3 beginner issues open, or 2 intermediate issues open at once in a single repository.
-- **Beginner issues may be capped** at any time to reserve for current events, such as volunteer programs or Hacktoberfest.
-
-### Abandoned Contribution Policy:
-
-We understand that life happens! **If you can no longer finish a contribution, please comment to let us know so we can swiftly reassign.**
-
-- After 60 days of no activity, your issue or pull request will be labeled `stale` and you will be prompted to respond in the discussions.
-- If there is no response, we will unassign the issue and close your pull request.
-
 ## 3. **Fork the Repo and Create a New Branch:**
 
 First, read the **Git Flow and Deployment** section in your project's `README` file to learn of any project-specific requirements. Generally, the git flow is the same among all repositories, however, each project may slightly vary.
@@ -204,8 +177,6 @@ Whether you are a beginner developer or experienced, we recommend all contributo
 3. **Run linters** to properly format your code before making commits. Directions for running linters are in the repository's `README` file.
 4. **Run tests and check that they pass.** Directions for running tests are in the repository's `README` file.
 
-   **Important Note about Tests:** We are currently making upgrades to our products performances. Therefore, some tests may need to be ran multiple times before they pass, and some may not pass at all. We recommend frequently running tests as you make code changes, then at your own discretion, deciding which tests fail due to your code changes, and fixing them so that they pass. Please reach out to Chayn staff in issue discussions if you encounter any issues with tests. Thank you for your patience!
-
 5. **Check that no secrets (sensitive API keys and environment variables) and no unwanted, irrelevant files are commited.** Everything you commit to Chayn will be public, please be vigilant about not commiting sensitive information. Be sure to update `.gitignore` as needed, making sure to clean the `.gitignore` cache whenever new files are added to it. Learn more about properly using the `.gitignore` file to ignore specific files in this GitHub guide: [Ignoring Files Guide](https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files).
 
 6. **Write readable commit messages** as demonstrated below:
@@ -243,8 +214,6 @@ Fix bug preventing users from submitting the subscribe form
 fixed bug on landing page
 ```
 
-**Note: While following these directions perfectly is not expected, Chayn maintainers may ask you to implement these standards during your pull request review.**
-
 ## 5. **Sync Your Fork if Needed:**
 
 If the default branch of the Chayn repository you forked from has been updated (referred to as the "upstream repository"), it is recommended to keep your forked repository up to date with these changes.
@@ -255,32 +224,26 @@ Navigate to the GitHub UI (in the web browser) and view your forked repository,
 
 ### How Do I Update my Fork?
 
-**We highly recommend referring to this guide in GitHub's docs on how to sync your fork: [GitHub Docs: Syncing Your Fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).** You can sync your fork using the GitHub UI (web browser), command line, or GitHub's CLI by following the directions in the GitHub Docs.
-
-In addition to following the guide linked above, always make sure that your default branch is up-to-date first _before_ your feature branch. After syncing your default branch with the upstream, then **merge** those updates into your feature branch.
-
-Next, verify that the git history on your feature branch is correctly synced with the upstream. One way to do this is to use the `git log` command to check commit history. In your feature branch history, you should see the updated commits pulled from upstream, then your new commits, followed by a merge commit.
+**We recommend this GitHub guide on how to sync your fork: [GitHub Docs: Syncing Your Fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).** You can sync your fork using the GitHub UI (web browser), command line, or GitHub's CLI by following the directions in the GitHub Docs.
 
-Finally, please resolve any merge conflicts by manually editing the conflicting files and deciding how the conflicting changes should be merged. You can refer to the resources linked below for more guidance on how to handle merge conflicts.
+We recommend making sure that your default branch is up-to-date first _before_ your feature branch. After syncing your default branch with the upstream, then **merge** those updates into your feature branch. Next, verify the git history on your feature branch is correctly synced with the upstream. One way to do this is to use the `git log` command to check commit history. In your feature branch history, you should see the updated commits pulled from upstream, then your new commits, followed by a merge commit. Finally, please resolve any **merge conflicts** by manually editing the conflicting files and deciding how the conflicting changes should be merged.
 
-**For more guidance on updating forks, read the following guides:**
+**Additional Guidance:**
 
 - [GitHub Docs: About Merge Methods](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github)
 - [GitHub Docs: Resolving Merge Conflicts on GitHub](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github)
 - [GitHub Docs: Configuring a Remote Repo for a Fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-repository-for-a-fork)
 - [FreeCodeCamp: How to Sync Your Fork with the Original Git Repo](https://www.freecodecamp.org/news/how-to-sync-your-fork-with-the-original-git-repository/)
 
-**Note: We understand merge conflicts can feel scary for new devs! While we encourage contributors to update their forks prior to pull request, please do not hesitate to submit a pull request despite fork syncing issues or merge conflicts. If you have any questions or concerns, please let Chayn maintainers know in GitHub. Chayn maintainers are here to help!**
-
 ## 6. **Push Changes to GitHub:**
 
 **Before pushing changes to GitHub, please check that you have followed the standards listed in the [Commit Changes Using Open-Source Standards](#4-commit-changes-using-open-source-standards) section of this document.**
 
-In addition to following the best practices listed here, we ask that you **carefully ensure** that there are **no secrets and unwanted files being pushed.**
+We ask that you **carefully ensure** that there are **no secrets and unwanted files being pushed.**
 
 We recommend using the `git status` command to verify that the right files are being pushed.
 
-**For more guidance on pushing changes to GitHub, read the following guides:**
+**Additional Guidance:**
 
 - [Git Docs: git-status command](https://git-scm.com/docs/git-status)
 - [Git Docs: git push command](https://github.com/git-guides/git-push)
@@ -290,8 +253,6 @@ We recommend using the `git status` command to verify that the right files are b
 
 For a more in-depth guide on creating pull requests, please refer to this guide in the GitHub Docs: [Creating a Pull Request Guide](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request). We recommend opening a pull request in the GitHub UI (GitHub in the web browser.)
 
-**Important Note: Check that you are forking against the correct default branch in the upstream Chayn repository. While GitHub _should_ automatically fork against the default branch, if the default branch is not called `main` (some Chayn repositories use the `develop` branch as the default), GitHub is known to accidentally fork against main instead of the correct default branch. However, this is not a common issue.**
-
 **Next, complete the tasklist in the pull request template.** This is a brief tasklist that is only viewable when creating a pull request.
 
 Finally, submit your pull request, and be available for discussions that may arise and to make [suggested changes](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/incorporating-feedback-in-your-pull-request) that may be required before merging.
diff --git a/CYPRESS.md b/CYPRESS.md
index b657510b..d1f2e02f 100644
--- a/CYPRESS.md
+++ b/CYPRESS.md
@@ -1,72 +1,41 @@
 # Cypress Testing Guide
 
-Currently, integration tests are set up to be run locally with Chrome. When cypress runs in github actions in the CI flow, it runs against staging backend.
+### Prerequisites
 
-## Setup
+- Chrome internet browser (or Chromium with 'chrome' alias on Linux).
+- Backend is running, and database populated with test data.
+- Frontend is runnning, must be on `localhost:3000` port.
 
-First, create a local `cypress.env.json` file (this file is in `.gitignore` and will be ignore by git) and populate it with environment variables listed in the `cypress.env.example.json` file. Next, configure these variables using in our [Chayn Tech Wiki Guide](https://www.notion.so/chayn/Chayn-Tech-Contributor-Wiki-5356c7118c134863a2e092e9df6cbc34?pvs=4#1e51da106e1a484baf1429a04be71388).
+### Summary
 
-To configure the login credential variables in your database, first you need to create a super admin user in your database:
+We use [Cypress](https://learn.cypress.io/) for integration testing and [MailSlurp](https://www.mailslurp.com/) for email tesitng. Integration tests run locally with Chrome. In GitHub Action CI workflows, it runs against the staging backend. Cypress tests require the frontend running on `localhost:3000` port and backend running with populated database.
 
-1. Create a public user through the UI.
-2. In the database in `bloom-backend` you will need to set "isSuperAdmin" column to true for the user you created. See [BLOOM_USERS.md](/BLOOM_USERS.md) for steps on how to set up different users.
-3. There are 2 ways of data seeding with users. 1 is via a script in the bloom-scripts repo. Or 2 creating users through the UI (recommended).
+## Set-Up:
 
-   #### Creating users with the UI (Recommended):
+To set-up, configure the Cypress variables in `env.local`.
 
-   - ensure your `bloom-backend` is running.
-   - create a public user through the UI by navigating to the '/' home page and following instructions to create a user.
-   - To create partner admin users, log in as the super admin you created. Go to /admin/dashboard and create 1 bumble user and 1 badoo user. Make sure the emails are aliases of your own email. For example, if my email was 'test@chayn.co', I need to make accounts with emails `test+bumblepartneradmin@chayn.co`, `test+badoopartneradmin@chayn.co`. You will need to reset the password through the UI for both of these as firebase provides a random password for you.
+1. For `CYPRESS_PROJECT_ID`: [Get started with Cypress](https://docs.cypress.io/guides/cloud/getting-started) and use your [Cypress project ID](https://docs.cypress.io/guides/cloud/account-management/projects).
+2. For `CYPRESS_MAIL_SLURP_API_KEY` and `CYPRESS_INBOX_ID`: Create a [Mailslurp account](https://www.mailslurp.com/), navigate to your dashboard to obtain the API key, then [create an Mailslurp inbox](https://docs.mailslurp.com/inboxes/).
+3. For local Bloom Users: Create local Bloom users from your local frontend. You will need a public user, a super admin user, and 2 partner admin users. Directions in [BLOOM_USERS.md](/BLOOM_USERS.md).
 
-   #### Creating users with a script:
+For additional guidance setting up Cypress environemnt variables, check out our [Chayn Tech Wiki Guide](https://www.notion.so/chayn/Chayn-Tech-Contributor-Wiki-5356c7118c134863a2e092e9df6cbc34?pvs=4#1e51da106e1a484baf1429a04be71388).
 
-   - You will need to pull the [bloom-scripts repo](https://github.com/chaynHQ/bloom-scripts). This repo contains scripts for data seeding public and partner admin users. Note that you can also perform
-   - You will need the `bloom-backend/cypress-setup.ts` in the the bloom scripts repo.
-   - There are a few environment variables that you will need to get.
-
-     - URL - this is the url of your bloom-backend service so will likely be `http://localhost:35001/api`
-     - TOKEN - this needs to be a token with super admin authentication. The way you get this token is to log in as the super admin user in the UI. Go to the Network tab in the developer tools (this is for chrome users). Look for authenticated requests to the backend. A good one to use is the user/me endpoint. In the network tab it usually comes up as `me`. Click on the request and look at the request headers. In particular, look for the authorisation header. This should look like `bearer 123dsdfljkdbfksndfg;ksndg`. Copy everything that is after the `bearer ` into your .env TOKEN variable.
-     - BUMBLE_PARTNER_ID - you should be able to get this ID from your database in the `partner` table
-     - BADOO_PARTNER_ID - you should be able to get this ID from your database in the `partner` table
-     - CYPRESS_TEMPLATE_EMAIL - this needs to be your email because you will need to reset passwords in the UI. To be able to reset passwords, you need the reset email to go into your inbox. The script will generate alias email addresses for all the Cypress template users. For example - my email is `test@chayn.co`. The accounts that will be created will be under `test+publicuser@chayn.co`, `test+bumblepartneradmin@chayn.co`, `test+badoopartneradmin@chayn.co`.
-     - CYPRESS_TEMPLATE_PASSWORD - this will be the password for all test accounts created.
-     - run the script with `npm run setup-cypress`.
-
-### Finish Cypress Variable Configuration
-
-- You will have created all the accounts needed to run cypress tests.
-- You will need to reset the passwords for both partner admin accounts. Navigate to `localhost:3000/auth/login` in the frontend UI. Click on the password reset button and reset both passwords by following the instructions.
-- You now will need to populate the cypress.env.json with the information below:
-
-```
-  "bumble_partner_admin_email": "",
-  "bumble_partner_admin_password": "",
-  "badoo_partner_admin_email": "",
-  "badoo_partner_admin_password": "",
-  "super_admin_email": "",
-  "super_admin_password": "",
-  "public_email": "",
-  "public_password": "",
-```
-
-- The environment is now ready to run the tests.
-
-## Run the Tests Locally
+## Run Tests:
 
 To run the tests, follow the instructions below:
 
-1. Ensure both bloom backend and bloom front-end are running locally.
-2. Ensure the local database contains users with emails matching those in the `cypress.env.json` file.
+1. Ensure prerequisites are met.
+2. Ensure the local database contains users with emails matching those in the `env.local` file.
 3. Ensure Chrome is available on your local machine.
-4. Run the command `yarn cypress` on your terminal.
+4. Run the command `yarn cypress` on your terminal to run tests in the browser.
+   - To run a faster, head-less version of the tests (i.e. no visible browser), use the command `yarn cypress:headless`.
+   - Run single tests at a time by running `./node_modules/.bin/cypress run --spec cypress/integration/example_test_PATH.cy.tsx`
 5. Cypress will now open a new screen displaying the available test (this may take upto a minute the first the command runs).
 6. Click on the test you'd like to run. This will open another Chrome window and the chosen test will now run.
 
-The above option will run the tests against a visible browser. To run a head-less version of the tests (i.e. no visible browser), use the command `yarn cypress:headless`. The headless cypress runs will be faster as the browser elements are not visible.
-
 ## Test Coverage
 
-After all tests have been run using `yarn cypress:headless`, a code coverage report can be generated by running `yarn cypress:coverage`. This will generate two reports:
+A code coverage report can be generated by running `yarn cypress:coverage`. This will generate two reports:
 
 1. A coverage summary in the terminal
 2. An `index.html` page found in `./coverage` which provides details of what lines of code have or have not been covered by tests, and can be viewed in a browser
diff --git a/README.md b/README.md
index 0e857912..77705b6e 100644
--- a/README.md
+++ b/README.md
@@ -2,37 +2,28 @@
 
 [![Bloom CI Pipeline](https://github.com/chaynHQ/bloom-frontend/actions/workflows/build-and-test-prs.yml/badge.svg)](https://github.com/chaynHQ/bloom-frontend/actions/workflows/build-and-test-prs.yml)
 
-**Currently in active development.**
+Bloom is a remote trauma support service from [Chayn](https://www.chayn.co/about), a global, award-winning charity designing open-source tools to support the healing of survivors across the world. Since 2013, Chayn has reached over 500,000 survivors worldwide with our trauma-informed, survivor-centred, and intersectional approaches in utilizing tech for social impact. Bloom is our flagship product; a free, web-based, secure support service designed to aid in the healing of survivors. Through a combination of online video-based courses, anonymous interaction, and 1:1 chat, Bloom provides tailored information, self-help guidance, everyday tools, and comfort to cope with traumatic events.
 
-Bloom is a remote trauma support service from Chayn, a global charity supporting survivors of abuse across borders. Bloom is our flagship product; a free, web-based support service designed for anyone who has experienced or is currently experiencing domestic or sexual abuse. Through a combination of online video-based courses, anonymous interaction and 1:1 chat, Bloom aims to provide tailored information, guidance, everyday tools, and comforting words to cope with traumatic events. 💖
+Explore Chayn's [website](https://www.chayn.co/about), [research](https://org.chayn.co/research), [resources](https://www.chayn.co/resources), [projects](https://org.chayn.co/projects), [impact](https://org.chayn.co/impact), and [support services directory](https://www.chayn.co/global-directory). 💖
 
-For a more detailed explanation of this project's key concepts and architecture, please visit the [/docs directory](https://github.com/chaynHQ/bloom-frontend/tree/develop/docs).
+## Support Our Work
 
-## Get Involved
+Chayn is proudly open-source and built with volunteer contributions. We are grateful for the generosity of the open-source community and aim to provide a fulfilling experience for open-source developers.
 
-Do you want to make an impact with Chayn and receive special access to our organization and volunteer opportunities? Please visit our [Getting Involved Guide](https://www.chayn.co/get-involved) to get started!
+**Please give this repository a star ⭐ and follow our GitHub profile 🙏 to help us grow our open-source community and find more contributors like you!**
 
-Other ways you can support Chayn are [donating](https://www.paypal.me/chaynhq), starring this repository ⭐ (so we can find more contributors like you!), making an open-source contribution, and supporting us on social media!
+Support our mission further by [sponsoring us on GitHub](https://github.com/sponsors/chaynHQ), exploring our [volunteer programs](https://www.chayn.co/get-involved), and following Chayn on social media: - Linktree: [https://linktr.ee/chayn](https://linktr.ee/chayn) - Twitter: [@chaynhq](https://twitter.com/ChaynHQ) - Instagram: [@chaynhq](https://www.instagram.com/chaynhq/) - Youtube: [@chaynhq](https://www.youtube.com/@chaynhq) - Facebook: [@chayn](https://www.facebook.com/chayn) - LinkedIn: [@chayn](https://www.linkedin.com/company/chayn).
 
-Find us online:
+# Bloom Frontend Contribution Docs:
 
-- Website: [https://www.chayn.co/](https://www.chayn.co/)
-- Linktree: [https://linktr.ee/chayn](https://linktr.ee/chayn)
-- Twitter: [@ChaynHQ](https://twitter.com/ChaynHQ)
-- Instagram: [@chaynhq](https://www.instagram.com/chaynhq/)
-- Youtube: [Chayn Team](www.youtube.com/@chaynhq)
-- LinkedIn: [@chayn](https://www.linkedin.com/company/chayn)
-
-# Contributing to Bloom Frontend
-
-Before making a contribution, please read our Contributing Guidelines in the [CONTRIBUTING.md](/CONTRIBUTING.md) file.
-
-We ask all contributors to follow our [Contributing Guidelines](/CONTRIBUTING.md) to help Chayn developers maintain open-source best practices.
+By making an open-source contribution to Chayn, you have agreed to our [Code of Conduct](/CODE_OF_CONDUCT.md).
 
 Happy coding! ⭐
 
 ## Technologies Used
 
+Visit the [/docs directory](https://github.com/chaynHQ/bloom-frontend/tree/develop/docs) for an overview of Bloom's frontend key concepts.
+
 - [React](https://reactjs.org/) - JavaScript library for building component based user interfaces
 - [Next.js](https://nextjs.org/) - React framework for hybrid static & server rendering, file-system routing and more
 - [Vercel](https://vercel.com/) - Build, deploy and host staging and production apps
@@ -48,114 +39,153 @@ Happy coding! ⭐
 - [GitHub Actions](https://github.com/features/actions) - CI pipeline
 - [Jest](https://jestjs.io/) - Unit testing.
 - [Cypress](https://www.cypress.io/) - End-to-end testing.
+- [ESLint](https://eslint.org/) and [Prettier](https://prettier.io/) for linting and formatting.
+
+## Local Development:
+
+### Summary
+
+To run Bloom's frontend: install prerequisites, run Bloom's backend locally, configure environment variables, install dependencies, then run the app locally with yarn.
+
+Before running Cypress integration tests, first populate your backend local database with test data ([directions in Bloom's backend repo](https://github.com/chaynHQ/bloom-backend?tab=readme-ov-file#populate-database)).
 
 ## Prerequisites
 
 - NodeJS 20.x
 - Yarn v1.x
-
-## Local Development:
+- Read [Contribution Guidelines](/CONTRIBUTING.md)
 
 ### Run Local Backend
 
-See [bloom-backend](https://github.com/chaynHQ/bloom-backend) for instructions.
-You will need to run this in the background for the frontend to be functional.
+See [Bloom's backend repo](https://github.com/chaynHQ/bloom-backend) for instructions. You will need to run this in the background for the frontend to be functional.
 
 ### Configure Environment Variables
 
-- **For Chayn staff:** You can import all environment variables from Vercel. Please get in touch with the team for environment variables and access to Vercel. If you already have access, you may proceed to the [Vercel Environment Variable Import](#vercel-environment-variable-import) directions.
-
-- **For open-source contributors:** create a `env.local` file and populate it with **required** variables below. Required variables are needed to run the app, optional variables are for specific features. To configure the Firebase variables, [create a Firebase project in the Firebase console](https://firebase.google.com/) (Google account required). Next, obtain the Storyblok token from our [Chayn Tech Wiki Guide](https://chayn.notion.site/Chayn-Tech-Contributor-Wiki-5356c7118c134863a2e092e9df6cbc34?pvs=4). Additionally, while New Relic variables are not required to run the app, not including them prints lengthy warnings. To prevent this, set the New Relic variables as provided in the [Chayn Tech Wiki Guide](https://chayn.notion.site/Chayn-Tech-Contributor-Wiki-5356c7118c134863a2e092e9df6cbc34?pvs=4).
-
-  Note: Variables provided by Chayn are public, not linked to production, and subject to change at any time. Check for updates if you are experiencing problems. The absence of some optional environment variables may result in test failures. If you require an optional environment variable and cannot acquire it yourself (some must be connected to Chayn in some way), please reach out to the team in GitHub’s issue discussions.
-
-See the the [Chayn Tech Wiki Guide](https://chayn.notion.site/Chayn-Tech-Contributor-Wiki-5356c7118c134863a2e092e9df6cbc34?pvs=4) for more info.
+Create a new `.env.local` file and fill it with the required environment variables:
 
 ```
-# --- REQUIRED ---
+# Variables for building, unit tests, and integration tests.
+# Provided variables are read-only and subject to change.
+#====================================================================
+# REQUIRED VARIABLES FOR LOCAL DEVELOPMENT
+#--------------------------------------------------------------------
+# CORE ENVIRONMENT VARIABLES
 NEXT_PUBLIC_ENV=local
 NEXT_PUBLIC_API_URL=http://localhost:35001/api/v1
 NEXT_PUBLIC_BASE_URL=http://localhost:3000
-NEXT_PUBLIC_STORYBLOK_TOKEN= # provided in Chayn Tech Wiki Guide.
+NEXT_PUBLIC_PORT=3000
 
+# FIREBASE AUTH AND ANALYTICS
 NEXT_PUBLIC_FIREBASE_API_KEY=
 NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN=
 NEXT_PUBLIC_FIREBASE_PROJECT_ID=
 NEXT_PUBLIC_FIREBASE_STORAGE_BUCKET=
 NEXT_PUBLIC_FIREBASE_MESSAGING_SENDER_ID=
 NEXT_PUBLIC_FIREBASE_APP_ID=
-NEXT_PUBLIC_FIREBASE_MEASUREMENT_ID= # enables Google Anayltics in Firebase project
-
-# --- OPTIONAL ---
-NEW_RELIC_APP_NAME=  # provided in Chayn Tech Wiki Guide.
-NEW_RELIC_LICENSE_KEY=  # provided in Chayn Tech Wiki Guide.
-
-NEXT_PUBLIC_CRISP_WEBSITE_ID= # user messaging
-NEXT_PUBLIC_SIMPLYBOOK_WIDGET_URL= # booking session forms
-NEXT_PUBLIC_HOTJAR_ID= # UX analytics
-NEXT_PUBLIC_ZAPIER_WEBHOOK_DEMO_FORM= # user data form webhooks
-NEXT_PUBLIC_ZAPIER_WEBHOOK_SETA_FORM= # user data form webhooks
+NEXT_PUBLIC_FIREBASE_MEASUREMENT_ID=
+
+# CONTENT TOKEN
+NEXT_PUBLIC_STORYBLOK_TOKEN=xB5HoaLRkYs8ySylSUnZjQtt
+
+# FEATURE FLAGS
+NEXT_PUBLIC_FF_USER_RESEARCH_BANNER=true
+
+# REQUIRED VARIABLES FOR CYPRESS INTEGRATION TESTING
+# SEE CYPRESS.MD FOR INSTRUCTIONS
+#--------------------------------------------------------------------
+# CYPRESS PROJECT
+CYPRESS_PROJECT_ID=
+
+# MAILSLURP
+CYPRESS_MAIL_SLURP_API_KEY=
+CYPRESS_INBOX_ID=
+
+# LOCAL BLOOM USERS
+CYPRESS_SUPER_ADMIN_EMAIL=
+CYPRESS_SUPER_ADMIN_PASSWORD=
+CYPRESS_PUBLIC_NAME=
+CYPRESS_PUBLIC_EMAIL=
+CYPRESS_PUBLIC_PASSWORD=
+CYPRESS_BUMBLE_PARTNER_ADMIN_EMAIL=
+CYPRESS_BUMBLE_PARTNER_ADMIN_PASSWORD=
+CYPRESS_BADOO_PARTNER_ADMIN_EMAIL=
+CYPRESS_BADOO_PARTNER_ADMIN_PASSWORD=
+
+# OPTIONAL VARIABLES
+#--------------------------------------------------------------------
+# NEW RELIC TRACKING
+NEW_RELIC_LICENSE_KEY=eu01xx6fc63a14eea79c367dfe82e702FFFFNRAL
+NEW_RELIC_APP_NAME=bloom-frontend
+NEW_RELIC_BROWSER_MONITORING_KEY=NRJS-0f9d5f21ee9234a45cc
+
+# ANALYTICS
+NEXT_PUBLIC_HOTJAR_ID=
+NEXT_PUBLIC_GOOGLE_TAG_MANAGER_ID=
+
+# ADDITIONAL FEATURES
+NEXT_PUBLIC_CRISP_WEBSITE_ID= # User messaging
+NEXT_PUBLIC_SIMPLYBOOK_WIDGET_URL= # Booking session forms
+NEXT_PUBLIC_ZAPIER_WEBHOOK_DEMO_FORM= # User data form webhooks
+NEXT_PUBLIC_ZAPIER_WEBHOOK_SETA_FORM= # User data form webhooks
+NEXT_PUBLIC_ROLLBAR_ENV= # Rollbar logging
+NEXT_PUBLIC_ROLLBAR_TOKEN= # Rollbar logging
 ```
 
-#### Vercel Environment Variable Import:
+#### How to Configure Firebase Variables:
 
-For Chayn staff only -- if you have access to Vercel as a staff member, follow the instructions below. If you do not have access, please proceed past this section.
+To configure the Firebase variables, [create a Firebase project in the Firebase console](https://firebase.google.com/) (Google account required). For additional guidance on setting environment variables, check out our [Chayn Tech Wiki Guide](https://www.notion.so/chayn/Chayn-Tech-Contributor-Wiki-5356c7118c134863a2e092e9df6cbc34?pvs=4#bf62b5dcdb43496ea16231ff1815298b).
 
-Environment variables are defined and stored in Vercel for each of the environments: development, preview and production. Read more about Vercel environment variables [here](https://vercel.com/docs/concepts/projects/environment-variables). These environment variables can be imported using the Vercel CLI.
+#### How to Create New Environment Variables:
 
-Download and login to the Vercel CLI:
+If creating new environment variables, please tag Chayn staff developers in PR / issue discussions to let us know. New environment variables may require being added to Vercel (required for production-level variables) and GitHub Actions (required for app to build and pass CI tests). Note: Environment variables that are exposed to the client/browser must be prefixed with `NEXT_PUBLIC_` - see [next.js docs](https://nextjs.org/docs/basic-features/environment-variables#exposing-environment-variables-to-the-browser).
 
-```bash
-npm i -g vercel
-vercel login
-```
+#### Additional Helper Environment Variables (optional):
 
-Link the Vercel project to your local directory:
+- `FF_DISABLED_COURSES`: This feature flag is intended to remove courses from the users course home page. Note that this does not prevent the user from accessing the course completely - the user may still be able to access the course if they navigate to the URL.
 
-```bash
-vercel link
-
-# copy these answers
-Vercel CLI 24.1.0
-? Set up “~/yourpath/bloom-frontend? [Y/n] y
-? Which scope should contain your project? Chayn
-? Found project “chaynhq/bloom-frontend”. Link to it? [Y/n] y
-✅  Linked to chaynhq/bloom-frontend (created .vercel)
-```
+  In terms of use, the variable could be used to disable a course when it has not been translated to a particular language e.g. if the `healing-from-sexual-trauma/` course is ready in English but not in French, then the course can be enabled in storyblok but still disabled in french. To do this, the the french url slug `fr/courses/healing-from-sexual-trauma/` should be included in the environment variable. This means the course will be hidden in the French version of bloom but still visible to the English version of bloom. If multiple courses need to be disabled, the slugs will need to be separated by commas.
 
-Download the local environment variables files from Vercel:
+- `NEXT_PUBLIC_FF_USER_RESEARCH_BANNER`: This feature flag enables a banner which displays a banner message aimed to gathering users for Bloom feedback. It is intended to be turned on temporarily, for saw 1-2 weeks at a time. It links to an external form which users can fill out if they would like to take part in research.
 
-```bash
-vercel env pull .env.local
-```
+#### How to Import Environment Variables with Vercel (Chayn team only):
 
-#### Creating New Environment Variables:
+- Chayn staff can import all environment variables from Vercel. Ask the team for access, then proceed to the [Vercel Environment Variable Import](#vercel-environment-variable-import) for directions. Environment variables are defined and stored in Vercel for each of the environments: development, preview and production. Read more about Vercel environment variables [here](https://vercel.com/docs/concepts/projects/environment-variables). These environment variables can be imported using the Vercel CLI.
 
-When creating new environment variables, for use in production, they must be added to Vercel before release. Please tag staff in your issue if creating new environment variables for production. Additionally, new environment variables that are required for the app to build and pass tests must be added to GitHub Secrets and workflows.
+  Download and login to the Vercel CLI:
 
-Note: Environment variables that are exposed to the client/browser must be prefixed with `NEXT_PUBLIC_` - see [next.js docs](https://nextjs.org/docs/basic-features/environment-variables#exposing-environment-variables-to-the-browser).
+  ```bash
+  npm i -g vercel
+  vercel login
+  ```
 
-#### Additional Environment Variables:
+  Link the Vercel project to your local directory:
 
-These additional environment variables are optional:
+  ```bash
+  vercel link
 
-- `FF_DISABLED_COURSES`: This feature flag is intended to remove courses from the users course home page. Note that this does not prevent the user from accessing the course completely - the user may still be able to access the course if they navigate to the URL.
+  # copy these answers
+  Vercel CLI 24.1.0
+  ? Set up “~/yourpath/bloom-frontend? [Y/n] y
+  ? Which scope should contain your project? Chayn
+  ? Found project “chaynhq/bloom-frontend”. Link to it? [Y/n] y
+  ✅  Linked to chaynhq/bloom-frontend (created .vercel)
+  ```
 
-  In terms of use, the variable could be used to disable a course when it has not been translated to a particular language e.g. if the `healing-from-sexual-trauma/` course is ready in English but not in French, then the course can be enabled in storyblok but still disabled in french. To do this, the the french url slug `fr/courses/healing-from-sexual-trauma/` should be included in the environment variable. This means the course will be hidden in the French version of bloom but still visible to the English version of bloom. If multiple courses need to be disabled, the slugs will need to be separated by commas.
+  Download the local environment variables files from Vercel:
 
-- `NEXT_PUBLIC_FF_USER_RESEARCH_BANNER`: This feature flag enables a banner which displays a banner message aimed to gathering users for Bloom feedback. It is intended to be turned on temporarily, for saw 1-2 weeks at a time. It links to an external form which users can fill out if they would like to take part in research.
+  ```bash
+  vercel env pull .env.local
+  ```
 
 ### Install Dependencies
 
-After configuring your environment variables, it's time to install dependencies and run the app.
-
-First, to install dependencies, run:
+Install dependencies by running:
 
 ```bash
 yarn
 ```
 
-### Run Locally
+### Run Locally with yarn
 
 Start the app in development mode (with hot-code reloading, error reporting, etc.):
 
@@ -165,7 +195,7 @@ yarn dev
 
 Go to [http://localhost:3000](http://localhost:3000)
 
-### Run Tests
+### Unit Testing
 
 ```bash
 yarn test
@@ -177,20 +207,18 @@ To have your unit tests running in the background as you change code:
 yarn test:watch
 ```
 
-### Formatting and Linting
-
-We use ESLint and Prettier for linting and formatting. Workspace settings for VSCode are included in [.vscode/settings.json](.vscode/settings.json) for consistency, and can be replicated if using an alternative IDE. We recommend installing the VSCode extensions in the [.vscode/extensions](.vscode/extensions.json) for automated formatting and linting.
+### Format and Linting
 
-[Pre-commit](https://pre-commit.com/) and [husky](https://typicode.github.io/husky/) are set up to run formatting and linting before each commit is pushed. **Commits will be blocked if there are any formatting or linting issues**
+Linting and formatting are provided by [ESLint](https://eslint.org/) and [Prettier](https://prettier.io/). We recommend VSCode users to utilize the workspace settings in [.vscode/settings.json](.vscode/settings.json) and install the extensions in [.vscode/extensions](.vscode/extensions.json) for automated consistency.
 
-If an error is thrown when pushing a commit:
+Additionally, this application uses [Pre-commit](https://pre-commit.com/) and [husky](https://typicode.github.io/husky/) to run formatting and linting before each commit is pushed. If an error is thrown when pushing a commit:
 
 - check the output logs for linting errors - fix all linting errors before committing.
 - check file changes for new formatting changes - if formatting fixes were applied during pre-commit, the original changes will now be staged, and new formatted changes will need to be staged and committed.
 
-We strongly recommend linting and formatting before every commit:
+**We strongly recommend maintaining consistent code style by linting and formatting before every commit:**
 
-Run lint:
+Run linting:
 
 ```bash
 yarn lint
@@ -218,41 +246,22 @@ yarn build
 
 ## Cypress Testing
 
-We use Cypress to perform end-to-end (e2e) tests of platform.
-See [CYPRESS.md](CYPRESS.md) for set up instructions for Cypress tests.
-
-**Running the https proxy**
-You need to run a https proxy for the storyblok preview.
-
-```bash
-// Install mkcert for creating a valid certificate (Mac OS):
-
-          $ brew install mkcert
-          $ mkcert -install
-          $ mkcert localhost
-
-// Then install and run the proxy
-
-          $ npm install -g local-ssl-proxy
-          $ local-ssl-proxy --source 3010 --target 3000 --cert localhost.pem --key localhost-key.pem
-
-// https is now running on port 3010 and forwarding requests to http 3000
-```
+Bloom uses Cypress to perform end-to-end (e2e) tests of platform.
+See [CYPRESS.md](CYPRESS.md) for set-up instructions.
 
 ## Git Flow and Deployment
 
 **The develop branch is our source of truth, not main.**
 
-### Directions for Contributors
+### Staging Directions for Contributors
+
+Testing the staging preview is helpful for making front-end design changes.
 
-1. Follow the Contributing Guidelines in [CONTRIBUTING.md](/CONTRIBUTING.md).
-2. Fork the repo and create a new branch from the `develop` base branch.
-3. Run the app on the new branch, complete your work testing on http://localhost:3000, and commit. Note that commits with linting errors will be blocked - see [pre-commit and husky checks](#pre-commit-and-husky-checks)
-4. Go to Github and open a pull request for the branch - the branch should be automatically based off of the `develop` branch. Creating a pull request will trigger GitHub Actions to automatically run build and linting tasks. A [vercel preview url](https://vercel.com/docs/deployments/preview-deployments) will also be created, to act as a staging environment for this branch
-5. Test the new branch on the vercel preview url, and ensure all new changes working as expected
-6. Request a code review from a staff member who will manage the merge and deployment flow (see below)
+1. Creating a pull request will trigger GitHub Actions to automatically run build and linting tasks. A [vercel preview url](https://vercel.com/docs/deployments/preview-deployments) will also be created, to act as a staging environment for this branch
+2. Test the new branch on the vercel preview url, and ensure all new changes working as expected
+3. Request a code review from a staff member who will manage the merge and deployment flow.
 
-### Merge and Deployment Flow
+### Staging Merge and Deployment Flow Directions for Maintainers
 
 1. When a pull request is approved, **squash and merge** the pull request into `develop`. Merging a pull request into `develop` will trigger a deployment to the [staging preview url](https://bloom-frontend-git-develop-chaynhq.vercel.app/). A new pull request `Merge Develop onto Main` will be automatically created when `develop` is ahead of `main`