OpenTelemetry JavaScript SIG Focus Topics

[pichlermarc]

OpenTelemetry JavaScript SIG Focus Topics

Note

This issue is read-only. It serves as a way to broadcast information about focus topics.
Discussions are held on linked issues to avoid cognitive overload.

This issue is a living document that lists focus topics for the OpenTelemetry JavaScript SIG.
@open-telemetry/javascript-maintainers pick focus topics based on a these criteria:

maintainability of existing components

• We see this as the top priority. Continued maintenance of existing features comprises the
  main chunk of work for core contributors and is the limiting factor in how much value we
  can provide. By improving maintainability of existing components we free up bandwidth for
  stabilizing existing components and for adding new features, which provides additional value
  to our users.

stabilizing existing components

• existing experimental components should be re-worked if necessary and released
  as stable to enable end-users to depend on these components in production. We strive to provide
  a minimum viable stable product and expand on it later with new features as needed. When going
  through a stabilization phase, it is important to keep these future feature additions in mind.
  We need to ensure that adding these features is possible without introducing breaking changes.

end-user need for new features

• new features come with additional maintenance burden and therefore need to be carefully weighed
  against the topics above.

How you can help

help with day-to-day tasks

• Day-to-day tasks still need to be done while we work on these focus topics. Bugs are filed,
  tests break, dependencies need updating. As an Approver or Triager, you can help by appropriately labeling issues,
  creating reproducers and linking them on issues, and opening and reviewing bugfix PRs. Approvers have autonomy to
  merge these PRs. By doing these important things independently, you indirectly help the Maintainer group to archive
  these more time-intensive larger-scale priority goals.

get involved with a focus topic

• While your priority topic may not be deemed as an immediate priority for the SIG, it will eventually become one as
  we work through existing topics. PR reviews - not code contributions - are a limiting factor for the SIG.
  Approver or not: if you see a PR that is associated with an active focus topic and you review it,
  it helps move that topic along, and it will eventually free up resources for your priority topic.

Active Focus Topics

This list is intentionally limited to a small amount of focus topics. Fewer topics means less context-switching.
Less context-switching means we can deliver quicker.

When a topic is finished, @open-telemetry/javascript-maintainers re-evaluate which topics are important by going through
open issues and grouping them into focus topics that are added to the backlog. These topics are re-prioritized and a
new focus-topic is added.

Note

We strive to eventually include more contributors and end-users in the discussion. However, we ask for understanding that we have to honor our commitments to existing features before we add new ones. The maintainer group's goal is further to ensure that the project can grow in a healthy way, and that occasionally requires us to consider non-functional requirements first.

HTTP Semantic Convention Stability Migration

Tracking issue: #5646

Milestone: https://github.com/open-telemetry/opentelemetry-js/milestone/21

Reasoning

• maintainability of existing components
  • HTTP semantic conventions were declared stable in November 2023. The Semantic Conventions SIG has defined a migration plan to transition from unstable to stable semantic conventions. This plan involves dual-emitting both old and new conventions for six months, requiring two code paths to be maintained. After this period, the non-stable part will be removed, which will eventually reduce maintenance effort.
    • The six-month period begins once all core and contrib repo packages are updated to dual-emit.
    • Quick alignment of all packages is crucial to minimize the dual-maintenance period.
    • A unified approach across packages is necessary to avoid the burden on reviewers of making case-by-case decisions on safe merges, ensuring consistency and reducing potential breakages, thus improving maintainability during this period.
• stabilizing existing components
  • Packages cannot be marked as stable if they do not emit telemetry adhering to stable semantic conventions. Adjusting them to emit telemetry adhering to stable semantic conventions brings them closer to stabilization.
• end-user need for new features
  • As other language SIGs progress towards emitting telemetry adhering to stable semantic conventions, the inability of OTel JS instrumentations to emit according to these conventions creates challenges for end-users, necessitating workarounds. Updating to the latest semantic conventions also means end-users will have access to new attributes that did not exist in previous versions.

Database Semantic Convention Stability Migration

Tracking issue: #5658
Milestone: TBD

Reasoning

• maintainability of existing components
  • Database semantic conventions were declared stable in November 2023. The Semantic Conventions SIG has defined a migration plan to transition from unstable to stable semantic conventions. This plan involves dual-emitting both old and new conventions for six months, requiring two code paths to be maintained. After this period, the non-stable part will be removed, which will eventually reduce maintenance effort.
    • The six-month period begins once all core and contrib repo packages are updated to dual-emit.
    • Quick alignment of all packages is crucial to minimize the dual-maintenance period.
    • A unified approach across packages is necessary to avoid the burden on reviewers of making case-by-case decisions on safe merges, ensuring consistency and reducing potential breakages, thus improving maintainability during this period.
• stabilizing existing components
  • Packages cannot be marked as stable if they do not emit telemetry adhering to stable semantic conventions. Adjusting them to emit telemetry adhering to stable semantic conventions brings them closer to stabilization.
• end-user need for new features
  • As other language SIGs progress towards emitting telemetry adhering to stable semantic conventions, the inability of OTel JS instrumentations to emit according to these conventions creates challenges for end-users, necessitating workarounds. Updating to the latest semantic conventions also means end-users will have access to new attributes that did not exist in previous versions.

Upcoming

OTLP Exporter re-work and stabilization

OTLP Exporter re-work and stabilization

Tracking issue: #4585

Milestone: https://github.com/open-telemetry/opentelemetry-js/milestone/18

Reasoning

• maintainability of existing components
  • The OTLP exporters have grown to a state where it is very difficult to add features and fix bugs without
    introducing breaking changes. Further, a large amount of code is duplicated, and so are tests for the exporters.
    This blocks improvements in other parts of the project, as the exporters and their tests are very interwoven
    with SDK internals and break whenever we make any significant changes. Improving the maintainability of the
    exporters will free up resources to work on improvements elsewhere. It will also unblock improvements for SDK 2.0.
• stabilizing existing components
  • OTLP is the de-facto default export format defined by the OpenTelemetry Organization. We cannot reasonably call
    Traces and Metrics stable without a stable exporter in place. The maintainability concerns you can see in the previous
    section and the tracking issue linked above lists what prevents us from stabilizing the components.

How to help

• reviews - if you see a PR that is contributing to this topic, please review it
• stop feature development for these components - we are reworking these components, adding new features while we do that leads to unnecessary churn. As always, we're still happy to accept bug fixes.

Backlog

This list includes focus topics that have been identified as important, but are currently not scheduled.

Important

This list is not prioritized, it is an incomplete collection of topics that may be considered once a previous
focus topic has been completed.

• Re-working/Stabilizing the @opentelmetry/instrumentation packages
  • Tracking issue: [instrumentation] instrumentation base stabilization plan #4586
• Publish ESM packages following ESM spec
  • Tracking issue: Publish ESM packages following ESM spec #4898
• Stabilizing the Logs API/SDK
  • Milestone: https://github.com/open-telemetry/opentelemetry-js/milestone/19
• Improving OTel libraries for use Browser/Bundled use (bundler support, bundle size improvements)
  • Tracking issue: TBD
• Node.js Dynamic Plugin Loading (eliminating the need for meta-packages, enabling dynamic loading of third party instrumentations, plugins)
  • Tracking issue: TBD

Completed Topics

OpenTelemetry SDK 2.0

OpenTelemetry SDK 2.0

Tracking issue: #5148

Milestone: https://github.com/open-telemetry/opentelemetry-js/milestone/17

Reasoning

• maintainability of existing components
  • The 1.x SDK release supports Node.js versions that are out-of-date, such as Node.js v14. As more
    and more of our dependencies and devDependencies drop support for this Node.js version we amass
    more and more technical debt. It forces us to develop workarounds. Dropping support requires a breaking change.
  • Similar to the outdated Node.js versions, we also support TypeScript >4.4, which limits us in which
    tools and language features we can use. Bumping TypeScript to a later version requires us to introduce a breaking change.
  • We have identified problems with our current exports. We usually export TypeScript classes, which, in
    the context of a library means that we expose private fields as part of the public API. This makes it
    extremely difficult to innovate. We also export some types that were unintentionally exported. Removing these
    types from the public API is a breaking change, but makes it easier to make internal changes and reduces the risk
    for unintentional breaking changes.
  • We currently do not specify a minimum supported browser version this means that we have to deal with
    bugs that only occur on very old, and long-out-of-support browsers. Removing this support is a breaking change,
    but by dropping support for these old versions, we free up bandwidth to work on other things.

How to help

• reviews - if you see a PR that is contributing to this topic, please review it
• refining issues (triager, approver, maintainer) - head on over to the milestone
  • if you see issues that can be broken down into sub tasks, do so and link them appropriately
  • if something is unclear, ask clarifying questions
• code contributions - ask before picking up an issue from the milestone to avoid duplicate work.