diff --git a/contributingGuides/KSv2.md b/contributingGuides/KSv2.md
new file mode 100644
index 000000000000..056cb09df12c
--- /dev/null
+++ b/contributingGuides/KSv2.md
@@ -0,0 +1,70 @@
+# KSv2
+
+In Expensify, we use a prioritization system called called "Kernel Scheduler v2" (KSv2) to help us keep aligned on how frequently GitHub issues should be worked on, depending on their time priority:
+
+**Hourly**: If a Github issue has the `Hourly` label, the assignee should update it *at least* once an hour
+
+**Daily**: If a Github issue has the `Daily` label, the assignee should update it *at least* once a day
+
+**Weekly**: If a Github issue has the `Weekly` label, the assignee should update it *at least* once a week
+
+**Monthly**: If a Github issue has the `Monthly` label, the assignee should update it *at least* once a month.
+
+## Dashboard
+
+To help surface the issues and PRs that need the most `#urgency`, we've built a custom extension to use in GitHub. It looks like this:
+
+
+
+Once you have the extension installed, you can access it by going to https://github.com/Expensify/Expensify#k2 or clicking on the K2 tab at the top of a repo (between pull requests and GH actions). You'll have to create a Personal Access Token in GitHub ([here](https://github.com/settings/tokens)) and enter that in the K2 dashboard the first time you open it, so that your K2 extension can automatically pull data about your GitHub account.
+
+### Pull Requests for review
+
+In the dashboard, you can first see the PRs assigned to you as `Reviewer`. As part of our engineering guidelines, an engineer (internal or external) should review other people's code before working on their own code. This helps unblock others so that everyone can be as efficient as possible getting stuff done.
+
+### Issues assigned to you
+
+In the next section you can see all issues assigned to you, prioritized from most urgent (on the left) to least urgent (on the right). Issues will also change color depending on other factors - e.g. if they have "HOLD" in the title or if they have the `Overdue`, `Planning`, or `Waiting for copy` labels applied.
+
+If a GitHub issue has the `Overdue` label, the text will be red. This means that the issue hasn't been updated in the amount of time allotted for an update (ex - A weekly issue becomes overdue if it hasn't been updated in a week).
+
+### Your Pull Requests
+
+After the issues section you will find a section that lists the PRs you've created.
+
+
+
+### WAQ issues
+
+This section displays a list of open issues in the App repo which are not on hold and don't have PRs yet, all ordered by their age (and grouped by how many weeks old they are):
+
+
+
+## Label buttons
+
+The page for a GitHub issue will have buttons on the right side for the most common labels. Some of these labels are only for internal use, but there are other labels that can be used for public repos:
+
+
+
+## Reviewer Checklist button
+
+Additionally, the extension provides a button that facilitates the creation of the Reviewer Checklist into a new comment:
+
+
+
+## Installation
+
+You can install the KSv2 extension from [here](https://github.com/Expensify/k2-extension/).
+
+## Best Practices
+- Look at the dashboard every day, before you start any work
+- Work your way down from the top to the bottom
+ 1. Look at PRs you need to review first
+ 2. Next, provide updates for issues assigned to you
+ 3. Check the progress on PRs you've written
+ 4. Finally, find something new to work on
+
+## Why is it called "Kernel Scheduler v2?"
+KSv2 is a shout-out to Windows 95 improving the kernel scheduler used in Windows 3.1. In Windows 3.1, if a program was in the foreground, it was given 100% of the CPU time. This meant that if you watched a background application like the clock, it wouldn't update its time until the foreground application was no longer in the foreground. Then the clock could "catch up" and update to show the current time. Windows 95 made it so that background applications could update by dedicating a small amount of the foreground CPU usage as "spare cycles" for background apps to use. This meant that the clock could now update in real-time, even though it was running in the background.
+
+We brought the same thinking to GitHub priority. A monthly issue is like the "background app". Rather than never getting any work done on it ever, we say that it should have _something_ done on it once a month. It doesn't need to be closed or completed, but it should have something done to it. That way most of a developer's bandwidth can be used on the high-priority items that are hourly and daily, yet still, make some progress on weekly and monthly issues.