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.

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

(DOCSP-11407): Update Parameters page #40

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

Conversation

melissamahoney-mongodb
Copy link
Contributor

JIRA
Staging

Open Q: Do we want to standardize on how we do parameter tables in regards to column headings?

@atsansone atsansone added the feature Merge to Feature Branch label Jul 25, 2020
@atsansone atsansone self-assigned this Jul 25, 2020
@atsansone atsansone added the copy review Review for language, format, and structure label Jul 25, 2020
Copy link
Contributor

@atsansone atsansone left a comment

Choose a reason for hiding this comment

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

@melissamahoney-mongodb : Some additional thoughts here.

source/style-guide/style/parameters.txt Show resolved Hide resolved
Comment on lines 20 to +25
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."
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.

Comment on lines 23 to 30
- 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``."
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

Copy link
Contributor

@atsansone atsansone left a comment

Choose a reason for hiding this comment

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

LGTM % 1 thought.

@atsansone atsansone added RFM Ready for Merge squash Rebase commits before merging and removed copy review Review for language, format, and structure labels Jul 30, 2020
@atsansone atsansone force-pushed the style-guide-v3 branch 3 times, most recently from 477cd3c to 789181e Compare August 4, 2020 07:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Merge to Feature Branch RFM Ready for Merge squash Rebase commits before merging
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants