diff --git a/doc/source/open-community.rst b/doc/source/open-community.rst
index 43642f2..30d8ff1 100644
--- a/doc/source/open-community.rst
+++ b/doc/source/open-community.rst
@@ -70,12 +70,30 @@ perfectly) level playing field with email than they might be with synchronous
 forms of text-based communication, such as IRC. When in doubt, prefer using a
 mailing list to other options.
 
-When using the mailing list for team communication, it's best to tag the
-subject with the name of the project surrounded by brackets. For example,
-to communicate something to the mailing list about Nova, you would add this
-to the subject::
+For the openstack-discuss_ mailing list, where most usage, operations and
+development discussions take place, the following tags are recommended to
+better categorize topics (add as many to the beginning of the subject line as
+are relevant):
 
-  [nova]
+  * ``[$groupname-wg]`` Discussion within $groupname working group (example:
+    `[publiccloud-wg]`)
+  * ``[$projectname]`` Discussion affects the $project project team (example:
+    `[nova]`)
+  * ``[$signame-sig]`` Discussion within $signame SIG (example:
+    `[upgrades-sig]`)
+  * ``[all]`` Topic is a general community discussion affecting everyone. Use
+    with care.
+  * ``[dev]`` Discussion is specific to development concerns, but otherwise
+    affects all devs
+  * ``[docs]`` Any kind of documentation discussions that are cross-projects
+  * ``[goals]`` Affects community goals
+  * ``[ops]`` Discussion is specific to operators concerns, but otherwise
+    affects all ops
+  * ``[ptl]`` Topics needing the attention of PTLs
+  * ``[release]`` Affects the upcoming release, all PTLs or release liaisons
+    should read
+  * ``[tc]`` Discussion around Technical Committee activities
+  * ``[uc]`` Discussion around User Committee activities
 
 There are many mailing lists in the OpenStack ecosystem. Projects should ensure
 they have subscribers on all of the lists relevant to their project.
@@ -216,3 +234,4 @@ release cycle (for PTL elections) and summit dates (for the TC elections).
 .. _decision: https://governance.openstack.org/tc/resolutions/20141128-elections-process-for-leaderless-programs.html
 .. _adding your blog: https://wiki.openstack.org/wiki/AddingYourBlog
 .. _Openstack-wide goals: https://governance.openstack.org/tc/goals/index.html
+.. _openstack-discuss: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
diff --git a/doc/source/ptl.rst b/doc/source/ptl.rst
index dd69f37..de60e2d 100644
--- a/doc/source/ptl.rst
+++ b/doc/source/ptl.rst
@@ -49,9 +49,10 @@ consider.
 Criteria when considering new cores
 -----------------------------------
 
-A successful appointment can be made solely by the PTL, however it is encouraged
-to hear the opinions of the existing core team. This can be done through
-private messages on IRC or publicly through the openstack-dev mailing list.
+A successful appointment can be made solely by the PTL, however it is
+encouraged to hear the opinions of the existing core team. This can be done
+through private messages on IRC or publicly through the openstack-discuss_
+mailing list.
 
 #.  Are their review numbers (quantity and disagreements) similar to those of
     existing core members?
@@ -223,12 +224,13 @@ The following are a few ways you can do that.
 Mailing Lists
 -------------
 
-Our community has several mailing lists, some of which are specific to
-operators. The `OpenStack Operator mailing list`_ is a great place to ask for
-feedback. An advantage of using mailing lists is that responses are logged
-making it easy to reference them later. You also don't have to wait for a
-specific time or place to use mailing lists, making it easy to attempt to
-collect feedback in a pinch or when a formal setting isn't feasible.
+Our community has several mailing lists, though most usage, operations and
+development discussions take place on the openstack-discuss_ mailing list
+making it a great place to ask for feedback. An advantage of using mailing
+lists is that responses are logged making it easy to reference them later. You
+also don't have to wait for a specific time or place to use mailing lists,
+making it easy to attempt to collect feedback in a pinch or when a formal
+setting isn't feasible.
 
 User Surveys
 ------------
@@ -312,4 +314,4 @@ When necessary, the following can be performed at unscheduled times.
 .. _release management: http://docs.openstack.org/project-team-guide/release-management.html
 .. _FirstContact SIG liaisons: https://wiki.openstack.org/wiki/First_Contact_SIG#Project_Liaisons
 .. _weekly meetings: http://eavesdrop.openstack.org/#User_Committee_Meeting
-.. _OpenStack Operator mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
+.. _openstack-discuss: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
diff --git a/setup.cfg b/setup.cfg
index 80cb8ac..e76a282 100644
--- a/setup.cfg
+++ b/setup.cfg
@@ -4,7 +4,7 @@ summary = OpenStack Project Team Guide
 description-file =
     README.rst
 author = OpenStack
-author-email = openstack@lists.openstack.org
+author-email = openstack-discuss@lists.openstack.org
 home-page = https://docs.openstack.org/project-team-guide/
 classifier =
     Intended Audience :: Developers