-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Extract long remarks #9535
Extract long remarks #9535
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
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.
System.Runtime.InteropServices LGTM
I know this will not change anything and I don't expect it to, but I wanted to express my opinion on this. I think this just inserts another obstacle between the user and the information they need. IMO API docs are the gateway to .NET docs. If the information is not in the API docs, it doesn't exist for many users. And lately, we've been slowly removing valuable information from API docs and just leaving the useless "Gets or sets the name of the object" behind. And it makes me sad, because these docs used to be one of the best I ever used. |
Regarding @ManickaP's comment I think the goal here is to find a balance between usability on the customer side and maintainability on our side. I assume there are good reasons for keeping IMO the ideal solution would be to maintain long remarks separately (still in this repo), but make the tooling copy the remarks into the resulting API doc html pages. |
@ManickaP Now is the time to get this right, so your feedback matters. It sounds like most everyone including @carlossanlop @stephentoub thinks the best solution is for all the Remarks (or perhaps anything longer than a couple sentences) to be published inline via Include files that live in this (dotnet-api-docs) repo. (For 1-2 sentence remarks, those can probably live directly in the ///?) The purpose of this PR was to extract any really, really long remarks into the conceptual docs, to ease page navigation and to utilize all the grammar/link checks we get in the conceptual docs repo. However, if the team doesn't like even this small subset of remarks being moved to conceptual docs, they can certainly be brought in via Include files as well. The downsides that I see for using Include files are that 1) they'd require PRs in this (dotnet-api-docs) repo to edit, and once /// is source of truth, edits would otherwise be disabled in this repo and 2) long remarks are difficult to navigate in the API docs presentation.
Regarding this comment, can you elaborate on how information has been removed (other than this PR)? Or is it just that information hasn't been added for the newer APIs? |
This comment was marked as outdated.
This comment was marked as outdated.
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.
Left some comments for you to consider. Feel free to address them in a separate PR if you prefer. Looks good enough for merging as is.
Learn Build status updates of commit 41600dd:
|
It's both. For example, I rarely see us adding example usages with new APIs. And with removing the info, for example here and here where we removed code samples because they were out of date, instead of updating them. |
Contributes to dotnet/docs#37859