update readme to remove configuration working group

[codeboten]

With the stability of the Configuration schema being achieved, the goal of the original working group has been reached and the project completed. I would recommend future issues with the configuration specification and schema be folded into the general specification call.

[trask]

Is the plan for the opentelemetry-configuration repo maintainership to transition to the specification maintainers (i.e. @open-telemetry/technical-committee)? Or for the configuration repo to be folded into the specification repo? thanks

[jack-berg]

Is the plan for the opentelemetry-configuration repo maintainership to transition to the specification maintainers (i.e. @open-telemetry/technical-committee)?

I'm not sure. I think of the opentelemetry-configuration repo as an extension of the spec, like opentelemetry-proto, semantic-conventions, opamp-spec. The one thing that's a bit odd is that the different related bits ultimately have different maintainer groups:

• API, SDK, high level data model description and yaml representation live in the spec, maintained by technical-commitee
• The data model schema lives in opentelemetry-configuration, maintained by configuration-maintainers

By coincidence, most of the configuration-approvers and all of configuration-maintainers are already spec-sponsors.

Going forward, I'd like to see the spec contribution process updated to be "declarative configuration first", where additions to the SDK spec need to be accompanied by proposals on corresponding proposals for schema changes to opentelemetry-configuration. This will help ensure that features are evaluated holistically, since the config plays a key part of the UX. In this future, config work really is spec work.

Do we need to fix the maintenance responsibility mismatch? Or is maintaining the config schema a different enough job to warrant a different group, and its good enough that configuration-maintainers has strong overlap with the spec sponsors?

Or for the configuration repo to be folded into the specification repo?

I don't think so. Historically, we've peeled pieces out of the spec rather than rolling them in.

[trask]

can we get clarification from the Specification SIG maintainers how they'd like to move forward with this?

In particular do they want to have multiple sets of maintainers in the SIG, or do they want to have a single set of maintainers? (there are examples of both, e.g. the Java SIG has different sets of maintainers for different repos, while the spec SIG currently has a single set of maintainers for its current 2 repos)

my only goal here is to avoid having a repo without an active SIG and an active set of maintainers.

[jack-berg]

can we get clarification from the Specification SIG maintainers how they'd like to move forward with this?

My inclination is to keep configuration-maintainers separate from the TC maintainers of the spec, despite the fact that the schema in opentelemetry-configuration is actually of the spec. If it becomes a problem we can address it then.

@open-telemetry/technical-committee WDYT?

In particular do they want to have multiple sets of maintainers in the SIG, or do they want to have a single set of maintainers? (there are examples of both, e.g. the Java SIG has different sets of maintainers for different repos, while the spec SIG currently has a single set of maintainers for its current 2 repos)

I'd argue the spec is comprised of opentelemetry-specification, semantic-conventions, opentelemetry-proto, opentelemetry-configuration, and opamp-spec. I.e. not just 2 repos.

[trask]

I'd argue the spec is comprised of opentelemetry-specification, semantic-conventions, opentelemetry-proto, opentelemetry-configuration, and opamp-spec. I.e. not just 2 repos.

The difference from my perspective is that Semantic Convention and OpAmp repos each have their own (active) SIG / meeting / slack.

Here we're proposing to fold the Configuration SIG (back) into the Specification SIG / meeting / slack(?).

My inclination is to keep configuration-maintainers separate from the TC maintainers of the spec, despite the fact that the schema in opentelemetry-configuration is actually of the spec. If it becomes a problem we can address it then.

Makes sense, I can go ahead and merge this, can you add as an FYI in next week's Specification SIG meeting?