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:
parent
13361dee3d
commit
d2eba37918
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue