Clarify titles and descriptions of various packages of same technology#19526
Clarify titles and descriptions of various packages of same technology#19526MichelLosier wants to merge 4 commits into
Conversation
✅ Elastic Docs Style Checker (Vale)No issues found on modified lines! The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale. |
🚀 Benchmarks reportTo see the full report comment with |
jmikell821
left a comment
There was a problem hiding this comment.
Reviewed all the title/description updates. Everything from my end LGTM!
|
Pinging @elastic/sec-windows-platform (Team:Security-Windows Platform) |
|
Pinging @elastic/ecosystem (Team:Ecosystem) |
There was a problem hiding this comment.
READMES and any other doc that is referencing the title and description should be align with changes. i think the best will be asking claude to go through all the updated integrations and make sure _dev/build/docs/README.md is aligned with the changes and then regenerate docs/README.md with elastic-package build command (this one is generated from the template one)
i was trying to look if the title or description was referenced as a template variable but it appears they are hardcoded.... also keep in mind i see some packages not having the template (_dev/build/docs) but directly the docs/README.md
A quick way to check this is seen correctly is by using the elastic-package tool. When running elastic-package stack up within the root of the integrations repository, the local registry used on the stack includes the local builds of the packages... so for instance, you could elastic-package foearch -- build (this builds all the packages) and then run the stack. When you go to the local kibana you should be able to see the tiles renamed and the package documentation updated. let me know if you have any doubt
EDIT: also, could we wrap up a small skill/rule/X where the style on titles and descriptions are stablished so future itegrations follow the same aproach. i am thinking on referencing an AI agent to review the integration and check for this (as for example we use Vale linting for written style)
|
Thanks for the catch there @teresaromero! I've updated the Readmes in 62e33b7 |
| @@ -1,7 +1,7 @@ | |||
| # IIS OpenTelemetry Input Package | |||
There was a problem hiding this comment.
If we are removing the name Input Package here.
Just writing IIS (OpenTelemtry) can mean multiple thing.
Input package
Content Package (Assets)
Integration PAckage (Composable one).
Isn't this ambiguous ?
There was a problem hiding this comment.
I agree when the Composable package one arrives we'll need again look at how we are providing a choice to the user. In this discussion with the team, it seems we need a git issue to capture how or if it all we want to show input packages that are already composed into a larger integration.
With IIS right now a user has the choice of
IISIIS OpenTelemetry Input PackageIIS OpenTelemetry assets
The immediate goal here is to simplify this to a choice of (I want to monitor X with ECS or OTEL) absent a composable package choice:
IISIIS (OpenTelemetry)
With hidden by default filtering:
IIS OpenTelemetry assets
When we create the composable package, I think we'll want to keep the choice simple still with:
IISIIS (OpenTelemetry)(composable package)
Again still hidden by default filtering:
IIS OpenTelemetry assets
At which point the input package I could see getting a different name again as the composable integration would be the preferred package for OTEL, but also making sure the input package is not an immediate or visible option to complicate that choice.
There was a problem hiding this comment.
Created a follow up issue: https://github.com/elastic/ingest-dev/issues/8480
|
|
||
| ## Overview | ||
| The IIS OpenTelemetry Input Package for Elastic enables collection of telemetry data from Internet Information Services (IIS) web servers through OpenTelemetry protocols using the [iisreceiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/iisreceiver#iis-receiver). | ||
| This integration enables collection of telemetry data from Internet Information Services (IIS) web servers through OpenTelemetry protocols using the [iisreceiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/iisreceiver#iis-receiver). |
There was a problem hiding this comment.
Is it right to refer to this as integration ?
This is an input package. Integration would be the composable packages that we plan to develop in furture that actually combines the configuration (input packs) and the asstes (contet packs).
There was a problem hiding this comment.
I think viewing these in the context of the integrations experience, there is a broader use of this term aside from our distinction of package types. I think though it is fine in the Readme here to get into the specifics and use "This input package" or just the title The IIS (OpenTelemetry) package as a convention.
|
@MichelLosier : Also what is the overall plan here fro changing the titles and descriptions ? |
|
@ishleenk17 The idea here is to have the title and descriptions communicate what the package does and not bother the user with the underlying implementation detail of it being an Separately content packages wont be shown by default anymore (https://github.com/elastic/ingest-dev/issues/8097), and their naming will be unchanged. Issue related to grouping: https://github.com/elastic/ingest-dev/issues/8082 This is a for-now work as we introduce composables and grouping |
Ok, sure! |
|
✅ All changelog entries have the correct PR link. |
💚 Build Succeeded
History
|
Proposed commit message
Updates the titles and descriptions of various packages that observe the same technology to clarify their distinction
Checklist
changelog.ymlfile.Author's Checklist
How to test this PR locally
Related issues
Screenshots