docs: updating runtime guard policy (#10983)

Codifying that most L7 changes should be runtime guarded, updating deprecation timeline as we changed it a while back.

Signed-off-by: Alyssa Wilk <alyssar@chromium.org>

CONTRIBUTING.md

@@ -125,10 +125,14 @@ versioning guidelines:
 
 # Runtime guarding
 
-Some high risk changes in Envoy are deemed worthy of runtime guarding. Instead of just replacing
+Some changes in Envoy are deemed worthy of runtime guarding. Instead of just replacing
 old code with new code, both code paths are supported for between one Envoy release (if it is
 guarded due to performance concerns) and a full deprecation cycle (if it is a high risk behavioral
-change).
+change). Generally as a community we try to guard both high risk changes (major
+refactors such as replacing Envoy's buffer implementation) and most user-visible
+non-config-guarded changes to protocol processing (for example additions or changes to HTTP headers or
+how HTTP is serialized out) for non-alpha features. Feel free to tag @envoyproxy/maintainers
+if you aren't sure if a given change merits runtime guarding.
 
 The canonical way to runtime guard a feature is
 ```
@@ -156,8 +160,9 @@ time.
 Runtime guarded features may either set true (running the new code by default) in the initial PR,
 after a testing interval, or during the next release cycle, at the PR author's and reviewing
 maintainer's discretion. Generally all runtime guarded features will be set true when a
-release is cut, and the old code path will be deprecated at that time. Runtime features
-are set true by default by inclusion in
+release is cut. Old code paths for refactors can be cleaned up after a release and there has been
+some production run time. Old code for behavioral changes will be deprecated after six months.
+Runtime features are set true by default by inclusion in
 [source/common/runtime/runtime_features.h](https://github.com/envoyproxy/envoy/blob/master/source/common/runtime/runtime_features.h)
 
 There are four suggested options for testing new runtime features:

PULL_REQUESTS.md

@@ -67,6 +67,16 @@ current version. Please include any relevant links. Each release note should be
 relevant subsystem in **alphabetical order** (see existing examples as a guide) and include links
 to relevant parts of the documentation. Thank you! Please write in N/A if there are no release notes.
 
+### <a name="runtime_guard"></a>Runtime guard
+
+If this PR has a user-visible behavioral change, or otherwise falls under the
+guidelines for runtime guarding in the [contributing doc](CONTRIBUTING.md.md)
+it should have a runtime guard, which should be documented both in the release
+notes and here in the PR description.
+
+For new feature additions guarded by configs, no-op refactors, docs changes etc.
+this field can be disregarded and/or removed.
+
 ### <a name="issues"></a>Issues
 
 If this PR fixes an outstanding issue, please add a line of the form:

PULL_REQUEST_TEMPLATE.md

@@ -7,5 +7,6 @@ Risk Level:
 Testing:
 Docs Changes:
 Release Notes:
+[Optional Runtime guard:]
 [Optional Fixes #Issue]
 [Optional Deprecated:]