mark as ready for prod + enhance wording

Author: SylvainJuge

jmx-scraper/README.md

@@ -4,8 +4,7 @@ This utility provides a way to query JMX metrics and export them to an OTLP endp
 The JMX MBeans and their metric mappings are defined in YAML and reuse implementation from
 [jmx-metrics instrumentation](https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/jmx-metrics).
 
-This is currently a work-in-progress component not ready to be used in production.
-The end goal is to provide an alternative to the [JMX Gatherer](../jmx-metrics/README.md) utility.
+This is an alternative to the [JMX Gatherer](../jmx-metrics/README.md) utility.
 
 ## Usage
 
@@ -154,22 +153,22 @@ Like with the JMX Gatherer, the selection of provided metrics to use is still do
 However, there is now two distinct sets of metrics to select from using the `otel.jmx.target.source` configuration option:
 
 - `legacy`: [metrics definitions](./src/main/resources) equivalent to JMX Gatherer definitions to help transition and preserve compatibility
-- `instrumentation`: [metrics definitions inherited from instrumentation](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/jmx-metrics/library/src/main/resources/jmx/rules/), which is now used as a reference for JMX metrics.
+- `instrumentation`: [metrics definitions inherited from instrumentation](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/jmx-metrics/library/src/main/resources/jmx/rules/), which is now used as a reference for JMX metrics, those also aim to provide better alignment with [metrics semantic conventions](https://opentelemetry.io/docs/specs/semconv/general/metrics/).
 
 In both cases, the metrics definitions themselves are embedded in the JMX Scraper binary, thus they
 will only change if the release version of the JMX Scraper binary changes.
 
 By default, `otel.jmx.target.source` is `auto`, which means for each value of `otel.jmx.target.system`:
 
-- metrics definitions from instrumentation will be used by default, if available
-- legacy metrics definitions equivalent to JMX Gatherer will be used as fallback
-- whenever new metrics definitions are being added or modified in instrumentation, those newer definitions will be used
+- Metrics definitions from instrumentation will be used by default, if available.
+- Legacy metrics definitions equivalent to JMX Gatherer will be used as fallback.
+- Whenever new metrics definitions are being added or modified in instrumentation, those newer definitions will be used.
 
-There are multiple strategies depending on the ability or willingness to embrace change in metrics definitions:
+There are multiple possible strategies depending on the ability or willingness to embrace change in metrics definitions:
 
 - To preserve maximum compatibility, using `legacy` is the recommended option, however it means to not benefit from future updates and contributions.
-- To only get the most recent definitions, using `instrumentation` ensures that none of the legacy definitions is used, only the "reference" from instrumentation, which could still evolve over time.
-- To embrace newer definitions whenever they become available, using `auto` is the recommended option, however it means the metrics produced could change when updating the version of JMX Scraper.
+- To only get the most recent definitions, using `instrumentation` ensures that none of the legacy definitions is used, only the reference from instrumentation, which could still evolve over time.
+- To embrace reference definitions whenever they become available, using `auto` is the recommended option, however it means the metrics produced could change when updating the version of JMX Scraper.
 - To handle more complex migration strategies or for tight control of metrics definitions, using copies of the YAML metrics definitions and providing them explicitly with `otel.jmx.config` is the recommended option.
 
 ## Component owners