Project proposal: Registry Data Quality Improvements #2246
Conversation
Signed-off-by: svrnm <neumanns@cisco.com>
Signed-off-by: svrnm <neumanns@cisco.com>
|
I was pointed at this by @CodeBlanch. For areas like opentelemetry-dotnet-contrib, it's unclear once you start delving into the component tree as to what the supported state of the component is, who the owners are and policies for updates etc. If a lot of that data is going to be schematized into the component yaml - then can we also have a component that can be included in the readme to return the data in a common format, like a badge? Maybe this also acts as hyperlink into the registry page for that component? |
This is not unique to .NET contrib, Collector SIG started to address this with mdatagen, that's why I called it out as a starting point.
That would be great, yes!
Yes:-)
That's part of the automation I was thinking about. We have a scrapper that is working on data from README.md and some other heuristics, which is far from optional. Having a standardized YAML + schema across the project (and ecosystem), is what this project is about! |
|
The parent issue is Collector related, but other OTel projects that produce metadata (such as language SDKs) might have different schemas or needs. That complicates things a bit. Would working on a unified metadata schema help here? Context: We pull in upstream metadata into Splunk docs, or produce it downstream, and it's challenging. |
That's what this project is about (80%, the rest is tooling&automation) |
| 2. After a package has been added to the registry, it is a manual process to verify if the package is still available and | ||
| if the meta-data is still correct. | ||
| 2. Packages lack a lot of information, and the information available is sometimes of bad quality. Metadata that might be available | ||
| for packages is not in a human readable format, or in the case of the collector (`mdatagen`-data) not consumed by the registry. |
There was a problem hiding this comment.
Is there a technical reason why it is not consumed? Or is it just "we have not implemented this"?
There was a problem hiding this comment.
It's a mix of "we have not implemented this" and let's make sure that what we consume is in an agreed format (hence this project proposal)
| and how useable is that data. If we address those issues end users will see the registry as a valuable place and will use | ||
| it to find the building blocks they need, and by reaching that state, we can use the registry to accomplish other goals, like | ||
|
|
||
| - making end users aware of non-otel-community created components they can use. Combined with a system to label "good quality" |
There was a problem hiding this comment.
I think this is another whole project of its own 😄
There was a problem hiding this comment.
Agreed, this project would be the foundation for such another project
Co-authored-by: Pablo Baeyens <pbaeyens31+github@gmail.com>
This has been discussed at multiple places, I was trying to write this down in different shapes and forms before, but @mx-psi's issue (open-telemetry/opentelemetry.io#4921) gave me the urgently needed last kick to create and publish this.
Note that this should not be a blocker for the mentioned issue (io4921), since it is related to the collector1.0 release.