Kelly has made the guidelines below part of the Style Guide:

URI parameters - required is assumed (because of the nature of URI parameters - they are in the API operation call).
query parameters - optional is assumed (because of the nature of query parameters - use them if you want to).
request body parameters - must note if required. If not noted as required, optional is assumed (this is input to the API operation).
response body parameters - no notation (because this is output to the user - no input).

Files:

WADL

RST

Doesn't have any example in the source though this text points to following examples:

The following examples show the requests and corresponding responses to list the domain changes because midnight, GMT-5, on September 13, 2011:

Hello!

Our v2 API has a couple of endpoints related to customer limits that are not currently documented. One of them is older (sorry!), one is new.

Rate Limits

We currently have a section that describes user rate limits. But there is actually an API call they can make to view their current limits. This is will show the same type of information that is already documented, and it will also update in real time. So a user that has a rate limits of 60/min for operation X, if they do a couple X's, and then hit this endpoint, they'll be able to see that their remaining limit for the minute is 58.

curl -H "X-Auth-Token: ${TOKEN}"  https://global.dns.api.rackspacecloud.com/v2/${TENANT}/ratelimits | jq '.'
{
  "limits": {
    "rate": [
      {
        "limit": [
          {
            "next-available": "2016-05-26T14:59:13.120Z",
            "unit": "MINUTE",
            "remaining": 420,
            "value": 420,
            "verb": "GET"
          }
        ],
        "regex": ".*/v2/(\\d+/limits).*",
        "uri": "/limits"
      },
      {
        "limit": [
          {
            "next-available": "2016-05-26T14:59:13.119Z",
            "unit": "MINUTE",
            "remaining": 420,
            "value": 420,
            "verb": "GET"
          }
        ],
        "regex": ".*/v2/(\\d+/pools).*",
        "uri": "/pools"
      },
      {
        "limit": [
          {
            "next-available": "2016-05-26T14:59:13.119Z",
            "unit": "MINUTE",
            "remaining": 40,
            "value": 40,
            "verb": "PATCH"
          }
        ],
        "regex": ".*/v2/(\\d+/tlds).*",
        "uri": "/tlds"
      },
      {
        "limit": [
          {
            "next-available": "2016-05-26T14:59:13.119Z",
            "unit": "MINUTE",
            "remaining": 40,
            "value": 40,
            "verb": "PATCH"
          }
        ],
        "regex": ".*/v2/(\\d+/blacklists).*",
        "uri": "/blacklists"
      },
      {
        "limit": [
          {
            "next-available": "2016-05-26T14:59:13.119Z",
            "unit": "MINUTE",
            "remaining": 10,
            "value": 10,
            "verb": "DELETE"
          }
        ],
        "regex": ".*/v2/(\\d+/blacklists).*",
        "uri": "/blacklists"
      },
      {
        "limit": [
          {
            "next-available": "2016-05-26T14:59:13.119Z",
            "unit": "MINUTE",
            "remaining": 4,
            "value": 4,
            "verb": "GET"
          }
        ],
        "regex": ".*/v2/(\\d+)/recordsets.*",
        "uri": "/recordsets"
      },
      {
        "limit": [
          {
            "next-available": "2016-05-26T14:59:13.119Z",
            "unit": "MINUTE",
            "remaining": 20,
            "value": 20,
            "verb": "DELETE"
          }
        ],
        "regex": ".*/v2/(\\d+/zones)/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}/recordsets.*",
        "uri": "/zones/id/recordsets/id"
      },
      {
        "limit": [
          {
            "next-available": "2016-05-26T14:59:13.119Z",
            "unit": "MINUTE",
            "remaining": 20,
            "value": 20,
            "verb": "PATCH"
          }
        ],
        "regex": ".*/v2/(\\d+/zones)/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}/?",
        "uri": "/zones/id"
      },
...
}

You can see all the information for a given uri and verb is given, along with the total allowed count per unit: value, and the number they have left remaining. The information here is relatively static, but it does get updated occasionally.

Absolute Limits

There is now a very simple endpoint that can show users their "Absolute Limits", sometimes called "Quotas".

curl -H "X-Auth-Token: ${TOKEns.api.rackspacecloud.com/v2/${TENANT}/limits | jq '.'
{
  "max_page_limit": 50,
  "max_zone_recordsets": 3000,
  "max_recordset_name_length": 255,
  "max_recordset_records": 50,
  "max_zone_name_length": 255,
  "max_zone_records": 3000,
  "max_zones": 5000,
  "min_ttl": 300
}

To give you a quick idea of what these mean:

Both of these endpoints are GET only.

I hope I've included the necessary information there. If not, please let me know.

We truly appreciate you ❤️

... right before the actual link for more information: https://developer.rackspace.com/docs/cloud-dns/v2/developer-guide/#getting-started

they won't end up in this repo, but i wanted task in waffle.

Removed DocBook source and artifacts from repo per @meker12 issue here:
rackerlabs/docs-rackspace#73

See the markup and comments in the attached Word doc for my suggested edits for the release notes. Please let me know if you have any questions. Thanks!

Cloud DNS Release Notes_editsKH.docx

on hold till more content is provided

Refactor API Guide: QE checklist

Use the following checklist to verify that API guide refactoring for each service. If you have questions, open a docs-common issue.

Do the QE check against the PR submitted to the master repo. Ask the person who did the refactoring to make you a collaborator on their fork in case you want to submit a PR to correct something.

When you build the refactored Sphinx project, use the make clean html command to build chunked content.

• Review the Strider build log for errors. Notify author about any issues.
• Check for broken links.
• Verify that navigation matches the API Guide template.
• Check the API reference section to verify that the methods for each resource are in a single topic.
• Check the General API information topics to make sure they match the common content where possible.
• Check the Authentication topic in the Getting started section to make sure it matches the common template.
• Check conf.py to make sure it has the updates from the
  template.
• Verify that you can build locally from source.

To describe how they're used for import and export functions.

This is the new version of Cloud DNS (v2), now called Managed DNS. Here is the secret published link: https://developer.rackspace.com/docs/cloud-dns/v2/developer-guide/

It's not on landing page until 3/14, so you have to know URL to reach it. If you can get the edits to me by 3/5, I'd be grateful!!

While reviewing issues with admonitions in converted RST output and discussing how the new UX design handles admonition formatting, I noticed that this topic has an awful lot of notes -- 4 total and one that is "Notes" .

After conversion, you might want to consolidate or re-organize the note content.

http://docs.rackspace.com/cdns/api/v1.0/cdns-devguide/content/POST_createDomain_v1.0__account__domains_domains.html

Instructions/resources here:
https://github.com/rackerlabs/docs-common/blob/master/refactor-api-guide.md
and
rackerlabs/docs-common#68
and
https://github.com/rackerlabs/docs-common/tree/master/api-guide-template

Refactor API Guide checklist

Use the following checklist to guide and track the refactoring work for
each Developer Guide. If you have questions, open a docs-common issue.

When you build the refactored Sphinx project, use the make clean html command to build chunked content. Before you begin refactoring, review restructured text fixes.

Important: If the project contains additional source files or content significantly
different than the template, add a link to the source in Issue #62 in the docs-common repo.

RST coding syntax fixes

Refactoring the API guides gives us a chance to make our RST source files comply with coding best practices. You can make the following changes when you are refactoring, or make the updates in a separate effort. When the changes are complete, check off the list items.

• Wrap all lines to 79 characters.
• Ensure that heading separator lines are the same length as the title

    ====
    Test
    ====

• Use the following symbols for heading separators:
  • H1: over and underline =
  • H2: ~
  • H3: -
  • H4: ^

Tip: If you are using the Atom editor, you can configure the soft wrap feature to reflow text
to 79 characters with a keybinding:

• Set the line length:
  • Click Atom > Preferences > Settings.
  • Change the Preferred Line Length to 79.
  • Make sure that Soft wrap at Preferred Line length is selected.
  • Do not select the Soft wrap selection.
• Reflow text that exceeds 79 characters.
  • Select the line or paragraph.
  • Click alt+cmd+q to reflow the text. If text is indented or has special formatting,
    you have to adjust the text manually.

Note: Don't worry about the line length in code samples or tables for now.

Configuration updates (conf.py)

• Replace everything above the ## -- General configuration line with the first 32 lines from
  the conf.py in the API Guide template.
• Change deconst builder configuration to deconst-serial to build chunked html.
  builder = 'deconst-serial'
#builder = 'deconst-single
• Add the spelling checker extension after the extension modules configuration.
• Ensure that extlinks library matches the one in conf.py template.
• Add sphinx-rtd-template to improve template for local builds.
• Add requirements.txt to the root directory to support local builds
• Update titles to remove "Developer Guide". Follow title pattern in conf.py template.

After you complete the conf.py updates, run the Sphinx build (make clean html) to test that the build still works: make clean html. Resolve any errors.

Note: If the Sphinx build doesn't run, follow the build from source instructions to install the required dependencies.

Overview updates

When you refactor the content in the overview source files, you relocate the content and delete the overview folder and files.

• Move the following files to the root directory of the Sphinx project: additional-resources.rst,service-updates.rst
• Copy the About API description from overview/index.rst to the beginning of the main index.rst file so that the API description is the first information in the API Guide.
• Move any other files in the overview folder to the root directory, and either integrate the content into another topic, or add the file in the index.rst toctree where it makes sense.
• Delete the overview folder.
• Update the index.rst toctree directive to add additional-resources and service-updates. Add them after the release-notes file and before the copyright as shown in the index.rst template.

After you complete the overview updates, run the local Sphinx build. Resolve any errors. Then, run the following command to review the local build output to verify that the API description, Additional resources and Service updates content renders correctly: open _build/html/index.html

Getting started updates

For the Getting Started section, use the following instructions to refactor the common content and the product-specific Getting Started content.

Update common gs-section

• Copy the common-gs folder with the [API Guide template files].(https://github.com/rackerlabs/docs-common/tree/master/api-guide-template/common-gs)

• View the diff of the new content against your existing content.

  If you have any content that's not included in the common content, determine whether it
  needs to be added to the template. If not, then put the content in a different location so
  that the common content is the same across all API Guides. If necessary, open a
  docs-common issue issue
  to update the template or determine how to handle the custom content. All common-gs
  content must be the same.

The changes made to the common-gs content include the following:

• Adjust heading levels in auth-using-curl.rst to move everything up one level.
• Update get-credentials to move heading up a level and remove Cloud Control Panel login info.
• How-to-use-curl minor edits and add Windows cURL info.
• Wrap all lines at 79 characters and remove trailing spaces.
• Miscellaneous editorial improvements.

Update Getting Started section

• Add the get-credentials-include.rst file to the getting-started folder. This file embeds the common get-credentials.rst topic at the H2 level.
• Move concepts.rst file from the root directory to the getting-started folder.
• Update authentication.rst to append Identity endpoint information at end of last paragraph. See authentication template.
• Update send-request-ovw.rst to change intro sentence to refer to section and
  remove link definition for Cloud Control panel. See Send API request template.
• Update index.rst (See template.)
  • Copy the heading and opening paragraph from getting-started.rst to the
    top of getting-started/index.rst.
  • Remove bold format from heading.
  • Add the prerequisite information after the opening paragraph following the getting-started topic template
  • Update toctree specification:
    * Add get-credentials-include file at the top of the list.
    * Remove prerequisites topic.
    * Add concepts.rst after authentication.rst topic.

After you complete the Getting Started updates, rebuild the Sphinx project. Resolve any errors. Then, review the local build output to verify that the content renders correcctly and that it matches the Getting started template.

Developer Guide updates

The Developer Guide refactoring moves the content from the Developer Guide introduction to the main index.rst file.

• index.rst updates:
  • Copy Developer Guide intro about audience and prerequisite knowledge to root index.rst intro before the paragraph with links to the sections of the API documentation. See root index.rst template.
  • Remove the link to the Developer Guide section.
  • Update the toctree specification to remove developer-guide
• Delete the developer-guide.rst file from the root directory

After you complete the Developer Guide updates, rebuild the Sphinx project. Resolve any errors. Then, preview the local build output to verify that the Developer Guide section was removed.

General API info updates

When you refactor the General API section, the main changes are removing the authentication
topic and adjusting the heading levels.

• Change index.rst heading level to

=======================
General API information
=======================

• Update general-api-info/index.rstto append a reference to the Getting Started authentication section. (See General API info index.rst template.)
• Update the toctree directive to remove the filename for the authentication topic.
• Delete the authentication source file from the getting-started directory.
• Change headings in sub-topics to H1 and H2 (~~~~~) per template.
• Compare general api source files to the source in the API template directory, and update to match common content where possible. If you have common files in your source that are not in the template directory or significantly deviate from the template source file, add a link to the github source for that file to the General API info source file issue](https://github.com/rackerlabs/docs-common/issues/62).

After you complete the Getting Started updates, rebuild the Sphinx project. Resolve any errors, Then, review the local build output to verify that the content renders correctly and that it matches the General API information template.

API Reference updates

When you refactor the API reference section, the main changes are relocating the api-reference heading to api-reference/index.rst topic and adjusting the heading levels in the methods section.

• Rename api-operations folder to api-reference
• Update the exclude_pattern configuration in conf.py with the new name.
• Update api-reference/index.rst to follow template
• Check api-reference.rst in the root directory to make sure it doesn't have any additional
  information not included in the updated api-reference/index.rst file. If no extra content, delete the file. If additional content is included and still needed, move it to the index.rst file.
• Update root index.rst with new path to api-reference/index.rst.
• Change api resource topic heading levels to h1 (====).
• Change api method heading levels to h2 (~~~~~~~~~).
• Change request and response heading levels to h3 (-------).

After you complete these updates, rebuild the Sphinx project. Resolve any errors. Then, review the local build output to verify that the content renders correctly and that it matches the API Reference API reference template.

Release notes updates

When you refactor the API reference section, the main change is relocating the Release notes heading and introduction to release-notes/index.rst, moving the release note topics to a sub-folder, and including all release notes topic in index.rst. You also need to add the new release-notes folder to the exclude_patterns specification in the Sphinx configuration file, conf.py.

• Move release-notes.rst to release-notes folder and rename to index.rst.
• Set up all release note content to render in a single topic.
  • Create a releases sub-folder in the release-notes directory.
  • Move individual release notes files into the releases folder.
  • Update release-notes/index.rst to include all release files.
    Use the .. include:: directive
• release-notes/index.rst updates: - [x] Change refid to.._release-notes-collection:. - [x] Updaterelease-notes/index.rstto include all release files using the.. include::`` directive. See template.
  • Remove bold format from title.
• Main index.rst updates
  • Update link to release note section to use new
    refid = release-notes-collection.
  • Update toctree specification with path to release-notes/index
• Update the exclude_patterns specification in the Sphinx configuration file conf.py to
  add the release-notes/releases path.

After you complete the updates, rebuild the Sphinx project. Resolve any errors. Then, review the local build output to verify that the content renders correctly and that it matches the API Guide Release notes template.

Root index.rst updates

Many of the refactoring changes in the root index.rst file were completed when you refactored earlier section. These instructions provide a summary of the changes so you can verify them.

• Ensure the first paragraph provides information about audience and prerequisite knowledge like the root index.rst template.
• Update the links to API Guide sections
  • Remove Developer-Guide
  • Change release-notes ref ID to release-notes-collection
• Update files in toctree directive to follow this pattern:

   Product name v# <https://developer.rackspace.com/docs/cloud-load-balancers/v1/>
   getting-started/index
   general-api-info/index
   api-reference/index
   release-notes/index
   service-updates
   additional-resources
   copyright

Changes include:

• Add the following file names:
  • additional-resources.rst
  • service-updates.rst
• Delete the following file names:
  • getting-started.rst topic
  • prerequisites-for-using-api.rst
  • concepts.rst
  • developer-guide.rst
  • api-reference.rst

Note: If your project contains additional source files not included in this list, add them to Issue #62 in the docs-common repo. Include them in the content architecture where it makes sense. IA team can review.

Next steps

After you complete the refactor work, submit a PR against your upstream repository and follow the Review instructions.

Copied from https://github.com/rackerlabs/docs-migration/issues/109 on 7/27/2016

Per rackerlabs/docs-cloud-files#65 (comment)

Kelly edited the contributor collateral, and we added a CONTRIBUTING.md so that users get the link to contributor instructions when working in the repo.

Using [Cloud Identity](https://github.com/rackerlabs/docs-cloud-identity] as a model, update the info for contributors:

• Revise README.md
• Add CONTRIBUTING.md
• Add GITHUBING.md

Update all links and naming to match product.

Refactor API Guide: QE checklist

Use the following checklist to verify that API guide refactoring for each service. If you have questions, open a docs-common issue.

Do the QE check against the PR submitted to the master repo. Ask the person who did the refactoring to make you a collaborator on their fork in case you want to submit a PR to correct something.

When you build the refactored Sphinx project, use the make clean html command to build chunked content.

• Review the Strider build log for errors. Notify author about any issues.
• Check for broken links.
• Verify that navigation matches the API Guide template.
• Check the API reference section to verify that the methods for each resource are in a single topic.
• Check the General API information topics to make sure they match the common content where possible.
• Check the Authentication topic in the Getting started section to make sure it matches the common template.
• Check conf.py to make sure it has the updates from the
  template.
• Verify that you can build locally from source.

Instructions/resources here:
https://github.com/rackerlabs/docs-common/blob/master/refactor-api-guide.md
and
rackerlabs/docs-common#68
and
https://github.com/rackerlabs/docs-common/tree/master/api-guide-template

Refactor API Guide checklist

Use the following checklist to guide and track the refactoring work for
each Developer Guide. If you have questions, open a docs-common issue.

When you build the refactored Sphinx project, use the make clean html command to build chunked content. Before you begin refactoring, review restructured text fixes.

Important: If the project contains additional source files or content significantly
different than the template, add a link to the source in Issue #62 in the docs-common repo.

RST coding syntax fixes

Refactoring the API guides gives us a chance to make our RST source files comply with coding best practices. You can make the following changes when you are refactoring, or make the updates in a separate effort. When the changes are complete, check off the list items.

• Wrap all lines to 79 characters.
• Ensure that heading separator lines are the same length as the title

    ====
    Test
    ====

• Use the following symbols for heading separators:
  • H1: over and underline =
  • H2: ~
  • H3: -
  • H4: ^

Tip: If you are using the Atom editor, you can configure the soft wrap feature to reflow text
to 79 characters with a keybinding:

• Set the line length:
  • Click Atom > Preferences > Settings.
  • Change the Preferred Line Length to 79.
  • Make sure that Soft wrap at Preferred Line length is selected.
  • Do not select the Soft wrap selection.
• Reflow text that exceeds 79 characters.
  • Select the line or paragraph.
  • Click alt+cmd+q to reflow the text. If text is indented or has special formatting,
    you have to adjust the text manually.

Note: Don't worry about the line length in code samples or tables for now.

Configuration updates (conf.py)

• Replace everything above the ## -- General configuration line with the first 32 lines from
  the conf.py in the API Guide template.
• Change deconst builder configuration to deconst-serial to build chunked html.
  builder = 'deconst-serial'
#builder = 'deconst-single
• Add the spelling checker extension after the extension modules configuration.
• Ensure that extlinks library matches the one in conf.py template.
• Add sphinx-rtd-template to improve template for local builds.
• Add requirements.txt to the root directory to support local builds
• Update titles to remove "Developer Guide". Follow title pattern in conf.py template.

After you complete the conf.py updates, run the Sphinx build (make clean html) to test that the build still works: make clean html. Resolve any errors.

Note: If the Sphinx build doesn't run, follow the build from source instructions to install the required dependencies.

Overview updates

When you refactor the content in the overview source files, you relocate the content and delete the overview folder and files.

• Move the following files to the root directory of the Sphinx project: additional-resources.rst,service-updates.rst
• Copy the About API description from overview/index.rst to the beginning of the main index.rst file so that the API description is the first information in the API Guide.
• Move any other files in the overview folder to the root directory, and either integrate the content into another topic, or add the file in the index.rst toctree where it makes sense.
• Delete the overview folder.
• Update the index.rst toctree directive to add additional-resources and service-updates. Add them after the release-notes file and before the copyright as shown in the index.rst template.

After you complete the overview updates, run the local Sphinx build. Resolve any errors. Then, run the following command to review the local build output to verify that the API description, Additional resources and Service updates content renders correctly: open _build/html/index.html

Getting started updates

For the Getting Started section, use the following instructions to refactor the common content and the product-specific Getting Started content.

Update common gs-section

• Copy the common-gs folder with the [API Guide template files].(https://github.com/rackerlabs/docs-common/tree/master/api-guide-template/common-gs)

• View the diff of the new content against your existing content.

  If you have any content that's not included in the common content, determine whether it
  needs to be added to the template. If not, then put the content in a different location so
  that the common content is the same across all API Guides. If necessary, open a
  docs-common issue issue
  to update the template or determine how to handle the custom content. All common-gs
  content must be the same.

The changes made to the common-gs content include the following:

• Adjust heading levels in auth-using-curl.rst to move everything up one level.
• Update get-credentials to move heading up a level and remove Cloud Control Panel login info.
• How-to-use-curl minor edits and add Windows cURL info.
• Wrap all lines at 79 characters and remove trailing spaces.
• Miscellaneous editorial improvements.

Update Getting Started section

• Add the get-credentials-include.rst file to the getting-started folder. This file embeds the common get-credentials.rst topic at the H2 level.
• Move concepts.rst file from the root directory to the getting-started folder.
• Update authentication.rst to append Identity endpoint information at end of last paragraph. See authentication template.
• Update send-request-ovw.rst to change intro sentence to refer to section and
  remove link definition for Cloud Control panel. See Send API request template.
• Update index.rst (See template.)
  • Copy the heading and opening paragraph from getting-started.rst to the
    top of getting-started/index.rst.
  • Remove bold format from heading.
  • Add the prerequisite information after the opening paragraph following the getting-started topic template
  • Update toctree specification:
    * Add get-credentials-include file at the top of the list.
    * Remove prerequisites topic.
    * Add concepts.rst after authentication.rst topic.

After you complete the Getting Started updates, rebuild the Sphinx project. Resolve any errors. Then, review the local build output to verify that the content renders correcctly and that it matches the Getting started template.

Developer Guide updates

The Developer Guide refactoring moves the content from the Developer Guide introduction to the main index.rst file.

• index.rst updates:
  • Copy Developer Guide intro about audience and prerequisite knowledge to root index.rst intro before the paragraph with links to the sections of the API documentation. See root index.rst template.
  • Remove the link to the Developer Guide section.
  • Update the toctree specification to remove developer-guide
• Delete the developer-guide.rst file from the root directory

After you complete the Developer Guide updates, rebuild the Sphinx project. Resolve any errors. Then, preview the local build output to verify that the Developer Guide section was removed.

General API info updates

When you refactor the General API section, the main changes are removing the authentication
topic and adjusting the heading levels.

• Change index.rst heading level to

=======================
General API information
=======================

• Update general-api-info/index.rstto append a reference to the Getting Started authentication section. (See General API info index.rst template.)
• Update the toctree directive to remove the filename for the authentication topic.
• Delete the authentication source file from the getting-started directory.
• Change headings in sub-topics to H1 and H2 (~~~~~) per template.
• Compare general api source files to the source in the API template directory, and update to match common content where possible. If you have common files in your source that are not in the template directory or significantly deviate from the template source file, add a link to the github source for that file to the General API info source file issue](https://github.com/rackerlabs/docs-common/issues/62).

After you complete the Getting Started updates, rebuild the Sphinx project. Resolve any errors, Then, review the local build output to verify that the content renders correctly and that it matches the General API information template.

API Reference updates

When you refactor the API reference section, the main changes are relocating the api-reference heading to api-reference/index.rst topic and adjusting the heading levels in the methods section.

• Rename api-operations folder to api-reference
• Update the exclude_pattern configuration in conf.py with the new name.
• Update api-reference/index.rst to follow template
• Check api-reference.rst in the root directory to make sure it doesn't have any additional
  information not included in the updated api-reference/index.rst file. If no extra content, delete the file. If additional content is included and still needed, move it to the index.rst file.
• Update root index.rst with new path to api-reference/index.rst.
• Change api resource topic heading levels to h1 (====).
• Change api method heading levels to h2 (~~~~~~~~~).
• Change request and response heading levels to h3 (-------).

After you complete these updates, rebuild the Sphinx project. Resolve any errors. Then, review the local build output to verify that the content renders correctly and that it matches the API Reference API reference template.

Release notes updates

When you refactor the API reference section, the main change is relocating the Release notes heading and introduction to release-notes/index.rst, moving the release note topics to a sub-folder, and including all release notes topic in index.rst. You also need to add the new release-notes folder to the exclude_patterns specification in the Sphinx configuration file, conf.py.

• Move release-notes.rst to release-notes folder and rename to index.rst.
• Set up all release note content to render in a single topic.
  • Create a releases sub-folder in the release-notes directory.
  • Move individual release notes files into the releases folder.
  • Update release-notes/index.rst to include all release files.
    Use the .. include:: directive
• release-notes/index.rst updates: - [x] Change refid to.._release-notes-collection:. - [x] Updaterelease-notes/index.rstto include all release files using the.. include::`` directive. See template.
  • Remove bold format from title.
• Main index.rst updates
  • Update link to release note section to use new
    refid = release-notes-collection.
  • Update toctree specification with path to release-notes/index
• Update the exclude_patterns specification in the Sphinx configuration file conf.py to
  add the release-notes/releases path.

After you complete the updates, rebuild the Sphinx project. Resolve any errors. Then, review the local build output to verify that the content renders correctly and that it matches the API Guide Release notes template.

Root index.rst updates

Many of the refactoring changes in the root index.rst file were completed when you refactored earlier section. These instructions provide a summary of the changes so you can verify them.

• Ensure the first paragraph provides information about audience and prerequisite knowledge like the root index.rst template.
• Update the links to API Guide sections
  • Remove Developer-Guide
  • Change release-notes ref ID to release-notes-collection
• Update files in toctree directive to follow this pattern:

   Product name v# <https://developer.rackspace.com/docs/cloud-load-balancers/v1/>
   getting-started/index
   general-api-info/index
   api-reference/index
   release-notes/index
   service-updates
   additional-resources
   copyright

Changes include:

• Add the following file names:
  • additional-resources.rst
  • service-updates.rst
• Delete the following file names:
  • getting-started.rst topic
  • prerequisites-for-using-api.rst
  • concepts.rst
  • developer-guide.rst
  • api-reference.rst

Note: If your project contains additional source files not included in this list, add them to Issue #62 in the docs-common repo. Include them in the content architecture where it makes sense. IA team can review.

Next steps

After you complete the refactor work, submit a PR against your upstream repository and follow the Review instructions.

Copied from https://github.com/rackerlabs/docs-migration/issues/109 on 7/27/2016

There is a reference to the KC in the bottom section. Should be How-To articles.

docs-cloud-dns/api-docs/v1/general-api-info/role-based-access-control.rst

https://developer.rackspace.com/docs/cloud-dns/v1/developer-guide/#document-general-api-info/role-based-access-control

They seem to be largely missing!

Hi

Exists any Swagger or OpenAPI files for Cloud DNS API? That help us to maintain sync with specifications and data model.

Best regards.

Pretty sure it should only be 500?
Source: https://github.com/rackerlabs/docs-cloud-dns/blob/annegentle-typo/rst/dev-guide/api-operations/methods/get-list-ptr-records-v1.0-account-rdns-service-name.rst
Output: http://staging.developer.rackspace.com/docs-cloud-dns/#list-ptr-records

Work has been merged with repo. Still needs to be edited, final approval,and added to landing page.
Due 3/17

DNS v2 Devguide needs to be translated to RST. Source is at https://github.com/rackerlabs/docs-cloud-dns/blob/master/src/main/resources/cdns-devguide-2.xml
DNS v2 Getting Started needs to be translated to RST. Source is at https://github.com/rackerlabs/docs-cloud-dns/blob/master/src/main/resources/cdns-getting-started-2.xml
Both docs need latest updates applied (see attachments)
EA release is Feb. 15.
DNS team contacts: Joe McBride, Nicole Hairston, Tim Simmons

1. docs.rackspace is mentioned here: https://developer.rackspace.com/docs/cloud-dns/v1/developer-guide/#document-overview/additional-resources
2. KC is mentioned here: https://developer.rackspace.com/docs/cloud-dns/v1/developer-guide/#document-overview/index

From email Aaron Davis [email protected] July 1st:

Hey sending this to everyone so there is visibility. It appears that we have documentation up for the Managed DNS v2 API which is currently not in an active state. https://developer.rackspace.com/docs/cloud-dns/v2/ is there any way we can get this unpublished as I am currently not aware of any timeline for this product? We had a customer ticket that asked about this https://core.rackspace.com/ticket/170606-17561 Just wanted to reach out to find out more about this as it appears this documentation should probably not be up due to its current state.

self-explanitary :)

• Add disclaimer to Developer Docs Trello card
• Update _deconst.json to add variables to enable Edit on GitHub feature Trello card
• Remove SLA and pricing topic from docs Trello card

James Li [10:49 AM] 6/27/2016
cath6136: DNS-992 was about a new designate v2 endpoint /v2/{tenant}/recordsets which accepts GET only requests to retrieve a single recordset; and list cross-zone recordsets owned by a tenant; and filter cross-zone recordsets.

upstream docs are at: http://docs.openstack.org/developer/designate/rest/v2/recordsets.html#get--recordsets-(uuid-id)

http://docs.openstack.org/developer/designate/rest/v2/recordsets.html#get--recordsets

http://docs.openstack.org/developer/designate/rest/v2/recordsets.html#get--recordsets?KEY=VALUE

cath6136: Some other info about the new endpoint but still under review upstream are: (1) supported KEYs of filtering; (2) Retrieve recordsets on all-tenant calls.

It will be nice if you could make some placeholders in your doc at this point until upstream finally accepts the changes.

Per editor: The guidelines for tables is to use the same guidelines as for lists, and that guideline is "Capitalize the first letter of each list item unless the first letter must be lowercase."

Hi,

There is no JSON example for delete-records:
https://developer.rackspace.com/docs/cloud-dns/v1/api-reference/records/#delete-records

Ptr record parameter table is incomplete:
https://developer.rackspace.com/docs/cloud-dns/v1/api-reference/reverse-dns-ptr-records/#add-ptr-records

Best,
Gin

https://github.com/rackerlabs/docs-rackspace/blob/master/doc/tools/build-from-source.rst