include some more changes

Signed-off-by: Danilo Patrucco <danilo.patrucco@gmail.com>

hips/hip-0019.md

@@ -11,7 +11,7 @@ status: "draft"
 This proposal introduces enhancements to the `helm lint` command, allowing the exclusion of specific files or patterns through a `.helmlintconfig.yaml` file. Additionally, a `--lint-config-file` flag will be added to specify alternative locations for the `.helmlintconfig.yaml` file. This feature is particularly useful in projects with multiple sub-charts. An environment variable `HELM_LINT_CONFIG_FILE` will also be introduced to mirror the functionality of the flag.
 
 ## Motivation
-In large Helm charts, certain files or configurations may not conform to standard linting rules but are accepted by the maintainers. The current `helm lint` process evaluates all files within a chart, often leading to irrelevant warnings or errors. An option to exclude specific files and the ability to specify config file locations would streamline the linting process.
+In large Helm charts, maintainers often encounter scenarios where certain files or configurations, while deviating from standard linting rules, are nonetheless acceptable. The current helm lint process indiscriminately evaluates all files within a chart, leading to the generation of potentially irrelevant warnings or errors. Introducing options to exclude specific files and to specify locations for config files would greatly streamline the linting process. This adjustment would especially benefit situations where imported subcharts are flagged with low-priority lint errors that maintainers would prefer to suppress.
 
 ## Rationale
 The aim of this proposal is to grant developers and integrators more control over the linting process by enabling:
@@ -51,10 +51,9 @@ Documentation for the `.helmlintconfig.yaml` file and the `--lint-config-file` f
 PR #[13257](https://github.com/helm/helm/pull/13257) created in the Helm/helm repository in gitlab 
 
 ## Open Issues
-- Developing an Effective and User-Friendly Pattern Syntax: We are considering the design of a flexible and intuitive pattern syntax for the `.helmlintconfig.yaml` file. This syntax would ideally support rule-specific configurations and exclusions, allowing users to finely control lint behaviors on a per-rule basis.
+- Developing an Effective and User-Friendly Pattern Syntax and Rule Configurations: We are considering the design of a flexible and intuitive pattern syntax for the `.helmlintconfig.yaml` file that supports rule-specific configurations and exclusions. This enables users to control lint behaviors on a per-rule basis. Additionally, introducing named lint rules, akin to those in yamllint, will provide a foundation for more sophisticated configuration features, including rule-specific settings and extensions of a "default" configuration set. This could also facilitate the introduction of features like error code suppression across the board (hypothetically, using `errorCode: H019`). This change will require a strong refactoring of the linting code to accommodate the new configuration and rule management systems.
 - In-File Annotations for Excluding Chart Sections: Exploring the possibility of in-file annotations that would let developers temporarily exclude specific sections of a chart from linting. This feature would provide granular control directly within Helm chart files.
-- Rule Naming and Configurations: Currently, Helm does not support named lint rules. Introducing named rules is a foundational step that would enable us to implement more sophisticated configuration features, such as rule-specific exclusions and settings. This would also allow users to extend or override a "default" configuration set, similar to practices seen in tools like [yamllint](https://yamllint.readthedocs.io/en/stable/configuration.html#extending-the-default-configuration). Naming rules would facilitate clearer and more maintainable configurations, laying the groundwork for future enhancements.
-- Future Enhancements and Extensibility: The proposed changes to the Helm linting system will likely require significant modifications to the existing codebase. As such, these enhancements could be implemented in phases, starting with foundational features like rule naming and extending to more complex configurations. This phased approach will help ensure stability and usability while expanding the linting capabilities of Helm.
+- Future Enhancements and Extensibility: The Open issues proposed changes to the Helm linting system will likely require significant modifications to the existing codebase, the basic design outlined in HIP-0019 won't. As such, these future enhancements could be implemented in phases, starting with foundational features like rule naming and extending to more complex configurations. This phased approach will help ensure stability and usability while expanding the linting capabilities of Helm.
 
 ## Rejected Ideas
 None at this time.