-
Notifications
You must be signed in to change notification settings - Fork 43
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
DOCS-1270: Improve generic #2143
Conversation
Overall readability score: 55.44 (🟢 +0.01)
View detailed metrics🟢 - Shows an increase in readability
Averages:
View metric targets
|
docs/components/generic/_index.md
Outdated
@@ -14,6 +14,8 @@ no_list: true | |||
|
|||
The _generic_ component {{< glossary_tooltip term_id="subtype" text="subtype" >}} is for custom components that are incompatible with any of the other component APIs. | |||
|
|||
For example, if you have an LED display, it does not make sense to implement it as an arm, camera, or any other existing component subtype because an LED display does not have joints or capture images. |
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.
@andf-viam can you review? I'm not sure my sentence is better but I'd like to avoid "it does not make sense", it just feels like it could sound condescending
For example, if you have an LED display, it does not make sense to implement it as an arm, camera, or any other existing component subtype because an LED display does not have joints or capture images. | |
For example, if you have an LED display, the APIs of other component types, such as arm, camera, and so on, do not fit since the APIs assume that the component has properties, such as having joints or the ability to capture images, that an LED display does not have. |
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.
LGTM with some language suggestions. Thank you!
1. Package your modular resource or modular resources as a {{< glossary_tooltip term_id="module" text="module" >}} and [upload the module to the Viam registry](/modular-resources/upload/) to make it available for deployment to robots. | ||
You can upload _private_ modules for your [organization](/manage/fleet/organizations/) or _public_ modules. | ||
1. Once you have uploaded your module to the registry, you can [deploy and configure the module](/modular-resources/configure/) from [the Viam app](https://app.viam.com/). | ||
You can test your added resource using the [**Control** tab](/manage/fleet/#remote-control) and [program](/program/) it with Viam's Go or Python SDKs. | ||
|
||
### Unique cases |
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.
This header works for me, thanks!
Co-authored-by: andf-viam <[email protected]>
You can view a rendered version of the docs from this PR at https://docs-test.viam.dev/2143/public |
Removed third bullet point since I believe that case falls under Advanced MR