diff --git a/contributors.yml b/contributors.yml
index 562dd6b8e24..1875a7b6867 100644
--- a/contributors.yml
+++ b/contributors.yml
@@ -10,3 +10,4 @@
 - meetbryce
 - morinokami
 - ryanflorence
+- twhitbeck
diff --git a/docs/api/remix.md b/docs/api/remix.md
index d9416a50403..83759f8f7ae 100644
--- a/docs/api/remix.md
+++ b/docs/api/remix.md
@@ -1788,7 +1788,7 @@ For purely cookie-based sessions (where the session data itself is stored in the
 
 The main advantage of cookie session storage is that you don't need any additional backend services or databases to use it. It can also be beneficial in some load balanced scenarios. However, cookie-based sessions may not exceed the browser's max allowed cookie length (typically 4kb).
 
-The downside is that you have to `commitSession` in almost every loader and action. If your loader or action changes the session at all, it must be commited. That means if you `session.flash` in an action, and then `session.get` in another, you must commit it for that flashed message to go away. With other session storage strageties you only have to commit it when it's created (the browser cookie doesn't need to change because it doesn't store the session data, just the key to find it elsewhere).
+The downside is that you have to `commitSession` in almost every loader and action. If your loader or action changes the session at all, it must be commited. That means if you `session.flash` in an action, and then `session.get` in another, you must commit it for that flashed message to go away. With other session storage strategies you only have to commit it when it's created (the browser cookie doesn't need to change because it doesn't store the session data, just the key to find it elsewhere).
 
 ```js
 import { createCookieSessionStorage } from "remix";