diff --git a/README.md b/README.md
index 1d5af207c..7f482d4c7 100644
--- a/README.md
+++ b/README.md
@@ -93,9 +93,7 @@ and use the latest head.
 
 > The head of the `master` branch is consistent and should be safe to pull
 without checking out a release tag. When encountering a problem with the latest
-head on `master` that is when a release tag should be sought. Users who require
-stability over feature development will be pulling from a specific feature-locked
-stable branch. No stable branches exist yet, sorry.
+head on `master` that is when a release tag should be sought.
 
 ### BUILD
 
diff --git a/doc/STYLE.md b/doc/STYLE.md
index c0511d2c9..18b420f5f 100644
--- a/doc/STYLE.md
+++ b/doc/STYLE.md
@@ -430,31 +430,31 @@ cable: eventually there would be complete silence.
 
 ### Git / Development related
 
-- Commits in this project tend to have a `prefix:` like `ircd::m:`. This is
+Commits in this project tend to have a `prefix:` like `ircd::m:`. This is
 simply an indicator of where the change occurred. If multiple areas of the
 project are changed: first determine if the change in each area can stand on
 its own and break what you're doing into multiple commits; this is generally
 the case when adding a low-level feature to support something built at a higher
 level. Otherwise, prefix the commit with the largest/most-fundamental area
 being changed.
-	- Prefixes tend to just be the namespace where the change is occurring.
-	- Prefixes can be an actual class name if that class has a lot of nested
-	assets and pretty much acts as a namespace.
-	- Prefixes for changes in `modules/` tend to be the path to the module
-	or the file in a large module. i.e `modules/s_conf:` or `modules/client/sync:`
-	- Prefixes for other areas of the project can just be the directory like `doc:`
-	or `tools:` or `README:`
+- Prefixes tend to just be the namespace where the change is occurring.
+- Prefixes can be an actual class name if that class has a lot of nested
+assets and pretty much acts as a namespace.
+- Prefixes for changes in `modules/` tend to be the path to the module
+or the file in a large module. i.e `modules/s_conf:` or `modules/client/sync:`
+- Prefixes for other areas of the project can just be the directory like `doc:`
+or `tools:` or `README:`
 
-- Existing conventions for commit wording are documented here as follows:
-	Generally after the prefix, the most frequent words a commit start with
-	are "Add" "Fix" "Move" "Remove" and "Improve" and though it is not
-	required, if you can classify what you're doing with one of those that
-	is ideal.
-	- The use of the word "minor" indicates that no application logic was
-	affected by a commit: i.e code formatting changes and "minor cleanup" etc.
-	- The use of the word "various" indicates many not-very-related changes
-	or very spread-out changes: i.e "various fixes" etc; this tends not to be
-	something one is proud of using.
-	- The use of the word "checkpoint" indicates something sloppy and
-	incomplete is being committed; it compiles and runs; there is a pressing
-	need to get it out of the dirty head for the time being.
+Existing conventions for commit wording are documented here as follows:
+Generally after the prefix, the most frequent words a commit start with
+are "Add" "Fix" "Move" "Remove" and "Improve" and though it is not
+required, if you can classify what you're doing with one of those that
+is ideal.
+- The use of the word "minor" indicates that no application logic was
+affected by a commit: i.e code formatting changes and "minor cleanup" etc.
+- The use of the word "various" indicates many not-very-related changes
+or very spread-out changes: i.e "various fixes" etc; this tends not to be
+something one is proud of using.
+- The use of the word "checkpoint" indicates something sloppy and
+incomplete is being committed; it compiles and runs; there is a pressing
+need to get it out of the dirty head for the time being.