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
Improve API Documentation Guidelines [ci-skip] #45332
Improve API Documentation Guidelines [ci-skip] #45332
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
When you are happy with the changes, would you mind squashing the commits?
Documentation has to be concise but comprehensive. Explore and document edge cases. What happens if a module is anonymous? What if a collection is empty? What if an argument is nil? | ||
Documentation has to be concise. Explore and document edge cases. What happens if a module is anonymous? What if a collection is empty? What if an argument is nil? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's leave this as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't "concise" mean "brief but comprehensive"? 🤔 ...
To me this would read "Documentation has to be brief but comprehensive but comprehensive."
Sounds like unnecessary repetition to me. No?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In common usage, I find that "concise" emphasizes "brief" more than "comprehensive." Here we want to especially emphasize "comprehensive" ("Explore and document edge cases..."), so I think the current way is fine. But if it troubles you, we can change "concise" to "brief."
|
||
The proper names of Rails components have a space in between the words, like "Active Support". `ActiveRecord` is a Ruby module, whereas Active Record is an ORM. All Rails documentation should consistently refer to Rails components by their proper name, and if in your next blog post or presentation you remember this tidbit and take it into account that'd be phenomenal. | ||
The proper names of Rails components have a space in between the words, like "Active Support". `ActiveRecord` is a Ruby module, whereas Active Record is an ORM. All Rails documentation should consistently refer to Rails components by their proper names. It'd be phenominal if you took this tidbit into account in your next blog post or presentation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I read that last sentence, I imagine it is said with a wink. But other readers might not pick up on that (and I don't think we add emojis to guides 🤔), so perhaps we should just omit that sentence.
The proper names of Rails components have a space in between the words, like "Active Support". `ActiveRecord` is a Ruby module, whereas Active Record is an ORM. All Rails documentation should consistently refer to Rails components by their proper names. It'd be phenominal if you took this tidbit into account in your next blog post or presentation. | |
The proper names of Rails components have a space in between the words, like "Active Support". `ActiveRecord` is a Ruby module, whereas Active Record is an ORM. All Rails documentation should consistently refer to Rails components by their proper names. |
Or we could go BIG.
The proper names of Rails components have a space in between the words, like "Active Support". `ActiveRecord` is a Ruby module, whereas Active Record is an ORM. All Rails documentation should consistently refer to Rails components by their proper names. It'd be phenominal if you took this tidbit into account in your next blog post or presentation. | |
The proper names of Rails components have a space in between the words, like "Active Support". `ActiveRecord` is a Ruby module, whereas Active Record is an ORM. All Rails documentation should consistently refer to Rails components by their proper names. | |
TIP: Using proper component names in your blog posts and presentations demonstrates that you are a Rails professional! |
(I'm only half joking.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll emphasise "should" instead like should.
|
||
Spell names correctly: Arel, minitest, RSpec, HTML, MySQL, JavaScript, ERB. When in doubt, please have a look at some authoritative source like their official documentation. | ||
Spell names correctly: Arel, minitest, RSpec, HTML, MySQL, JavaScript, ERB, Hotwire. When in doubt, please have a look at some authoritative source like their official documentation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice addition! 👍
@@ -283,7 +283,7 @@ In lists of options, parameters, etc. use a hyphen between the item and its desc | |||
# * <tt>:allow_nil</tt> - Skip validation if attribute is +nil+. | |||
``` | |||
|
|||
The description starts in upper case and ends with a full stop-it's standard English. | |||
The description starts in upper case and ends with a full stop--it's standard English. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this will be rendered in a proportional (not monospace) font, let's use a true em dash:
The description starts in upper case and ends with a full stop--it's standard English. | |
The description starts in upper case and ends with a full stop—it's standard English. |
Documentation has to be concise but comprehensive. Explore and document edge cases. What happens if a module is anonymous? What if a collection is empty? What if an argument is nil? | ||
Documentation has to be concise. Explore and document edge cases. What happens if a module is anonymous? What if a collection is empty? What if an argument is nil? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In common usage, I find that "concise" emphasizes "brief" more than "comprehensive." Here we want to especially emphasize "comprehensive" ("Explore and document edge cases..."), so I think the current way is fine. But if it troubles you, we can change "concise" to "brief."
|
||
The proper names of Rails components have a space in between the words, like "Active Support". `ActiveRecord` is a Ruby module, whereas Active Record is an ORM. All Rails documentation should consistently refer to Rails components by their proper name, and if in your next blog post or presentation you remember this tidbit and take it into account that'd be phenomenal. | ||
The proper names of Rails components have a space in between the words, like "Active Support". `ActiveRecord` is a Ruby module, whereas Active Record is an ORM. All Rails documentation *should* consistently refer to Rails components by their proper names. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm unclear on the purpose of the asterisks...?
When I read that sentence aloud with vocal emphasis on "should", it sounds like I am saying "All Rails documentation probably consistently refers to Rails components by their proper names. (It should, but I don't know if it actually does.)"
Without the asterisks, it sounds like I am stating a fact, with the expectation that the fact will remain true. (i.e. I expect the audience to uphold the truth of that statement.)
Are we happy with the changes here? @jonathanhefner ;) |
Looks great! Thank you, @siaw23! 😄 (Backported to |
…ment Improve API Documentation Guidelines [ci-skip] (cherry picked from commit 0adc234)
Summary
Other Information