diff --git a/doc/source/admin_guide.rst b/doc/source/admin_guide.rst
index a85f008c04..06c4244822 100644
--- a/doc/source/admin_guide.rst
+++ b/doc/source/admin_guide.rst
@@ -684,8 +684,7 @@ of async_pendings in real-time, but will not tell you the current number of
 async_pending container updates on disk at any point in time.
 
 Note also that the set of metrics collected, their names, and their semantics
-are not locked down and will change over time.  StatsD logging is currently in
-a "beta" stage and will continue to evolve.
+are not locked down and will change over time.
 
 Metrics for `account-auditor`:
 
diff --git a/doc/source/overview_erasure_code.rst b/doc/source/overview_erasure_code.rst
index 18ed2ea28a..64ce5621f2 100644
--- a/doc/source/overview_erasure_code.rst
+++ b/doc/source/overview_erasure_code.rst
@@ -182,17 +182,13 @@ similar to that of replication with a few notable exceptions:
 Performance Considerations
 --------------------------
 
-Efforts are underway to characterize performance of various Erasure Code
-schemes.  One of the main goals of the beta release is to perform this
-characterization and encourage others to do so and provide meaningful feedback
-to the development community.  There are many factors that will affect
-performance of EC so it is vital that we have multiple characterization
-activities happening.
-
 In general, EC has different performance characteristics than replicated data.
 EC requires substantially more CPU to read and write data, and is more suited
 for larger objects that are not frequently accessed (eg backups).
 
+Operators are encouraged to characterize the performance of various EC schemes
+and share their observations with the developer community.
+
 ----------------------------
 Using an Erasure Code Policy
 ----------------------------
diff --git a/doc/source/overview_policies.rst b/doc/source/overview_policies.rst
index 5df03733d6..560320ae3e 100644
--- a/doc/source/overview_policies.rst
+++ b/doc/source/overview_policies.rst
@@ -37,8 +37,7 @@ There are many reasons why this might be desirable:
 .. note::
 
     Today, Swift supports two different policy types: Replication and Erasure
-    Code. Erasure Code policy is currently a beta release and should not be
-    used in a Production cluster. See :doc:`overview_erasure_code` for details.
+    Code. See :doc:`overview_erasure_code` for details.
 
     Also note that Diskfile refers to backend object storage plug-in
     architecture. See :doc:`development_ondisk_backends` for details.
diff --git a/etc/swift.conf-sample b/etc/swift.conf-sample
index 86810caf90..5bd57e6864 100644
--- a/etc/swift.conf-sample
+++ b/etc/swift.conf-sample
@@ -51,8 +51,7 @@ aliases = yellow, orange
 #policy_type = replication
 
 # The following declares a storage policy of type 'erasure_coding' which uses
-# Erasure Coding for data reliability.  The 'erasure_coding' storage policy in
-# Swift is available as a "beta".  Please refer to Swift documentation for
+# Erasure Coding for data reliability. Please refer to Swift documentation for
 # details on how the 'erasure_coding' storage policy is implemented.
 #
 # Swift uses PyECLib, a Python Erasure coding API library, for encode/decode