Consider pushing spec changes to SIGs as issues in repos

[tigrannajaryan]

We got the following feedback in the last end user working group (which was attended by SIG maintainers):

Would be nice if spec changes were somehow pushed out to SIGs. Tigran recently notified each SIG about instrumentation spec changes by creating an issue on each SIG’s repo - this was incredibly helpful!

One possibility is to automate creation of issues in language repos for each new CHANGELOG entry (either when the PR with the CHANGELOG is merged or when a spec release is made). To make this automatable we may need to first automate CHANGELOG.md creation from structured data (e.g. using the chloggen tool that Collector uses). We have an open issue for this: #655

Before we go ahead with this I would like to check with maintainers to see if this is desirable by (most?) maintainers. There is a danger that if implemented poorly we may spam the repos by too many issues. We will probably need to have some sort of annotation in changelog entries to indicate if it needs to create issues for language repos.

[tigrannajaryan]

@open-telemetry/dotnet-maintainers
@open-telemetry/php-maintainers
@open-telemetry/python-maintainers
@open-telemetry/javascript-maintainers
@open-telemetry/go-maintainers
@open-telemetry/cpp-maintainers
@open-telemetry/rust-maintainers
@open-telemetry/ruby-maintainers
@open-telemetry/swift-mainteiners
@open-telemetry/java-maintainers
@open-telemetry/erlang-maintainers
What do you think about this proposal? Please comment or vote up/down.
(Apologies for pinging all maintainers at once, but I think this should be your decision).

[dyladan]

Strongly supportive of this, I just want to make sure we don't end up creating a large number of issues that become ignored because there are too many of them. JS for example hasn't started work on logs so issues created around logs spec changes would be unhelpful and distracting at this point.

I would suggest we create entries on release and only for those changes which affect stable signals, or maybe each SIG should subscribe to the signals/components they care about.

[tigrannajaryan]

The number of the upvotes speaks for itself. :-) I am going to unassign this from @jmacd and mark as "help wanted".

[bryannaegele]

To Daniel's comment, I think this could be largely alleviated by only pushing out issues once a release is cut, which I assume was the plan.

[tigrannajaryan]

We can make it opt-in per SIG per signal or per spec area, so that SIGs that don't actively work on a particular area don't get spammed.