summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorEd Leafe <ed@leafe.com>2017-09-28 17:04:15 +0000
committerEd Leafe <ed@leafe.com>2017-10-12 18:07:33 +0000
commit9fd03c71c7db01a1bf9d56bfe0506a029d6542fe (patch)
tree4618e9630b631dae0b44db1522354f5a3af75457
parent8cf00fde96e596cf5f12a0cb580451efc0f5fe57 (diff)
Change API-WG to API-SIGHEADmaster
This updates as many references to 'API-WG', 'API Working Group', etc., to reflect the name change to the API-SIG. Change-Id: I15ca0860c58bd7ba51f08dd39e551a774d7a060a
Notes
Notes (review): Verified+1: Jenkins Code-Review+1: Chris Dent <cdent@anticdent.org> Code-Review+1: Dmitry Tantsur <divius.inside@gmail.com> Code-Review+2: Michael McCune <msm@redhat.com> Workflow+1: Michael McCune <msm@redhat.com> Verified+2: Zuul Submitted-by: Zuul Submitted-at: Thu, 19 Oct 2017 16:50:01 +0000 Reviewed-on: https://review.openstack.org/508242 Project: openstack/api-wg Branch: refs/heads/master
-rw-r--r--README.rst10
-rw-r--r--doc/source/conf.py22
-rw-r--r--doc/source/guidedreview.rst57
-rw-r--r--doc/source/index.rst22
-rw-r--r--doc/source/liaisons.rst18
-rw-r--r--doc/source/process.rst148
-rw-r--r--doc/source/template.rst2
-rw-r--r--guidelines/api_interoperability.rst12
-rw-r--r--setup.cfg4
-rwxr-xr-xtools/add-reviewers.py4
10 files changed, 146 insertions, 153 deletions
diff --git a/README.rst b/README.rst
index 4a02bce..7762c6a 100644
--- a/README.rst
+++ b/README.rst
@@ -2,12 +2,12 @@
2README 2README
3====== 3======
4 4
5Openstack API Working Group documents 5Openstack API Special Interest Group documents
6------------------------------------- 6----------------------------------------------
7 7
8This repository contains documents from the OpenStack API working group, 8This repository contains documents from the OpenStack API Special Interest
9including guidelines and proposed rules concerning API consistency, naming 9Group, including guidelines and proposed rules concerning API consistency,
10conventions, and best practice recommendations. The published 10naming conventions, and best practice recommendations. The published
11information can be found at `specs.openstack.org 11information can be found at `specs.openstack.org
12<http://specs.openstack.org/openstack/api-wg/>`_. 12<http://specs.openstack.org/openstack/api-wg/>`_.
13 13
diff --git a/doc/source/conf.py b/doc/source/conf.py
index 8ff1e56..8da32a7 100644
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -35,7 +35,7 @@ extensions = ['sphinx.ext.autodoc',
35 35
36# Feed configuration for yasfb 36# Feed configuration for yasfb
37feed_base_url = 'http://specs.openstack.org/openstack/api-wg' 37feed_base_url = 'http://specs.openstack.org/openstack/api-wg'
38feed_author = 'OpenStack API Working Group' 38feed_author = 'OpenStack API Special Interest Group'
39 39
40todo_include_todos = True 40todo_include_todos = True
41 41
@@ -52,8 +52,8 @@ source_suffix = '.rst'
52master_doc = 'index' 52master_doc = 'index'
53 53
54# General information about the project. 54# General information about the project.
55project = u'API Working Group' 55project = u'API Special Interest Group'
56copyright = u'%s, OpenStack API Working Group Team' % datetime.date.today().year 56copyright = u'%s, OpenStack API Special Interest Group Team' % datetime.date.today().year
57 57
58# The language for content autogenerated by Sphinx. Refer to documentation 58# The language for content autogenerated by Sphinx. Refer to documentation
59# for a list of supported languages. 59# for a list of supported languages.
@@ -191,8 +191,8 @@ latex_elements = {
191# Grouping the document tree into LaTeX files. List of tuples 191# Grouping the document tree into LaTeX files. List of tuples
192# (source start file, target name, title, author, documentclass [howto/manual]). 192# (source start file, target name, title, author, documentclass [howto/manual]).
193latex_documents = [ 193latex_documents = [
194 ('index', 'api-wg.tex', u'API Working Group', 194 ('index', 'api-sig.tex', u'API Special Interest Group',
195 u'OpenStack API Working Group Team', 'manual'), 195 u'OpenStack API Special Interest Group Team', 'manual'),
196] 196]
197 197
198# The name of an image file (relative to this directory) to place at the top of 198# The name of an image file (relative to this directory) to place at the top of
@@ -221,8 +221,8 @@ latex_documents = [
221# (source start file, target name, title, author, 221# (source start file, target name, title, author,
222# dir menu entry, description, category) 222# dir menu entry, description, category)
223texinfo_documents = [ 223texinfo_documents = [
224 ('index', 'api-wg', u'API Working Group', 224 ('index', 'api-sig', u'API Special Interest Group',
225 u'OpenStack API Working Group Team', 'nova-specs', 'Guidelines for OpenStack APIs.', 225 u'OpenStack API Special Interest Group Team', 'nova-specs', 'Guidelines for OpenStack APIs.',
226 'Miscellaneous'), 226 'Miscellaneous'),
227] 227]
228 228
@@ -239,10 +239,10 @@ texinfo_documents = [
239# -- Options for Epub output --------------------------------------------------- 239# -- Options for Epub output ---------------------------------------------------
240 240
241# Bibliographic Dublin Core info. 241# Bibliographic Dublin Core info.
242epub_title = u'API Working Group' 242epub_title = u'API Special Interest Group'
243epub_author = u'OpenStack API Working Group Team' 243epub_author = u'OpenStack API Special Interest Group Team'
244epub_publisher = u'OpenStack API Working Group Team' 244epub_publisher = u'OpenStack API Special Interest Group Team'
245epub_copyright = u'2014, OpenStack API Working Group Team' 245epub_copyright = u'2014, OpenStack API Special Interest Group Team'
246 246
247# The language of the text. It defaults to the language option 247# The language of the text. It defaults to the language option
248# or en if the language is not set. 248# or en if the language is not set.
diff --git a/doc/source/guidedreview.rst b/doc/source/guidedreview.rst
index 3411ede..6dccf5e 100644
--- a/doc/source/guidedreview.rst
+++ b/doc/source/guidedreview.rst
@@ -2,17 +2,17 @@
2Guided Review Process 2Guided Review Process
3===================== 3=====================
4 4
5The API working group would like to increase the tools available to OpenStack 5The API Special Interest Group would like to increase the tools available to
6project teams by defining a process and venue for conducting live face-to-face 6OpenStack project teams by defining a process and venue for conducting live
7reviews. At a high level, these reviews are focused on the question "does my 7face-to-face reviews. At a high level, these reviews are focused on the
8project align with the guidelines?" and are intended to be hosted by the 8question "does my project align with the guidelines?" and are intended to be
9working group at the PTG meetups. 9hosted by the API Special Interest Group at the PTG meetups.
10 10
11On a more concrete level, the working group expects that reviews which are 11On a more concrete level, the API Special Interest Group expects that reviews
12directed towards specific areas, or problems within, an API will garner the 12which are directed towards specific areas, or problems within, an API will
13best results (e.g. "Is using a PUT request for updating these resources 13garner the best results (e.g. "Is using a PUT request for updating these
14appropriate?", "We are using GET requests to start server actions, is there a 14resources appropriate?", "We are using GET requests to start server actions, is
15better alternative?"). 15there a better alternative?").
16 16
17Ideal Candidates for Review 17Ideal Candidates for Review
18--------------------------- 18---------------------------
@@ -46,35 +46,34 @@ group for a live review of your project:
46 and provide a reference for the reviewers to understand the flow of the API 46 and provide a reference for the reviewers to understand the flow of the API
47 in question. 47 in question.
48 48
49Then just show up to an API working group face-to-face session with your 49Then just show up to an API Special Interest Group face-to-face session with
50materials ready. Sending an email ahead of time will help to ensure that the 50your materials ready. Sending an email ahead of time will help to ensure that
51group is ready for your review but is not strictly necessary. 51the group is ready for your review but is not strictly necessary.
52 52
53What should I expect from my review? 53What should I expect from my review?
54------------------------------------ 54------------------------------------
55 55
56The answer to this will vary depending on the nature of your request to the 56The answer to this will vary depending on the nature of your request to the
57working group. You should expect to have clarification on the basic 57group. You should expect to have clarification on the basic question of how
58question of how close your API follows the working group's guidelines. But, 58close your API follows the API-SIG's guidelines. But, the depth of your review
59the depth of your review will depend entirely on how big a request is made of 59will depend entirely on how big a request is made of the review group.
60the review group.
61 60
62The preparations that a project team makes before the review process will have 61The preparations that a project team makes before the review process will have
63the largest effect on the expected outcome. Teams that are more specific and 62the largest effect on the expected outcome. Teams that are more specific and
64focused with their requests to the review group will most likely harvest the 63focused with their requests to the review group will most likely harvest the
65greatest fruits from this process. 64greatest fruits from this process.
66 65
67When considering approaching the working group for a review, we encourage 66When considering approaching the API-SIG for a review, we encourage projects to
68projects to identify areas of their APIs that could use clarification or have 67identify areas of their APIs that could use clarification or have been
69been problematic to the team. Project teams that have reviewed the API 68problematic to the team. Project teams that have reviewed the API guidelines
70guidelines and have questions about specific areas of interest will find that 69and have questions about specific areas of interest will find that their
71their reviews will be more productive than open-ended questions which cover 70reviews will be more productive than open-ended questions which cover large
72large portions of their API. 71portions of their API.
73 72
74After a review is completed, the API working group will archive the general 73After a review is completed, the API Special Interest Group will archive the
75details of the review (e.g. "Team <X> requested a review of API features <Y> 74general details of the review (e.g. "Team <X> requested a review of API
76and <Z>. It was agreed that actions <A>, <B> and <C> are the best path 75features <Y> and <Z>. It was agreed that actions <A>, <B> and <C> are the best
77forward") and any artifacts that are generated during the process. This 76path forward") and any artifacts that are generated during the process. This
78archive will exist in the same repository as the guidelines under a separate 77archive will exist in the same repository as the guidelines under a separate
79heading for reviews. 78heading for reviews.
80 79
diff --git a/doc/source/index.rst b/doc/source/index.rst
index 6d62c83..49d3ea8 100644
--- a/doc/source/index.rst
+++ b/doc/source/index.rst
@@ -1,8 +1,8 @@
1.. api-wg documentation master file 1.. api-wg documentation master file
2 2
3=========================== 3====================================
4OpenStack API Working Group 4OpenStack API Special Interest Group
5=========================== 5====================================
6 6
7Mission Statement 7Mission Statement
8----------------- 8-----------------
@@ -19,8 +19,8 @@ This document contains the guidelines and rules for OpenStack project
19APIs including guidelines and proposed rules concerning API consistency, naming 19APIs including guidelines and proposed rules concerning API consistency, naming
20conventions, and best practice recommendations. 20conventions, and best practice recommendations.
21 21
22If you would like to connect with the API Working Group, visit the wiki at: 22If you would like to connect with the API Special Interest Group, visit the
23https://wiki.openstack.org/wiki/API_Working_Group 23wiki at: https://wiki.openstack.org/wiki/API_Working_Group
24 24
25If you are interested in contributing to this document, the git repository is 25If you are interested in contributing to this document, the git repository is
26available at: http://git.openstack.org/cgit/openstack/api-wg/ 26available at: http://git.openstack.org/cgit/openstack/api-wg/
@@ -30,13 +30,13 @@ http://docs.openstack.org/infra/manual/developers.html
30 30
31 31
32.. warning:: 32.. warning::
33 These documents from the API Working Group are primarily focused on 33 These documents from the API Special Interest Group are primarily focused
34 providing advice and guidelines for JSON-based APIs. While other 34 on providing advice and guidelines for JSON-based APIs. While other
35 representations have their place in the OpenStack ecosystem, they present 35 representations have their place in the OpenStack ecosystem, they present
36 such a diversity of challenges and edge cases, especially with large 36 such a diversity of challenges and edge cases, especially with large and/or
37 and/or binary request and response bodies, that it is impossible to 37 binary request and response bodies, that it is impossible to provide
38 provide guidance that is complete. Where there is doubt refer to the 38 guidance that is complete. Where there is doubt refer to the HTTP RFCs,
39 HTTP RFCs, 7230 through 7235, as the ultimate authority. 39 7230 through 7235, as the ultimate authority.
40 40
41Guidelines 41Guidelines
42---------- 42----------
diff --git a/doc/source/liaisons.rst b/doc/source/liaisons.rst
index 829e9cf..3f8d1fc 100644
--- a/doc/source/liaisons.rst
+++ b/doc/source/liaisons.rst
@@ -4,22 +4,22 @@ Cross-Project Liaisons
4Description 4Description
5----------- 5-----------
6 6
7The API Working Group seeks API subject matter experts for each project to 7The API Special Interest Group seeks API subject matter experts for each
8communicate plans for API updates, review API guidelines with their project's 8project to communicate plans for API updates, review API guidelines with their
9view in mind, and review the API Working Group guidelines as they are drafted. 9project's view in mind, and review the API Special Interest Group guidelines as
10The Cross-Project Liaison (CPL) should be familiar with the project's REST API 10they are drafted. The Cross-Project Liaison (CPL) should be familiar with the
11design and future planning for changes to it. 11project's REST API design and future planning for changes to it.
12 12
13* The liaison should be the PTL or whomever they delegate to be their 13* The liaison should be the PTL or whomever they delegate to be their
14 representative 14 representative
15* The liaison is the first line of contact for the API Working Group team 15* The liaison is the first line of contact for the API Special Interest Group
16 members 16 team members
17* The liaison may further delegate work to other subject matter experts 17* The liaison may further delegate work to other subject matter experts
18* The liaison should be aware of and engaged in the API Working Group 18* The liaison should be aware of and engaged in the API Special Interest Group
19 `Communication channels 19 `Communication channels
20 <https://wiki.openstack.org/wiki/API_Working_Group#Communication>`_ 20 <https://wiki.openstack.org/wiki/API_Working_Group#Communication>`_
21* The Nova team has been very explicit about how they will liaise with the 21* The Nova team has been very explicit about how they will liaise with the
22 API Working Group, see the `Responsibilities of Liaisons <https://wiki.openstack.org/wiki/Nova/APIWGLiaisons>`_ 22 API Special Interest Group; see the `Responsibilities of Liaisons <https://wiki.openstack.org/wiki/Nova/APIWGLiaisons>`_
23 23
24Tooling 24Tooling
25------- 25-------
diff --git a/doc/source/process.rst b/doc/source/process.rst
index d5b63be..fc877cd 100644
--- a/doc/source/process.rst
+++ b/doc/source/process.rst
@@ -7,107 +7,101 @@ trivial changeset in the guidelines directory. A non trivial changeset
7is one which is more than a spelling/grammar typo or reformatting 7is one which is more than a spelling/grammar typo or reformatting
8change. 8change.
9 9
10The guidelines are initially intended to be a working group draft 10The guidelines are initially intended to be a group draft document. Our intent
11document. Our intent is to move fairly quickly to get published draft 11is to move fairly quickly to get published draft guidelines so this process
12guidelines so this process reflects a preference for efficiency while 12reflects a preference for efficiency while gathering consensus.
13gathering consensus.
14 13
15Review process 14Review process
16-------------- 15--------------
17 16
18For trivial changes (as defined above) there is no minimum time that 17For trivial changes (as defined above) there is no minimum time that they must
19they must be proposed before merging. They must have at least one +1 18be proposed before merging. They must have at least one +1 vote other than the
20vote other than the approver and no -1. Once this is true a working 19approver and no -1. Once this is true a working group core may merge the
21group core may merge the change. 20change.
22 21
23For changes which add a new guideline or make substantial changes to 22For changes which add a new guideline or make substantial changes to an
24an existing guideline reaching consensus is an explicit goal. To 23existing guideline reaching consensus is an explicit goal. To that end there is
25that end there is a well defined process to ensure that proposals 24a well defined process to ensure that proposals receive adequate review by the
26receive adequate review by the working group, cross project 25API Special Interest Group, cross project liaisons, and the OpenStack community
27liaisons, and the OpenStack community at large. 26at large.
28 27
29In the various stages of the review process (defined below) consensus 28In the various stages of the review process (defined below) consensus means the
30means the changeset is in its near final form for at least two working 29changeset is in its near final form for at least two working days. Minor
31days. Minor typo/formatting changes do not reset the counter. There 30typo/formatting changes do not reset the counter. There must be at least four
32must be at least four +1 votes and no -1 votes unless the concern 31+1 votes and no -1 votes unless the concern related to the -1 vote has been
33related to the -1 vote has been discussed in an API WG meeting. Once 32discussed in an API WG meeting. Once the matter has been discussed there should
34the matter has been discussed there should be no more than 20% of 33be no more than 20% of votes cast as -1 votes.
35votes cast as -1 votes. 34
36 35Discussion on Gerrit should be encouraged as the primary response. When
37Discussion on Gerrit should be encouraged as the primary response. 36discussion on IRC (in meetings or otherwise) is required that discussion should
38When discussion on IRC (in meetings or otherwise) is required that 37be summarized back to Gerrit.
39discussion should be summarized back to Gerrit.
40 38
41That process is: 39That process is:
42 40
431. Working group members should review proposed guideline changes 411. API Special Interest Group members should review proposed guideline changes
44 and reach consensus. 42 and reach consensus.
45 43
462. When consensus is reached within the group the guideline should 442. When consensus is reached within the group the guideline should be marked as
47 be marked as *frozen* and cross project liaisons (CPLs) should 45 *frozen* and cross project liaisons (CPLs) should be invited to review the
48 be invited to review the guideline. There is an ``add-reviewers.py`` 46 guideline. There is an ``add-reviewers.py`` script to do this. See
49 script to do this. See :doc:`liaisons` for more information. 47 :doc:`liaisons` for more information.
50 48
51 A proposal can be frozen by exactly one core reviewer by setting 49 A proposal can be frozen by exactly one core reviewer by setting Code-Review
52 Code-Review +2. Only the core reviewer responsible for freezing the 50 +2. Only the core reviewer responsible for freezing the proposal should +2
53 proposal should +2 it. All other core reviewers should vote with at 51 it. All other core reviewers should vote with at most a +1 when reviewing.
54 most a +1 when reviewing.
55 52
563. The CPLs have one week to review the proposal. If there are no 533. The CPLs have one week to review the proposal. If there are no reviews lazy
57 reviews lazy consensus is assumed. If there is a -1 review by a CPL 54 consensus is assumed. If there is a -1 review by a CPL that requires an
58 that requires an update to the changeset, it does not reset the 1 55 update to the changeset, it does not reset the 1 week the CPLs have to
59 week the CPLs have to review it. 56 review it.
60 57
614. When there is consensus from the CPLs, the proposal may be 584. When there is consensus from the CPLs, the proposal may be merged.
62 merged.
63 59
64 To avoid opportunities for miscommunication, the core working 60 To avoid opportunities for miscommunication, the core working group member
65 group member who froze the changeset should be responsible for 61 who froze the changeset should be responsible for merging it. If that core
66 merging it. If that core is unavailable for enough time to cause 62 is unavailable for enough time to cause a delay then the responsibility
67 a delay then the responsibility falls to one of the others cores. 63 falls to one of the others cores.
68 64
69 An email should be sent to the openstack-dev mailing list containing 65 An email should be sent to the openstack-dev mailing list containing the
70 the links to all of the guidelines that have recently merged. The 66 links to all of the guidelines that have recently merged. The finalized
71 finalized guidelines should be buffered such that a maximum of one 67 guidelines should be buffered such that a maximum of one announcement email
72 announcement email is sent per week. 68 is sent per week.
73 69
74If at any time during this process there is difficulty reaching 70If at any time during this process there is difficulty reaching consensus or an
75consensus or an apparent lack of information or input, additional 71apparent lack of information or input, additional input should be sought from
76input should be sought from the rest of the community. Two ways to 72the rest of the community. Two ways to do this include (preferring email):
77do this include (preferring email):
78 73
791. The openstack-dev mailing list. An email may be sent to the 741. The openstack-dev mailing list. An email may be sent to the openstack-dev
80 openstack-dev mailing list with the subject "[all][api] New API 75 mailing list with the subject "[all][api] New API Guidelines Ready for Cross
81 Guidelines Ready for Cross Project Review". The email should contain 76 Project Review". The email should contain links to the guidelines that need
82 links to the guidelines that need additional input. 77 additional input.
83 78
842. The `Cross Project Meeting 792. The `Cross Project Meeting
85 <https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting>`_. An 80 <https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting>`_. An agenda
86 agenda item should be added to the Cross Project Meeting which 81 item should be added to the Cross Project Meeting which indicates need for
87 indicates need for discussion. Links to the guidelines that need 82 discussion. Links to the guidelines that need additional input should be
88 additional input should be provided. When this is done an API WG 83 provided. When this is done an API WG member must attend the meeting to
89 member must attend the meeting to highlight the agenda item. 84 highlight the agenda item.
90 85
91Merged guidelines comprise a draft of the official guidelines. Before 86Merged guidelines comprise a draft of the official guidelines. Before an
92an official version of the guidelines can be released the following 87official version of the guidelines can be released the following has to occur:
93has to occur:
94 88
95* An 80% (of votes cast) majority vote on the document as a whole 89* An 80% (of votes cast) majority vote on the document as a whole with one vote
96 with one vote per OpenStack PTL (or delegate). 90 per OpenStack PTL (or delegate).
97 91
98* Reviewed and approved by the TC. The API WG is a delegated group from 92* Reviewed and approved by the TC. The API WG is a delegated group from the TC
99 the TC so the TC ultimately get final say on what the working 93 so the TC ultimately get final say on what the working group are able to
100 group are able to release. 94 release.
101 95
102Proposing a new guideline 96Proposing a new guideline
103------------------------- 97-------------------------
104 98
105When proposing a new guideline you should start by using the 99When proposing a new guideline you should start by using the :doc:`guideline
106:doc:`guideline template <template>` to generate the basic 100template <template>` to generate the basic structure. Copy the ``template.rst``
107structure. Copy the ``template.rst`` file to the ``guidelines`` directory 101file to the ``guidelines`` directory with a filename reflecting your new
108with a filename reflecting your new guideline (for example 102guideline (for example ``guidelines/errors.rst``), and then follow the
109``guidelines/errors.rst``), and then follow the instructions within the 103instructions within the template. Once complete you should follow the
110template. Once complete you should follow the `developer workflow`_ and 104`developer workflow`_ and the previously stated review process to have your
111the previously stated review process to have your guideline accepted. 105guideline accepted.
112 106
113.. _developer workflow: http://docs.openstack.org/infra/manual/developers.html 107.. _developer workflow: http://docs.openstack.org/infra/manual/developers.html
diff --git a/doc/source/template.rst b/doc/source/template.rst
index d4edb30..3ac8783 100644
--- a/doc/source/template.rst
+++ b/doc/source/template.rst
@@ -47,7 +47,7 @@ introduction if applicable.
47Guidance 47Guidance
48******** 48********
49 49
50The actual guidance that the API working group would like to provide. 50The actual guidance that the API Special Interest Group would like to provide.
51 51
52* The guideline should provide a clear recitation of the actions to be 52* The guideline should provide a clear recitation of the actions to be
53 taken by implementors. 53 taken by implementors.
diff --git a/guidelines/api_interoperability.rst b/guidelines/api_interoperability.rst
index fd1f034..585e475 100644
--- a/guidelines/api_interoperability.rst
+++ b/guidelines/api_interoperability.rst
@@ -67,11 +67,11 @@ makes:
67* Change in APIs is an inevitable consequence of evolving projects with a 67* Change in APIs is an inevitable consequence of evolving projects with a
68 diversity of contributors. In the unlikely event that such change is not 68 diversity of contributors. In the unlikely event that such change is not
69 a consideration then these guidelines need not apply. 69 a consideration then these guidelines need not apply.
70* The overarching goal of the API Working Group is to encourage consistency 70* The overarching goal of the API Special Interest Group is to encourage
71 in the APIs of all the services. The proposed solutions for enabling 71 consistency in the APIs of all the services. The proposed solutions for
72 compatibility and stability are guidance towards achieving consistency. 72 enabling compatibility and stability are guidance towards achieving
73 The assertions about when a change will violate interoperability are true 73 consistency. The assertions about when a change will violate
74 independent of any given solution. 74 interoperability are true independent of any given solution.
75 75
76Any service which does not support versioning and wishes to achieve 76Any service which does not support versioning and wishes to achieve
77interoperability SHOULD do two things: 77interoperability SHOULD do two things:
@@ -86,7 +86,7 @@ interoperability SHOULD do two things:
86 adhering to these guidelines for interoperability. The project itself 86 adhering to these guidelines for interoperability. The project itself
87 must make the decisions on how to evolve their API. If this leads to 87 must make the decisions on how to evolve their API. If this leads to
88 conflicts with other projects within the OpenStack ecosystem, the 88 conflicts with other projects within the OpenStack ecosystem, the
89 role of the API-WG is solely to help clarify the guidelines and 89 role of the API-SIG is solely to help clarify the guidelines and
90 provide advice on how to minimize the impact of changes. The 90 provide advice on how to minimize the impact of changes. The
91 Technical Committee is the body which provides adjudication and 91 Technical Committee is the body which provides adjudication and
92 mediation when consensus cannot be reached. 92 mediation when consensus cannot be reached.
diff --git a/setup.cfg b/setup.cfg
index 4ada295..64733ff 100644
--- a/setup.cfg
+++ b/setup.cfg
@@ -1,6 +1,6 @@
1[metadata] 1[metadata]
2name = api-wg 2name = api-sig
3summary = OpenStack API Workgroup Guidelines 3summary = OpenStack API Special Interest Group Guidelines
4description-file = 4description-file =
5 README.rst 5 README.rst
6author = OpenStack 6author = OpenStack
diff --git a/tools/add-reviewers.py b/tools/add-reviewers.py
index 2e16de5..98576d3 100755
--- a/tools/add-reviewers.py
+++ b/tools/add-reviewers.py
@@ -11,11 +11,11 @@ logger = logging.getLogger(__name__)
11def parse_args(): 11def parse_args():
12 parser = argparse.ArgumentParser( 12 parser = argparse.ArgumentParser(
13 description="Add the cross-project liaisons as reviewers " \ 13 description="Add the cross-project liaisons as reviewers " \
14 "on an API working group review.") 14 "on an API Special Interest Group review.")
15 parser.add_argument('--debug', help="Print debugging information", 15 parser.add_argument('--debug', help="Print debugging information",
16 action='store_true') 16 action='store_true')
17 parser.add_argument("username", help="Your Gerrit username", type=str) 17 parser.add_argument("username", help="Your Gerrit username", type=str)
18 parser.add_argument("review", help="An API WG Gerrit review", type=str) 18 parser.add_argument("review", help="An API-SIG Gerrit review", type=str)
19 args = parser.parse_args() 19 args = parser.parse_args()
20 20
21 return (args.debug, args.username, args.review) 21 return (args.debug, args.username, args.review)