From 98fcc54f888ecfc909cadde9b4df15c5f531a397 Mon Sep 17 00:00:00 2001 From: Thierry Carrez Date: Mon, 9 Feb 2015 15:46:23 +0100 Subject: [PATCH] Update to reflect recent governance changes Catch up with recent openstack/governance changes, in particular: - Programs are now Project Teams - programs.yaml was renamed projects.yaml - Report chnages in projects.yaml to the example snippet Small fixes about specs and blueprints: - specs are generally attached to the project team rather than each individual project, so change placeholders to - Bugs/Blueprints are sometimes attached to the project team rather than each project, so add "generally" to make it a not-so-hard rule. Change-Id: Ifc340042a46f033dc3c0950fb3db8395a2a51948 --- doc/source/creators.rst | 12 ++++++------ doc/source/developers.rst | 16 ++++++++-------- doc/source/drivers.rst | 4 ++-- 3 files changed, 16 insertions(+), 16 deletions(-) diff --git a/doc/source/creators.rst b/doc/source/creators.rst index f1b9097..fdc1676 100644 --- a/doc/source/creators.rst +++ b/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, diff --git a/doc/source/developers.rst b/doc/source/developers.rst index 329a331..9e9b69e 100644 --- a/doc/source/developers.rst +++ b/doc/source/developers.rst @@ -181,7 +181,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/. Contributors may review these reports regularly when looking for work to complete. @@ -223,9 +223,9 @@ section of the OpenStack Git Commit Good Practices wiki page. Working on Specifications and Blueprints ---------------------------------------- -Many OpenStack projects and programs have a -specs respository which +Many OpenStack projects teams have a -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:: @@ -239,7 +239,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 @@ -252,12 +252,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 `_. -View all approved project and program specifications at +View all approved project teams specifications at http://specs.openstack.org/. Starting a Change @@ -512,7 +512,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 diff --git a/doc/source/drivers.rst b/doc/source/drivers.rst index 6056f0a..666a034 100644 --- a/doc/source/drivers.rst +++ b/doc/source/drivers.rst @@ -214,14 +214,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/. 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 -specs. If a project has a spec +Many projects have repositories entitled -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.