From 31a66b6200e8c61ce8641380191fc9cd71feab6f Mon Sep 17 00:00:00 2001 From: Joshua Hesketh Date: Thu, 6 Apr 2017 19:38:24 +1000 Subject: [PATCH] Typo fixes Noticed a few things that needed tidying. Change-Id: I1addff2c309491e5c75d32465f738d7435b99b87 --- reference/base-services.rst | 2 +- reference/charter.rst | 2 +- reference/new-projects-requirements.rst | 2 +- reference/principles.rst | 6 +++--- reference/service-project-naming.rst | 4 +--- 5 files changed, 7 insertions(+), 9 deletions(-) diff --git a/reference/base-services.rst b/reference/base-services.rst index 2b063d006..e2dfa480c 100644 --- a/reference/base-services.rst +++ b/reference/base-services.rst @@ -21,7 +21,7 @@ Current list of base services **An oslo.messaging-compatible message queue** Some inter-process and inter-service communication in OpenStack - components is accomplished using message queues, through oslo.messaging + components is accomplished using message queues through oslo.messaging as an indirection layer. While most OpenStack deployments use RabbitMQ, other message queues are supported. diff --git a/reference/charter.rst b/reference/charter.rst index a6718d55d..0f4e293d9 100644 --- a/reference/charter.rst +++ b/reference/charter.rst @@ -107,7 +107,7 @@ and should be held open for no less than four business days. Voters for PTL seats ("APC") ============================ -Voters for a given project's PTL election are the active project contributors +Voters for a given project's PTL election are the Active Project Contributors ("APC"), which are a subset of the Foundation Individual Members. Individual Members who committed a change to a repository of a project over the last two 6-month release cycles are considered APC for that project team. diff --git a/reference/new-projects-requirements.rst b/reference/new-projects-requirements.rst index 3f7670b0a..0291373ab 100644 --- a/reference/new-projects-requirements.rst +++ b/reference/new-projects-requirements.rst @@ -25,7 +25,7 @@ When considering new projects for addition, the TC will check that: * The proposed project uses an open source license (preferably the Apache v2.0 license, since it is necessary if the project wants to be used in an OpenStack trademark program) - * Project must have no library dependencies which effectively restrict + * The project must have no library dependencies which effectively restrict how the project may be distributed or deployed * Open Community: diff --git a/reference/principles.rst b/reference/principles.rst index ea0fb5413..a11169f45 100644 --- a/reference/principles.rst +++ b/reference/principles.rst @@ -17,8 +17,8 @@ One OpenStack ------------- OpenStack is one community with one common mission, producing one framework -of collaborating components. Our organization into separate source code -repositories and teams allows contributors to focus on their areas of +of collaborating components. Our organization is split into separate source +code repositories and teams allowing contributors to focus on their areas of interest and expertise, but does not make OpenStack a loose collection of disconnected projects. @@ -69,7 +69,7 @@ OpenStack Leaders Exist to Serve Their Community OpenStack leaders hold their positions only in order to serve the people they lead. The TC only exists to serve the technical community. PTLs -exist to serve the contributors to and users of their projects. +exist to serve the contributors and users of their projects. Changes in Leadership are Good ------------------------------ diff --git a/reference/service-project-naming.rst b/reference/service-project-naming.rst index 970bcd326..cf832d729 100644 --- a/reference/service-project-naming.rst +++ b/reference/service-project-naming.rst @@ -30,7 +30,7 @@ the ``openstack`` CLI command. The history of this decision is that the documentation contributors wanted the least amount of cognitive overhead when writing and reviewing. Learning rules -about case can be difficult across multiple projects and with hundreds of +about case can be difficult across multiple projects with hundreds of documentation contributors and thousands of changes and additions. Lowercase for project names as a rule is then easiest to review and enforce at this scale and growth pattern. @@ -74,5 +74,3 @@ Developer documentation may refer to the project name, but end-user, operator, administrator, and application developer documentation must refer to the service name. When reviewing service names, consider the consumers of the information. - -