diff --git a/src/main/asciidoc/_chapters/preface.adoc b/src/main/asciidoc/_chapters/preface.adoc
index 7d244bdbb8d..ed2ca7a928c 100644
--- a/src/main/asciidoc/_chapters/preface.adoc
+++ b/src/main/asciidoc/_chapters/preface.adoc
@@ -99,7 +99,7 @@ Tested::
 
 Not Tested::
   In the context of Apache HBase, /not tested/ means that a feature or use pattern
-  may or may notwork in a given way, and may or may not corrupt your data or cause
+  may or may not work in a given way, and may or may not corrupt your data or cause
   operational issues. It is an unknown, and there are no guarantees. If you can provide
   proof that a feature designated as /not tested/ does work in a given way, please
   submit the tests and/or the metrics so that other users can gain certainty about
diff --git a/src/main/asciidoc/_chapters/protobuf.adoc b/src/main/asciidoc/_chapters/protobuf.adoc
index a614c0c023f..8c73dd0c374 100644
--- a/src/main/asciidoc/_chapters/protobuf.adoc
+++ b/src/main/asciidoc/_chapters/protobuf.adoc
@@ -31,7 +31,7 @@
 == Protobuf
 HBase uses Google's link:http://protobuf.protobufs[protobufs] wherever
 it persists metadata -- in the tail of hfiles or Cells written by
-HBase into the system hbase;meta table or when HBase writes znodes
+HBase into the system hbase:meta table or when HBase writes znodes
 to zookeeper, etc. -- and when it passes objects over the wire making
 xref:hbase.rpc[RPCs]. HBase uses protobufs to describe the RPC
 Interfaces (Services) we expose to clients, for example the `Admin` and `Client`
@@ -48,15 +48,15 @@ You then feed these descriptors to a protobuf tool, the `protoc` binary,
 to generate classes that can marshall and unmarshall the described serializations
 and field the specified Services.
 
-See the `README.txt` in the HBase sub-modules for detail on how
+See the `README.txt` in the HBase sub-modules for details on how
 to run the class generation on a per-module basis;
-e.g. see `hbase-protocol/README.txt` for how to generated protobuf classes
+e.g. see `hbase-protocol/README.txt` for how to generate protobuf classes
 in the hbase-protocol module.
 
-In HBase, `.proto` files are either in the `hbase-protocol` module, a module
+In HBase, `.proto` files are either in the `hbase-protocol` module; a module
 dedicated to hosting the common proto files and the protoc generated classes
-that HBase uses internally serializing metadata or, for extensions to hbase
-such as REST or Coprocessor Endpoints that need their own descriptors, their
+that HBase uses internally serializing metadata. For extensions to hbase
+such as REST or Coprocessor Endpoints that need their own descriptors; their
 protos are located inside the function's hosting module: e.g. `hbase-rest`
 is home to the REST proto files and the `hbase-rsgroup` table grouping
 Coprocessor Endpoint has all protos that have to do with table grouping.
@@ -71,7 +71,7 @@ of core HBase protos found back in the hbase-protocol module. They'll
 use these core protos when they want to serialize a Cell or a Put or
 refer to a particular node via ServerName, etc., as part of providing the
 CPEP Service. Going forward, after the release of hbase-2.0.0, this
-practice needs to whither. We'll make plain why in the later
+practice needs to whither. We'll explain why in the later
 xref:shaded.protobuf[hbase-2.0.0] section.
 
 [[shaded.protobuf]]
@@ -87,8 +87,8 @@ so hbase core can evolve its protobuf version independent of whatever our
 dependencies rely on. For instance, HDFS serializes using protobuf.
 HDFS is on our CLASSPATH. Without the above described indirection, our
 protobuf versions would have to align. HBase would be stuck
-on the HDFS protobuf version until HDFS decided upgrade. HBase
-and HDFS verions would be tied.
+on the HDFS protobuf version until HDFS decided to upgrade. HBase
+and HDFS versions would be tied.
 
 We had to move on from protobuf-2.5.0 because we need facilities
 added in protobuf-3.1.0; in particular being able to save on