Document use of the openstack-discuss mailing list

As the sun sets on our old openstack, openstack-dev,
openstack-operators and openstack-sigs mailing lists, provide a
durable reference to the recommended subject topic tags for the new
openstack-discuss mailing list which has supplanted them. This
initial set of tags was brainstormed at
https://etherpad.openstack.org/p/common-openstack-ml-topics but
subsequent additions or revisions should be made to this document
via code-review.

Change-Id: Iea0dc19775ac75a8979345e58e394094d30facd0
This commit is contained in:
Jeremy Stanley 2018-11-30 20:34:28 +00:00
parent 13361dee3d
commit d2eba37918
3 changed files with 37 additions and 16 deletions

View File

@ -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

View File

@ -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

View File

@ -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