Skip to content

MTA-6826, 6827, 6828, 6829, 6830, 6831 CQA April work for rules development guide#359

Open
Pkylas007 wants to merge 7 commits intomainfrom
mta-6826-6828
Open

MTA-6826, 6827, 6828, 6829, 6830, 6831 CQA April work for rules development guide#359
Pkylas007 wants to merge 7 commits intomainfrom
mta-6826-6828

Conversation

@Pkylas007
Copy link
Copy Markdown
Collaborator

@Pkylas007 Pkylas007 commented Apr 17, 2026

JIRA

Version

  • 8.1.0

Preview

Summary by CodeRabbit

  • Documentation
    • Standardized product/CLI placeholders and shifted references from a generic product name to parameterized placeholders.
    • Normalized language/provider names and inline code formatting (including “C#” and Java locations).
    • Clarified guidance for creating custom rules, provider capabilities, hyperlinks, and Java provider details.
    • Updated CLI/example placeholders, cross-references, abstracts and conditional includes; removed an obsolete rule-conditions include.

Signed-off-by: Prabha Kylasamiyer Sundara Rajan <pkylasam@pkylasam-thinkpadp16vgen1.bengluru.csb>
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Apr 17, 2026

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 00c29709-3cdb-4715-b2c3-d0338023cb89

📥 Commits

Reviewing files that changed from the base of the PR and between edf9380 and e4b7e99.

📒 Files selected for processing (3)
  • docs/topics/rules-development/create-first-yaml-rule.adoc
  • docs/topics/rules-development/yaml-builtin-provider.adoc
  • docs/topics/rules-development/yaml-java-locations.adoc
✅ Files skipped from review due to trivial changes (2)
  • docs/topics/rules-development/create-first-yaml-rule.adoc
  • docs/topics/rules-development/yaml-builtin-provider.adoc
🚧 Files skipped from review as they are similar to previous changes (1)
  • docs/topics/rules-development/yaml-java-locations.adoc

📝 Walkthrough

Walkthrough

Documentation-only edits across the Rules Development guide: replaced hardcoded product/CLI names with parameterized placeholders, reordered Asciidoc conditionals, renamed/retitled provider labels and inline code formatting, removed one rule-conditions include, and updated a cross-reference target.

Changes

Cohort / File(s) Summary
Assembly metadata & conditionals
assemblies/rules-development-guide/assembly_creating-rule.adoc, assemblies/rules-development-guide/assembly_java-conditions-detailed.adoc, assemblies/rules-development-guide/assembly_rules-introduction.adoc
Replaced hardcoded product/CLI references with parameter placeholders; reordered/relocated AsciiDoc conditional directives and switched some parent-context checks to parent-context-of-rules-introduction.
Providers, labels & formatting
docs/topics/rules-development/yaml-dotnet-provider.adoc, docs/topics/rules-development/yaml-java-provider.adoc, docs/topics/rules-development/yaml-java-locations.adoc, docs/topics/rules-development/yaml-provider-conditions.adoc, docs/topics/rules-development/create-csharp-custom-rule.adoc, docs/topics/rules-development/create-first-yaml-rule.adoc, docs/topics/rules-development/yaml-chaining-condition-variables.adoc, docs/topics/rules-development/yaml-condition-patterns.adoc, docs/topics/rules-development/yaml-rule-hyperlinks.adoc, docs/topics/rules-development/about-rules.adoc, docs/topics/rules-development/con_provider-capability-in-custom-rules.adoc, docs/topics/rules-development/yaml-builtin-provider.adoc
Text and inline formatting updates: csharpC# in wording, many provider/capability/location identifiers backticked, minor phrasing and placeholder adjustments, clarified Java LSP naming, and one cross-reference target updated. No schema or behavioral changes.
Removed include
docs/topics/rules-development/yaml-rule-conditions.adoc
Deleted the "Rule conditions" reference/include (file no longer contributes that section).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

Suggested reviewers

  • anarnold97
  • mguetta1
  • mpershina

Poem

🐰 I hopped through docs with ribbons of code,
Swapped names and backticks down the rabbit road.
Conditionals shuffled, cross-refs tucked tight,
C# wore a bow and the pages feel right.
Hooray — the rules guide sleeps cozy tonight!

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title references six JIRA issue IDs (MTA-6826, 6827, 6828, 6829, 6830, 6831) and 'CQA April work for rules development guide', clearly indicating the PR addresses Content Quality Assurance fixes across multiple issues for the rules development guide documentation. This directly corresponds to the PR objectives.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch mta-6826-6828

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
docs/topics/rules-development/yaml-java-locations.adoc (1)

114-123: ⚠️ Potential issue | 🟠 Major

Align location keyword with example (FIELD vs FIELD_DECLARATION).

Line 114 lists FIELD, but the example at Lines 121-123 uses FIELD_DECLARATION. Please make these consistent; otherwise readers may use an invalid location value in rules.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@docs/topics/rules-development/yaml-java-locations.adoc` around lines 114 -
123, The location keyword is inconsistent: the table lists `FIELD` but the
example uses `FIELD_DECLARATION`; update one so both match. Edit the example in
the java.referenced block or the table entry so the location value is the same
(choose either `FIELD` or `FIELD_DECLARATION`) and ensure the example's when ->
java.referenced -> location uses that exact token; keep the rest (pattern:
javax.jms.QueueConnectionFactory) unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@docs/topics/rules-development/yaml-dotnet-provider.adoc`:
- Line 12: Replace the standalone acronym "gRPC" in the sentence that begins
"The `C#` provider uses a gRPC interface..." by expanding it on first use as
"Google Remote Procedure Call (gRPC)" and then retain the abbreviation "gRPC"
for subsequent mentions; update the sentence containing the term `gRPC` so it
reads with the full name followed by the abbreviation.

In `@docs/topics/rules-development/yaml-java-locations.adoc`:
- Line 146: The DESCRIPTION for the `CLASS` declaration is wrong: update the row
that reads "`CLASS` (declaration) Matches against a given method declaration" to
describe class declarations instead—e.g., say "`CLASS` (declaration) Matches
against a given class declaration; can be coupled with an annotation match (see
Annotation inspection)". Modify the text for the `CLASS` entry in
yaml-java-locations.adoc to replace "method declaration" with "class
declaration" and keep the note about coupling with annotations/reference to the
Annotation inspection page.

In `@docs/topics/rules-development/yaml-provider-conditions.adoc`:
- Around line 325-329: The row describing the `builtin.json` capability uses the
phrase "an XPath query" which conflicts with earlier terminology (`jsonpath`);
update the phrase "an XPath query" to "a JSONPath query" (or "a jsonpath
expression") so the `builtin.json` row consistently references JSONPath/jsonpath
like the earlier JSON capability text.

---

Outside diff comments:
In `@docs/topics/rules-development/yaml-java-locations.adoc`:
- Around line 114-123: The location keyword is inconsistent: the table lists
`FIELD` but the example uses `FIELD_DECLARATION`; update one so both match. Edit
the example in the java.referenced block or the table entry so the location
value is the same (choose either `FIELD` or `FIELD_DECLARATION`) and ensure the
example's when -> java.referenced -> location uses that exact token; keep the
rest (pattern: javax.jms.QueueConnectionFactory) unchanged.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 67d7ee91-99a7-4c2f-a69a-16d41e10c933

📥 Commits

Reviewing files that changed from the base of the PR and between 28c1418 and 0ccdf3d.

📒 Files selected for processing (7)
  • assemblies/rules-development-guide/assembly_creating-rule.adoc
  • assemblies/rules-development-guide/assembly_java-conditions-detailed.adoc
  • assemblies/rules-development-guide/assembly_rules-introduction.adoc
  • docs/topics/rules-development/yaml-dotnet-provider.adoc
  • docs/topics/rules-development/yaml-java-locations.adoc
  • docs/topics/rules-development/yaml-provider-conditions.adoc
  • docs/topics/rules-development/yaml-rule-conditions.adoc
💤 Files with no reviewable changes (1)
  • docs/topics/rules-development/yaml-rule-conditions.adoc

Comment thread docs/topics/rules-development/yaml-dotnet-provider.adoc
Comment thread docs/topics/rules-development/yaml-java-locations.adoc Outdated
Comment thread docs/topics/rules-development/yaml-provider-conditions.adoc
Prabha Kylasamiyer Sundara Rajan added 2 commits April 17, 2026 16:01
Signed-off-by: Prabha Kylasamiyer Sundara Rajan <pkylasam@pkylasam-thinkpadp16vgen1.bengluru.csb>
Signed-off-by: Prabha Kylasamiyer Sundara Rajan <pkylasam@pkylasam-thinkpadp16vgen1.bengluru.csb>
@Pkylas007 Pkylas007 changed the title NTA-6826, 6827, 6828 CQA April work for rules development guide MTA-6826, 6827, 6828 CQA April work for rules development guide Apr 20, 2026
@Pkylas007 Pkylas007 changed the title MTA-6826, 6827, 6828 CQA April work for rules development guide MTA-6826, 6827, 6828, 6829, 6830, 6831 CQA April work for rules development guide Apr 20, 2026
Signed-off-by: Prabha Kylasamiyer Sundara Rajan <pkylasam@pkylasam-thinkpadp16vgen1.bengluru.csb>
@Pkylas007 Pkylas007 requested a review from vashirova April 20, 2026 09:55
@anarnold97
Copy link
Copy Markdown
Collaborator

JIRA CQA Analysis and Remediation Summary: PR #359

Document Title: Configuring and using rules for an MTA analysis Analysis Date: 2026-04-15 Genuine Issues Identified: 10

Pull Request #359 successfully addresses the genuine issues identified in the April 2026 Content Quality Assurance (CQA) report by remediating findings across six JIRA issues (MTA-6826 to MTA-6831).


1. Critical Structural Repairs (MTA-6826)

This JIRA issue focuses on structural integrity and orphaned files.

  • DITA Context Restoration: Fixed a critical copy-paste error in assembly_rules-introduction.adoc where the restoration block incorrectly tested the parent-context-of-getting-started attribute instead of parent-context-of-rules-introduction. This previously caused guide-level context to clear prematurely.
  • Orphaned Files: Resolved the status of yaml-rule-conditions.adoc, which was not included in any assembly and contained duplicate content.

2. Branding and Attribute Compliance (MTA-6827)

This JIRA issue ensures product naming meets branding standards.

  • Branding Accuracy: Corrected headings where "C#" was misspelled as "Csharp".
  • Attribute Update: Replaced hardcoded "MTA" and "MTA CLI Guide" strings with proper {ProductShortName} and {UserCLIBookName} attributes.
  • Rendered Text: Updated attribute values from lowercase YAML identifiers ("csharp", "nodejs") to proper product names ("C#", "Node.js") to prevent incorrect prose in rendered Developer Preview notes.
  • Legacy Terms: Updated outdated ".NET Core" references to the modern ".NET" naming convention.

3. Technical Formatting and Accuracy (MTA-6828)

This JIRA issue standardizes YAML properties and provider names.

  • Code Formatting: Applied mandatory backtick formatting to YAML technical identifiers such as builtin, xpath, filecontent, and nameregex when used in prose or tables.
  • XPath Consistency: Standardized the use of "XPath" as the proper noun for the query language in prose, replacing incorrect variations like "xpath" or "Xpath".

4. Readability and Grammar Remediation (MTA-6829)

This JIRA issue targets dense prose and passive construction.

  • Readability Grades: Simplified complex prose in 15 files that exceeded target reading levels. This included yaml-chaining-java-provider.adoc, which was flagged at a significantly high grade level of 17.03.
  • Voice Adjustment: Remediated 37 instances of pervasive passive voice, converting them to the direct, active voice required by Red Hat and IBM standards.

5. Clarity and Style Standardization (MTA-6830 & MTA-6831)

These JIRA issues cover acronym definitions and overall style polish.

  • Acronym Definitions: Ensured technical acronyms like LSP (Language Server Protocol), FQN (Fully Qualified Name), JDTLS (Eclipse JDT Language Server), and SLA (Service Level Agreement) are defined on their first occurrence in each topic.
  • Placeholder Formatting: Standardized user-replaced values in code examples to use underscores as word separators (e.g., <node_name>) instead of hyphens or spaces.
  • Terminology Standardization: Standardized "rule sets" as two words in prose while reserving the one-word "ruleset" for technical file references (e.g., ruleset.yaml).
  • Simplified Vocabulary: Implemented 17 "SimpleWords" suggestions, replacing complex terms like "aggregate" with total, "subsequent" with later, and "previous" with earlier.

Copy link
Copy Markdown
Collaborator

@anarnold97 anarnold97 left a comment

Choose a reason for hiding this comment

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

DITA report

master.adoc

  • 12:1 warning Assign [role="_abstract"] AsciiDocDITA.ShortDescription
    to a paragraph to use it as
    in DITA.

  • 12:1 warning Content other than additional AsciiDocDITA.AssemblyContents
    resources cannot follow
    include directives.

  • 39:1 warning Content other than links AsciiDocDITA.RelatedLinks
    cannot be mapped to DITA
    related-links.

    Are these all false positives?

@Pkylas007
Copy link
Copy Markdown
Collaborator Author

Pkylas007 commented Apr 21, 2026

DITA report

master.adoc

  • 12:1 warning Assign [role="_abstract"] AsciiDocDITA.ShortDescription
    to a paragraph to use it as
    in DITA.
  • 12:1 warning Content other than additional AsciiDocDITA.AssemblyContents
    resources cannot follow
    include directives.
  • 39:1 warning Content other than links AsciiDocDITA.RelatedLinks
    cannot be mapped to DITA
    related-links.
    Are these all false positives?

Hey Andy,

  • 12:1 warning Assign [role="_abstract"] AsciiDocDITA.ShortDescription
    to a paragraph to use it as
    in DITA.
    I discussed this warning with Masha and we decided that master.adoc file in any guide should not have an introduction since the inner assemblies have them.
  • 12:1 warning Content other than additional AsciiDocDITA.AssemblyContents
    resources cannot follow
    include directives.
  • 39:1 warning Content other than links AsciiDocDITA.RelatedLinks
    cannot be mapped to DITA
    related-links.
    These two points seem to be false positives since the rules guide master.adoc has an additional resources section after the include directives and no other content.
    Similarly, the Additional Resources section itself has two links which, IIRC, is allowed.
rules_guide_master-adoc

Copy link
Copy Markdown
Collaborator

@vashirova vashirova left a comment

Choose a reason for hiding this comment

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

@Pkylas007 peer review completed, see my comments. This is a great start! I've noticed some outstanding issues that are applicable to several files:

  • Abstracts - some of them exceed character limit of 300, end with a colon (:), and do not work as standalone text.
  • Leftover "refer to" instances.
  • Complex ifdef syntax in assemblies.
  • Leftover inconsistencies in "rule sets" spelling.
  • Leftover passive voice.
  • Broken syntax for italics.
  • Leftover incorrectly formatted user-replaced values (must be <user_replaced>).
  • Not everything from the linked ticket was addressed.

Let me know when you'd need a second round of review. Thank you.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Outside of scope suggestions for this and other files but must before migration to AEM:

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Outside of scope suggestions but a must before migration to AEM:

  • Shorten/add a new paragraph for abstract as the current one is a bit too long (394 characters instead of 300).
  • Also, it is not standalone text, "Additionally..." right afterwards suggests this. I'd recommend to rework this - either to rewrite the current abstract and following text or add a completely new and separate 300 characters short description. See https://redhat-documentation.github.io/supplementary-style-guide/#shortdesc.


The rules can be used by {mta-dl-plugin} to generate AI-assisted code resolutions. The issue description and metadata in rules are used by the {mta-dl-plugin} to form well-defined contexts. These contexts generate AI-assisted suggestions to resolve issues in the code that are identified through an analysis.

The rules can be used by {mta-dl-plugin} to generate AI-assisted code resolutions. {mta-dl-plugin} uses the issue description and metadata in rules to form well-defined contexts. These contexts generate AI-assisted suggestions to resolve issues in the code that {ProductShortName} identified through an analysis.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

How about this rewrite for the first sentence to remove passive voice?

Plus there are more instances of passive voice in this files and others, too. Is it intentional that we are fixing only this specific instance and not everything?

Suggested change
The rules can be used by {mta-dl-plugin} to generate AI-assisted code resolutions. {mta-dl-plugin} uses the issue description and metadata in rules to form well-defined contexts. These contexts generate AI-assisted suggestions to resolve issues in the code that {ProductShortName} identified through an analysis.
{mta-dl-plugin} can use the rules to generate AI-assisted code resolutions. It uses the issue description and metadata in rules to form well-defined contexts. These contexts generate AI-assisted suggestions to resolve issues in the code that {ProductShortName} identified through an analysis.


:_mod-docs-content-type: ASSEMBLY

ifdef::context[:parent-context-of-java-conditions-capabilities: {context}]
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I'm not entirely sure what we are trying to achieve with this change, could you elaborate on it please

Furthermore, the ifdef syntax with 2 statements seems complex. Typically we'd use ifdef if an assembly is re-used, however I don't think any of the assemblies in this PR are re-used right now? Could we review all this ifdef syntax for all of assemblies and asses if it could be simplified or removed? This could help with the unclosed parent context issue.

Copy link
Copy Markdown
Collaborator Author

@Pkylas007 Pkylas007 Apr 21, 2026

Choose a reason for hiding this comment

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

Thank you for your comment. I'm sorry but the CQA and DITA runs did not catch any unclosed parent context issue. I think the unset issue that is flagged was a false positive.

:context: rules-introduction

[role="_abstract"]
This guide is intended for software engineers who want to create custom YAML-based rules for {ProductName} ({ProductShortName}) tools.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I like that this short description includes the who and the what. The only missing piece according to our guidance https://redhat-documentation.github.io/supplementary-style-guide/#shortdesc is missing user-focused language ("This guide is intended " is self-referential and must be avoided). I suggest to reword it for DITA.


* You installed the `ilspycmd` and `paket` dependencies.
* You installed the `dotnet tools` and exported the `dotnet tools` path by using the `export PATH="$PATH:<path/to/.dotnet/tools"` command.
* You installed the `dotnet tools` and exported the `dotnet tools` path by using the `export PATH="$PATH:_<path_to_.dotnet_tools>_"` command.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

The newly added underscores do not make this user-replaceable value in italic, I'm not sure why. Perhaps we can try double underscores to read it as one piece?

Suggested change
* You installed the `dotnet tools` and exported the `dotnet tools` path by using the `export PATH="$PATH:_<path_to_.dotnet_tools>_"` command.
* You installed the `dotnet tools` and exported the `dotnet tools` path by using the `export PATH="$PATH:__<path_to_.dotnet_tools>__"` command.

Copy link
Copy Markdown
Collaborator Author

@Pkylas007 Pkylas007 Apr 21, 2026

Choose a reason for hiding this comment

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

I agree, the formatting requirements seem complicated and make rendering very tricky.

@@ -62,7 +62,7 @@ You can use a custom rule to check if {ProductShortName} triggers an incident wh

[source, terminal]
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Suggested change
[source, terminal]
[source, terminal,subs="+quotes"]

Changes on line 65 do not work, the user-replaced value is not in italics.


[role="_abstract"]
You can refer to example rules that describe how to create a YAML rule. This assumes that you already have MTA installed. See the MTA CLI Guide for installation instructions.
You can refer to example rules that describe how to create a YAML rule. This assumes that you already have {ProductShortName} installed. See the {ProductShortName} {CLIName} Guide for installation instructions.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I believe this abstract can be improved. First of all, it again uses "refer to" which isn't recommended for docs in general, see https://www.ibm.com/docs/en/ibm-style?topic=word-usage#r. Second, we can be more direct and start with an imperative. Next, as a general rule, I'd argue that referring users to another piece of documentation doesn't belong in short descriptions. Short descriptions meant to help user navigate and should work as a standalone piece. I strongly suggest to review this and other short descriptions.

|Location |Description |Rule condition example

|TYPE|Matches against all types, including classes, interfaces, enums, and annotation types that appear anywhere.
|`TYPE`|Matches against all types, including classes, interfaces, enums, and annotation types that appear anywhere.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Suggested change
|`TYPE`|Matches against all types, including classes, interfaces, enums, and annotation types that appear anywhere.
|`TYPE`|Matches against all types, including classes, interfaces, `enums`, and annotation types that appear anywhere.

Comment on lines 26 to 28
mkdir /home/<USER>/data/
touch /home/<USER>/data/jboss-web.xml
touch /home/<USER>/data/pom.xml
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

This happens to catch my eye. These commands should be separated (one command per one command block) and shell prompt (I think $, based on the previous step) should be added to each.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Thank you for your suggestion! This topic requires a re-write which is not strictly within the scope of work tracked in this PR. I'll get back to you on this 👍

@anarnold97
Copy link
Copy Markdown
Collaborator

Also can we be careful when running DITA

mta-documentation/assemblies/rules-development-guide/topics/rules-development$ vale *.adoc

output:

 create-first-yaml-rule.adoc
 18:1    warning  Content other than a single     AsciiDocDITA.TaskStep 
                  list cannot be mapped to DITA                         
                  steps.                                                
                       
 yaml-builtin-provider.adoc
 7:7    error    Use 'built-in' rather than      RedHat.TermsErrors 
                 'builtin'.                                         
                                   
 yaml-java-locations.adoc
                                              
 63:67    warning  Verify the word 'enums'. It is  RedHat.Spelling     
                   not in the American English or                      
                   Red Hat terminology spelling                        
                   dictionaries used by Vale.                          
                            
 yaml-provider-conditions.adoc
      
 32:15   warning  Verify the word 'csharp'.       RedHat.Spelling           
                  It is not in the American                                 
                  English or Red Hat terminology                            
                  spelling dictionaries used by                             
                  Vale.                                                     
 32:35   warning  Use 'Node.js' rather than       RedHat.CaseSensitiveTerms 
                  'nodejs'.                                                 
                                                  
 180:1   warning  Block titles can only be        AsciiDocDITA.BlockTitle   
                  assigned to examples, figures,                            
                  and tables in DITA.                                       
                                            


 yaml-rule-labels.adoc
 9:175  warning  Verify the word 'rulesets'.     RedHat.Spelling     
                 It is not in the American                           
                 English or Red Hat terminology                      
                 spelling dictionaries used by                       
                 Vale.                                               
 
                                       





 yaml-rulesets.adoc

 23:57   warning  Verify the word 'rulesets'.     RedHat.Spelling     
                  It is not in the American                           
                  English or Red Hat terminology                      
                  spelling dictionaries used by                       
                  Vale.                                               

I think as the Assemblies file is a symlink, it is skewing the results. As you can see when i run vale directly in the Assemblies folder, it is returning more errors.

Also, I know rulesets is a false positive, so please create a new PR to add a vale rule to the MTA file.

Thanks

Prabha Kylasamiyer Sundara Rajan added 2 commits April 22, 2026 14:14
Signed-off-by: Prabha Kylasamiyer Sundara Rajan <pkylasam@pkylasam-thinkpadp16vgen1.bengluru.csb>
Signed-off-by: Prabha Kylasamiyer Sundara Rajan <pkylasam@pkylasam-thinkpadp16vgen1.bengluru.csb>
@Pkylas007
Copy link
Copy Markdown
Collaborator Author

Pkylas007 commented Apr 22, 2026

Also can we be careful when running DITA

mta-documentation/assemblies/rules-development-guide/topics/rules-development$ vale *.adoc

output:

 create-first-yaml-rule.adoc
 18:1    warning  Content other than a single     AsciiDocDITA.TaskStep 
                  list cannot be mapped to DITA                         
                  steps.                                                
                       
 yaml-builtin-provider.adoc
 7:7    error    Use 'built-in' rather than      RedHat.TermsErrors 
                 'builtin'.                                         
                                   
 yaml-java-locations.adoc
                                              
 63:67    warning  Verify the word 'enums'. It is  RedHat.Spelling     
                   not in the American English or                      
                   Red Hat terminology spelling                        
                   dictionaries used by Vale.                          
                            
 yaml-provider-conditions.adoc
      
 32:15   warning  Verify the word 'csharp'.       RedHat.Spelling           
                  It is not in the American                                 
                  English or Red Hat terminology                            
                  spelling dictionaries used by                             
                  Vale.                                                     
 32:35   warning  Use 'Node.js' rather than       RedHat.CaseSensitiveTerms 
                  'nodejs'.                                                 
                                                  
 180:1   warning  Block titles can only be        AsciiDocDITA.BlockTitle   
                  assigned to examples, figures,                            
                  and tables in DITA.                                       
                                            


 yaml-rule-labels.adoc
 9:175  warning  Verify the word 'rulesets'.     RedHat.Spelling     
                 It is not in the American                           
                 English or Red Hat terminology                      
                 spelling dictionaries used by                       
                 Vale.                                               
 
                                       





 yaml-rulesets.adoc

 23:57   warning  Verify the word 'rulesets'.     RedHat.Spelling     
                  It is not in the American                           
                  English or Red Hat terminology                      
                  spelling dictionaries used by                       
                  Vale.                                               

I think as the Assemblies file is a symlink, it is skewing the results. As you can see when i run vale directly in the Assemblies folder, it is returning more errors.

Also, I know rulesets is a false positive, so please create a new PR to add a vale rule to the MTA file.

Thanks

Thanks for the comment. Previously, the team agreed that builtin, enums, csharp (provider name). nodejs (provider name) and , rulesets can be exempt from Vale violations. I'll create a PR as discussed here.

The create-first-yaml-rule.adoc may require a rewrite to prevent further CQA flags.

@Pkylas007 Pkylas007 requested a review from vashirova April 22, 2026 09:37
Signed-off-by: Prabha Kylasamiyer Sundara Rajan <pkylasam@pkylasam-thinkpadp16vgen1.bengluru.csb>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants