Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

(DOCSP-11407): Update Parameters page #40

Open
wants to merge 2 commits into
base: style-guide-v3
Choose a base branch
from
Open

(DOCSP-11407): Update Parameters page #40

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7623ade
(DOCSP-11407): Update Parameters page
melissamahoney-mongodb Jul 23, 2020
b14bb3d
copy review
melissamahoney-mongodb Jul 29, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 4 additions & 14 deletions source/style-guide/style/parameters.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,9 @@
Parameters
==========

.. include:: /style-guide/includes/page-needs-update.rst
atsansone marked this conversation as resolved.
Show resolved Hide resolved
.. default-domain:: mongodb

.. include:: /includes/styles/corrections.rst

When documenting parameters, use the following guidelines:

Expand All @@ -20,25 +22,13 @@ When documenting parameters, use the following guidelines:

- Write the first sentence of a description with an implied
subject. For example, if the parameter is ``name``, the
description might be "Server name, which becomes the initial host
name of the server."
description might be "Initial host name of the server."
Comment on lines 24 to +25
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: Do we specify when to use the .. example:: block vs. inline? I think it should be more than one line, use a block.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of scope here, but noted.


- Include any valid values and default value at the end of the
description. Use the formats "Valid values are *n* and *n*." and
"The default is *n*." For example, "Valid values are ``true`` and
``false``." and "The default is ``false``."
Comment on lines 27 to 30
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: For body params, I have used:

Suggested change
- Include any valid values and default value at the end of the
description. Use the formats "Valid values are *n* and *n*." and
"The default is *n*." For example, "Valid values are ``true`` and
``false``." and "The default is ``false``."
- Include any valid values and default value at the end of the
description. Use the formats "Application accepts *m* and *n*." and
"The default is *n*." For example, "Atlas accepts ``true`` and
``false``." and "The default is ``false``."

For responses, I use:

Suggested change
- Include any valid values and default value at the end of the
description. Use the formats "Valid values are *n* and *n*." and
"The default is *n*." For example, "Valid values are ``true`` and
``false``." and "The default is ``false``."
- Include any valid values and default value at the end of the
description. Use the formats "Application returns *m* or *n*." and
"The default is *n*." For example, "Atlas returns ``true`` or
``false``." and "The default is ``false``."

The reason is to remove ambiguity as to whether something is probable, possible, or acceptable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a fair point, but also makes things harder for content reuse.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: Yes, but that's a problem for later. Right now, we have an issue with trying to figure out "acceptable" vs. "possible". Making it active voice fixes that. If this is a living doc, make this change and we can revisit post-OpenAPI.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may be a moot point with OpenAPI, but it has been hard to determine the word with the best connotation: "acceptable"? "valid"? "possible"? All of those sound like they're part of what's acceptable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also addressed this in PR #64


- For request body parameters only, label the required parameters by
adding the *(Required)* qualifier to the beginning of the
description. For example:

*(Required)* Path of the parameter to update. Valid values are
``/enabled``, ``/vault/region``, ``/vault/use_internal``, and
``/log-level``.

Don't label optional request body parameters. Also, don't label URI,
query, or response body parameters as either optional or required.

- When listing and describing request and response body parameters in
tables, show the parameters in the same order as they're shown in
the examples. If you have more than one example, match the order in
Expand Down