-
Notifications
You must be signed in to change notification settings - Fork 111
Enhance abstract skill for DITA short descriptions #4814
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
Changes from all commits
779de82
5d24fe6
9941009
98a5f4d
556cd90
f962926
3d32b37
7f8e893
85081dc
3b77ef0
33fc77f
b9055e6
57f41ce
e688592
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,6 +1,6 @@ | ||
| --- | ||
| name: abstract | ||
| description: Review or write abstract | ||
| description: Review or write an abstract (also called a short description) for a documentation module | ||
| --- | ||
| # Review or write abstract | ||
|
|
||
|
|
@@ -26,31 +26,13 @@ Abstracts typically contain the following information: | |
|
|
||
| When reviewing or writing the abstract, follow these principles: | ||
|
|
||
| - Ensure the abstract explains the What and the Why as defined in the section "Definition of an abstract". | ||
| - For the `What` part, state the action or feature clearly. For example, what the user must do or can do (in procedure modules), what the user needs to understand (in concept modules), or what is being listed (in reference modules). | ||
| - For the `Why` part, state the business value, benefit, or goal. For example, why the user should complete the action (in procedure modules), why the concept is important to users (in concept modules), or why the user would look up the information (in reference modules). | ||
| - For the `Example use case part`, consider including in what situations a user might find the contents of the module useful. | ||
| - Do not simply repeat the heading of the module; build upon it. | ||
| - Follow these user-centric language guidelines: | ||
| - Avoid documentation self-referential language (for example: avoid "This procedure..." or "This module"). | ||
| - Avoid feature-centric language (for example: avoid "This feature..."). | ||
| - Use user-centric language (for example: use phrases such as "You can [action] to [benefit]", "To [goal], configure [feature]", "[Action] [what] to [why]"). | ||
| - Do not simply repeat the heading of the module; build upon it. | ||
| - Avoid self-referential language (for example: avoid "This procedure...", "This module...", "This table..."). | ||
| - Avoid feature-centric language (for example: avoid "This feature..."). | ||
| - Do not use sentence fragments. | ||
| - When addressing the user, address them as "you". | ||
| - Follow these length constraints: 50-300 characters, 1-2 sentences, a single paragraph. | ||
|
|
||
| ## Examples of good abstracts | ||
|
|
||
| | Heading | Example abstract (procedure) | | ||
| | :--- | :--- | | ||
| | Browsing hosts in {ProjectWebUI} | Find and categorize your hosts within {Project} to get a quick overview of your managed infrastructure. Browsing hosts helps you understand your environment and identify specific host types for targeted actions. | | ||
| | Cloning hosts in {Project} | Clone existing hosts in {Project} to quickly create new hosts with similar configurations. This streamlines deployment processes and improves consistency across your environment. | | ||
| | Editing system purpose | Edit the system purpose attributes for your Red Hat Enterprise Linux hosts to help ensure they receive correct subscriptions and accurate reporting. This optimizes license compliance and management. | | ||
|
|
||
| | Heading | Example abstract (concept) | | ||
| | :--- | :--- | | ||
| | Security considerations in {Project} | {Project} supports multiple security mechanisms to provide additional layers of protection. Implementing these security features enhances the overall security of your {Project} deployment. | | ||
| | Overview of authentication methods in {Project} | The authentication methods you can configure depend on the authentication source you are using. If the native authentication features provided by {Project} are not sufficient for your use case, use this information to decide which external authentication provider best suits your requirements. | | ||
|
|
||
| | Heading | Example abstract (reference) | | ||
| | :--- | :--- | | ||
| | Subscriptions usage data | For the purposes of expense management and to optimize your spending, track your subscriptions usage data that you can get from your {Project} environment and Red Hat. You can track usage, capacity, and utilization of your Red Hat subscriptions. | | ||
| | Host global status overview | You can use the host global status in {Project} to see at a glance whether a host is OK, needs attention (Warning), or has errors. The status appears on the Hosts Overview page and helps you prioritize which hosts to investigate. | | ||
| - For module-type-specific abstract rules, look up the reference file that matches the `:_mod-docs-content-type:` AsciiDoc attribute in the module (open and apply that file in full): | ||
| - `CONCEPT` → [references/concept.md](references/concept.md) | ||
| - `PROCEDURE` → [references/procedure.md](references/procedure.md) | ||
| - `REFERENCE` → [references/reference.md](references/reference.md) | ||
|
Comment on lines
+35
to
+38
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would it be possible to include the specific guidelines here instead of in separate files? Or does the approach with separate files have any benefits?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Or actually, how about we pull in modular templates as a separate skill/skill reference, and include these specifics in those templates? Pulling the templates into this repo was proposed before in #4722, and I was against it, but I'm not sure how much longer the modular guides and templates will keep being supported and updates. Perhaps it's time we took ownership of them here as a project resource? Then these abstract instructions could be integrated with the abstract part of each template.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What do modular templates have to do with the content of short descriptions? Separating the specific instructions for each type - I did that based on best practices for agent skills.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fair enough, I can look into it myself later. |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,13 @@ | ||
| # Abstract instructions: concept modules | ||
|
|
||
| When the module is a concept module (is named `con_*.adoc` or includes `:_mod-docs-content-type: CONCEPT` as its first line), follow these rules for the abstract (short description): | ||
|
|
||
| - Introduce the concept and provide a concise answer to the question "What is this?" and in some cases "How is this knowledge useful to the user?" | ||
| - Avoid using the short description to lead in or build up to a topic. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What does this mean? A short description does introduce a topic.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's supposed to summarize the topic, not introduce it. |
||
|
|
||
| ## Examples of good abstracts | ||
|
|
||
| | Heading | Example abstract (concept) | | ||
| | :--- | :--- | | ||
| | Security considerations in {Project} | {Project} supports multiple security mechanisms to provide additional layers of protection. Implementing these security features enhances the overall security of your {Project} deployment. | | ||
| | Overview of authentication methods in {Project} | The authentication methods you can configure depend on the authentication source you are using. If the native authentication features provided by {Project} are not sufficient for your use case, use this information to decide which external authentication provider best suits your requirements. | | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,16 @@ | ||
| # Abstract instructions: procedure modules | ||
|
|
||
| When the module is a procedure module (is named `proc_*.adoc` or includes `:_mod-docs-content-type: PROCEDURE` as its first line), follow these rules for the abstract (short description): | ||
| - Explain the task that users can accomplish, the benefits of the task, and the purpose of the task. | ||
| - Do not simply repeat the title. | ||
| - Include information that will help users understand when the task is appropriate or necessary. | ||
| - Use phrases such as "You can [action] to [benefit]", "To [goal], configure [feature]", or "[Action] [what] to [why]". | ||
| - When the abstract is too short or generic, add more information about why the task is beneficial. | ||
|
|
||
| ## Examples of good abstracts | ||
|
|
||
| | Heading | Example abstract (procedure) | | ||
| | :--- | :--- | | ||
| | Browsing hosts in {ProjectWebUI} | Find and categorize your hosts within {Project} to get a quick overview of your managed infrastructure. Browsing hosts helps you understand your environment and identify specific host types for targeted actions. | | ||
| | Cloning hosts in {Project} | Clone existing hosts in {Project} to quickly create new hosts with similar configurations. This streamlines deployment processes and improves consistency across your environment. | | ||
| | Editing system purpose | Edit the system purpose attributes for your Red Hat Enterprise Linux hosts to help ensure they receive correct subscriptions and accurate reporting. This optimizes license compliance and management. | |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,12 @@ | ||
| # Abstract instructions: reference modules | ||
|
|
||
| When the module is a reference module (is named `ref_*.adoc` or includes `:_mod-docs-content-type: REFERENCE` as its first line), follow these rules for the abstract (short description): | ||
|
|
||
| - Briefly describe what the reference item does, what it is, or what it is used for. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "reference item" seems unclear
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's the "thing being referenced in the module". I don't know how else to call it. It seems clear enough to me. I'm open to suggestions. |
||
|
|
||
| ## Examples of good abstracts | ||
|
|
||
| | Heading | Example abstract (reference) | | ||
| | :--- | :--- | | ||
| | Subscriptions usage data | For the purposes of expense management and to optimize your spending, track your subscriptions usage data that you can get from your {Project} environment and Red Hat. You can track usage, capacity, and utilization of your Red Hat subscriptions. | | ||
| | Host global status overview | You can use the host global status in {Project} to see at a glance whether a host is OK, needs attention (Warning), or has errors. The status appears on the Hosts Overview page and helps you prioritize which hosts to investigate. | | ||
Uh oh!
There was an error while loading. Please reload this page.