Multiple issues could be closed

[ocelotl]

I asked Claude to review all open issues, here it is what it reported. I'll check them one by one and will comment in every issue that I agree can be closed.

@open-telemetry/specs-maintainers please assign this issue to me.

[ocelotl]

Housekeeping: candidate issues for closure

While triaging the backlog I read through all 618 open issues and identified 133 that look ready to close. Each one below was checked against its full thread (body, all comments, labels, cross-referenced PRs) and against the current spec, and every proposed closure was then independently re-verified. Candidates that didn't hold up on re-verification were dropped.

This is a proposal for maintainer review, not a request to close anything blindly — please push back on any that are still actionable. Where a reason is moved to another repo, the intent is to transfer/re-file it in the correct repo rather than lose it.

Breakdown

Reason	Count
Resolved	34
Duplicate	1
Obsolete	25
Moved to another repo	38
Answered question	10
Stale	25
Total	133

Confidence: 56 high, 77 medium. The medium ones especially deserve a second look before closing.

[ocelotl]

All flagged issues grouped by category. GitHub color-codes the references, so open issues render one color and closed issues another — a quick visual of overall progress.

Answered question (10)

• Composable sampler naming conventions #4640
• behavior of context and trace in the presence of timers #3144
• Add ability to *reset* metrics to 0 in UpDownCounter #3037
• Why do we need process.context_switches metric? #2929
• How to create an "up" metric semantic-conventions#3898
• Naming Convention for Custom Attributes #2564
• Are processes allowed to report their process.cpu.time? #2439
• There are four kind of datapoint(gauge,sum,histogram,exponential histogram). What kind of is count-distinct? #2396
• Officially supported open source logs exporter aside from OTLP #2206
• the example in define Tracing.Api.TracerProvider exists Ambiguity. #1303

Duplicate (1)

• Improve contributing guide to clarify the workflow on issues #1948

Moved to another repo (38)

• Analyze the overlap between OpenTelemetry resource attributes and ECS attributes #3409
• Schema translation for http.flavor -> net.app.protocol.name/version #3162
• In hardware memory metrics, add attribute for the type of error (correctable, non-correctable...) #3142
• Improve guidelines for sensor_location attribute in hardware section #3139
• Semantic guidelines for the hw.type attribute in hardware metrics #3138
• Add SemanticAttribute messaging.rabbitmq.vhost #3034
• Standardise SNS attributes collection #3008
• Question on process.memory.virtual metric #2928
• Proposal: New SpanAttribute HTTP_EXPECTED_RESPONSE_TIME #2921
• Add database resource specification #2916
• add convention attribute for k8s cluster version #2913
• Webengine semantic convention contradicts itself #2910
• Add support for redis list lengths #2877
• Remove process.runtime semconv for browser resource #2806
• what is the difference between state and status? #2554
• Semantic conventions for language bindings API calls #2527
• Non-namespaced attributes for metrics #2513
• Attribute Naming #2487
• Semantic Convention for redundant connections #2470
• Semantic convention for Multicast and Broadcast IP is missing #2460
• semconv: add rpc.type and rpc.status #2419
• Proposing a semconv for IsDeleted attribute to k8s resources #2394
• Completeness of semantic convention for k8s resources #2283
• Clarify faas.executions description in FaaS Metrics Spec #2209
• Details for peer service on spans of kind SERVER #2134
• Write "How to add a new set of semantic conventions (a new concept)" #1991
• Write "How to add a new attribute to semantic conventions" #1990
• host.id and device.id are confusingly similar to each other #1768
• Discuss changing naming conventions for faas metrics #1737
• Representing resources in Real User Monitoring #1680
• Amend cassandra.cql.table to exclude keyspace #1500
• Clarify (un)escaped form for trace attribute http.url #1329
• Semantic convention around retry attempts? #1306
• Metrics Start-time resource semantic convention #1273
• Add category attribute to spans #1161
• Update http metric spec #897
• Adding semantic conventions for setting attributes to record retry behavior #729
• enduser.role semantic attribute is vague #486

Obsolete (25)

• Missing Environment Variable for Cardinality Limit #4586
• profiles/follow up: location references in sample #4307
• Environment variables to provide K8s container and pod name #4140
• Update docfx check once 3.0.0 is released #2438
• Should the in-memory exporter be a pull metric exporter? #2425 reviewed by @alanwest, this one is a valid issue
• Improve wording on MetricReader/SDK #2424
• RPC Semantic Conventions diverge from HTTP Semantic conventions for similar metrics #2214
• Properties of sampler can not be transformed to YAML #2181
• Applicability of http semantic conventions #2171
• Define best practices for no-code configuration #1773
• Clarify Jaegar Envrionment Variables. #1505
• Support additional validation of keys and values #1490
• CONTRIBUTING.md should mention Go #1394
• Security requirements for GA #1333
• CI/CD Pipeline for GA #1183
• Instrumentation and Plugin Organization for GA #1182
• Example Code for GA #1181
• Integration Testing for GA #1179
• Release, Versioning, & Backlog Process for GA #1178
• Documentation for GA #1176
• OpenTracing Compatibility for GA #1174
• How to map StatusCode to Jaeger #1157
• Add StatusSource from OTEP 136 #1092
• Update Metrics Semantic Conventions README #1084
• Extract common protocol translation rules into single document #806

Resolved (34)

• Amend description of Composite/Composable samplers #5160
• [prometheus] Stabilize OTLP->Prometheus: Histograms #4921
• Update CONTRIBUTING.md regarding removed auto-assign workflow #3968
• Fork specification specific build-tools (protoc) into a specification-tools repository #3899 reviewed by @jsuereth, this one is a valid issue
• Need more resource types in k8s | service, pvc, volume support #3328
• Improve description of hardware network adapter #3133
• docs(google): access blocked #3030
• Is a MetricReader supposed to implement ForceFlush? #2924
• Metric names in specification don't match hostmetrics's paging scraper #2727
• [Common] Spec inconsistency with proto definition of Attributes #2581
• SetStatus to Unset spec unclear #2367
• Clarify the API on behavior of asynchronous callback reentrancy, timeout, duplicate observations #2350
• Clarify on if schemaUrl is part of InstrumentationLibrary #2133
• Kubernetes attributes don't cover labels and services #2043
• HTTP server span naming inconsistent across languages #1954
• How to map the Meter name in non-OTLP exporters? #1906
• Complete the TraceIdRatio specification #1826
• Add a identifier for agent/distro #1786
• SpanContext and Link spec/proto are not clear #1667
• Add semantic convention for describing network connectivity conditions #1647
• Remove suggestion of performing a DNS lookup for net.peer.name #1583
• Clarify OpenTracing Span's Baggage storage location #1553
• Interface stability for implementers and new methods in the spec #1457
• How to discard over limited data on span #1440
• Missing environment variables #1389
• Semantic conventions should use int or double, not number #1274
• Consider making faas.id a span attribute instead of a resource attribute #1261
• Tracking OTel Spec Issues for GA #1118
• Have Baggage section written with the immutable Baggage object. #1094
• Clarify why would analysis tools generate errors? #1068
• Revisit HTTPPropagator/Fields section #712
• Configuring a sampler from an environment variable #679
• Formalize the translation of OpenTracing references to span parent and links #562
• Properly define CorrelationContext as an optional interface. #482

Stale (25)

• Allow to disable injection or extraction on propagators #3153
• Clarification needed: handling repeated async counter observations #3109
• Informational headers in otlp exporter in every request #3063
• Project Tracking: FAAS SIG (Lambdas) #3042
• Structured Stacktrace in Span Attributes/Logs #2839
• Identify if trace data is being propagated to the current process and infer its format #2411
• I have a track file for android Context.data xml file I want to extract to see my trace flow #2138
• Return type of callback functions for Asynchronous Instruments #1732
• Allow supplying a callback for adding new attributes when spans start #1724
• Unclear merge order for Resources from environment variable #1620
• Improve Resource.Merge for the empty values case #1357
• Consistent formatting of terms #1271
• Split the data model into its own document? #1253
• Performance Testing for GA #1180
• Provide a way for knowing when a Context is made current #1163
• OpenTelemetry Implementation Compatibility #1153
• Need to document how changes to spec can be done after 1.0 #1119
• Contrib directory for vendor specific specifications #1110
• Consider distinguishing between API and SDK in the spec compliance matrix #1088
• Semantic conventions for Dependency Injection #813
• Add w3c TraceContext propagation integration tests #749
• Clarify in VENDORS what code is allowed in OTel #743
• Define conventions for Registry types. #595
• Update Setter used for Injection #444
• Re-introduce the concept of Entry and EntryKey #442

[lmolkova]

I think a simple deterministic approach of closing issues that don't have activity over X months and relying on motivated human applying judgement to reopen them would be a better solution than self-evaluating AI.

While probably most of issues are in the right buckets, I can see some of them not being where they should be (e.g. open-telemetry/semantic-conventions#3898 is not answered, but should be in semconv or #1161 is a spec / proto issue).

To separate one from another we need people with context to spend some time and apply their judgement. AI does not solve this yet.

[pellared]

I processed "Answered question (10)" and "Duplicate (1)".

[ocelotl]

I think a simple deterministic approach of closing issues that don't have activity over X months and relying on motivated human applying judgement to reopen them would be a better solution than self-evaluating AI.

While probably most of issues are in the right buckets, I can see some of them not being where they should be (e.g. open-telemetry/semantic-conventions#3898 is not answered, but should be in semconv or #1161 is a spec / proto issue).

To separate one from another we need people with context to spend some time and apply their judgement. AI does not solve this yet.

Yes, AI can be wrong, that's why I added a comment to each one of these issues explaining what Claude had found out for a human being to evaluate. I'm not advocating leaving AI to make the final decision, just to assist humans who will.

This approach seems promising, 30 issues have been closed in less than 24 hours ✌️

[lmolkova]

This approach seems promising, 30 issues have been closed in less than 24 hours ✌️

by closing issues that don't have activity over X months we would close a few hundreds in an hour including writing automation that would do it for us going forward

[ocelotl]

This approach seems promising, 30 issues have been closed in less than 24 hours ✌️

by closing issues that don't have activity over X months we would close a few hundreds in an hour including writing automation that would do it for us going forward

To separate one from another we need people with context to spend some time and apply their judgement. AI does not solve this yet.

Having an automation that closes an issue after X months have passed is not using human judgement.

The ~30 issues I mentioned were closed by a human.

What is being done here is using AI to assist a human in making the decision of closing an issue or not, and that is actually using human judgement.

Just to be clear, I am not trying to make an AI make the final decision, I am trying to use AI to help us humans make the decision on closing an issue or not.