Merge "Update to reflect recent governance changes"

doc/source/creators.rst

@@ -197,21 +197,21 @@ and click "Add Role".
 Add Project to the Governance Repository
 ========================================
 
-Each project managed by an official program in OpenStack needs to be
-listed in ``reference/programs.yaml`` in the ``openstack/governance``
+Each project managed by an official OpenStack project team needs to be
+listed in ``reference/projects.yaml`` in the ``openstack/governance``
 repository to indicate who owns the project so we know where ATCs
 voting rights extend.
 
 If your project is under the ``stackforge`` section of the git
 repository structure, you can skip this step.
 
-Find the appropriate section in ``reference/programs.yaml`` and add
+Find the appropriate section in ``reference/projects.yaml`` and add
 the new project to the list. For example, to add a new Oslo library
-edit the "Common Libraries" section::
+edit the "Oslo" section::
 
- Common Libraries:
-   codename: Oslo
+ Oslo:
    ptl: Doug Hellmann (dhellmann)
+   service: Common libraries
    mission:
      To produce a set of python libraries containing code shared by OpenStack
      projects. The APIs provided by these libraries should be high quality,

doc/source/developers.rst

@@ -184,7 +184,7 @@ Development Workflow
 Working on Bugs
 ---------------
 
-Bug reports for a program or project are tracked on Launchpad at
+Bug reports for a project are generally tracked on Launchpad at
 https://bugs.launchpad.net/<projectname>. Contributors may review these
 reports regularly when looking for work to complete.
 
@@ -226,9 +226,9 @@ section of the OpenStack Git Commit Good Practices wiki page.
 Working on Specifications and Blueprints
 ----------------------------------------
 
-Many OpenStack projects and programs have a <project>-specs respository which
+Many OpenStack projects teams have a <projectteam>-specs respository which
 is used to hold approved design specifications for additions and changes to
-the project or program.
+the project teams code repositories.
 
 The layout of the repository will typically be something like::
 
@@ -242,7 +242,7 @@ and which have already been implemented:
 
 You can typically find an example spec in ``specs/template.rst``.
 
-Check the repository for the project or program you're working on for specifics
+Check the repository for the project team you're working on for specifics
 about repository organization.
 
 Specifications are proposed for a given release by adding them to the
@@ -255,12 +255,12 @@ quick, but even if something was previously approved, it should be re-reviewed
 to make sure it still makes sense as written.
 
 Historically, Launchpad blueprints were used to track the implementation of
-these significant features and changes in OpenStack. For many projects and
-programs, these Launchpad blueprints are still used for tracking the current
+these significant features and changes in OpenStack. For many project teams,
+these Launchpad blueprints are still used for tracking the current
 status of a specification. For more information, see `the Blueprints wiki page
 <https://wiki.openstack.org/wiki/Blueprints>`_.
 
-View all approved project and program specifications at
+View all approved project teams specifications at
 http://specs.openstack.org/.
 
 Starting a Change
@@ -540,7 +540,7 @@ If a change fails tests in Jenkins, please follow the steps below:
      error isn't there, then:
   2. Identify which project(s) are affected, and search for a related
      bug on Launchpad. You can search for bugs affecting all OpenStack
-     Programs here: https://bugs.launchpad.net/openstack/ If you do
+     Projects here: https://bugs.launchpad.net/openstack/ If you do
      not find an existing bug, file a new one (be sure to include
      the error message and a link to the logs for the failure). If the
      problem is due to an infrastructure problem (such as Jenkins or

doc/source/drivers.rst

@@ -222,14 +222,14 @@ state of the tree.
 Targeting Blueprints
 ====================
 
-Blueprints for a program or project are posted to
+Blueprints for a project are generally posted to
 https://blueprints.launchpad.net/<projectname>. Project drivers need to review
 blueprints regularly and assign them to a target. For each release there are three
 milestones. Based on interactions with the proposer and/or assignee of the blueprint,
 the project driver assigns the blueprint to a milestone
 (release-1, release-2 or release-3) or defers it to a later release.
 
-Many projects have repositories entitled <project>-specs. If a project has a spec
+Many projects have repositories entitled <projectteam>-specs. If a project has a spec
 repo, a spec needs to be submitted and linked to the launchpad blueprint. The spec
 needs to be reviewed and approved prior to the launchpad blueprint being targeted to
 a milestone.