TLC Meeting - July 2, 2026

Meetings are happening on the #selenium-tlc channel on Selenium Slack. To add items to the agenda for the next meeting, please see our public Rolling Agenda

The next meeting will be Thursday, July 9 at 0700 Pacific / 1000 Eastern / 1500 UK / 1930 India.

Participation

Agenda


Meeting Summary

The TLC reviewed the Selenium 5 charter, Selenium Manager release status, ADR process updates, and BiDi implementation boundaries. The meeting also covered manual Java BiDi PRs, documentation planning, and npm trusted publishing work needed before the next Selenium release.

Decisions

  • The Selenium 5 release charter should remove classic fallback as a required release milestone.
  • The group agreed in principle that Selenium 5 should not ship with Selenium Manager still marked as beta; the exact release and compatibility details remain part of the Selenium Manager released API ADR discussion.
  • The ADR workflow update for PR and issue templates is acceptable, including tracking implementation status in issues instead of ADR text.
  • Low-level or generated BiDi APIs should not be exposed directly from the driver object. Language bindings should mark internal code according to each language’s conventions while keeping high-level APIs separate from lower-level escape hatches.

Discussion Notes

Selenium 5 release charter

diemol reviewed whether SeleniumHQ/selenium#17717 was ready to merge. AutomatedTester had already approved the PR before the meeting, and no new blocking concerns had been raised. The group confirmed that classic fallback should be removed from the required release scope, leaving four main release buckets.

The group also clarified that removing classic fallback from the Selenium 5 scope does not prevent future BiDi-backed implementations by consensus. It only means that fallback behavior is not a requirement for the Selenium 5 release.

Selenium Manager release status

titusfortner shared that SeleniumHQ/selenium#17741 had been opened to define what it means for Selenium Manager to be released independently from the language bindings. The discussion covered independent versioning, default behavior, telemetry, and compatibility expectations.

p0deje raised concern that independent versioning and release scheduling could add substantial work to the Selenium 5 scope. The group aligned on the narrower principle that Selenium 5 should not continue to label Selenium Manager as beta, while the ADR will define which implementation details are required for the release and which can continue afterward.

ADR process and tracking

titusfortner explained SeleniumHQ/selenium#17697, which adds templates and moves implementation tracking into GitHub issues rather than encoding status directly in ADR documents.

The group agreed this was a better separation of the decision record from implementation progress. It also keeps PR numbers as the primary ADR tracking identifiers instead of a separate incremental numbering system.

BiDi implementation boundary

titusfortner framed SeleniumHQ/selenium#17670 as the ADR that needs to define the boundary between supported user-facing APIs and generated or low-level BiDi code. Generated code may need to remain publicly accessible while not being covered by the normal deprecation policy, because it is driven by browser specifications and generated artifacts.

The group preferred a principle-based ADR rather than binding-specific implementation rules. The shared direction is that low-level BiDi executables should not appear as methods directly under driver. Instead, users who need lower-level access should compose the relevant class with the driver, and each binding should mark that code as internal using local language conventions.

Manual Java BiDi implementation PRs and CDDL generation

diemol asked whether manual Java BiDi implementation PRs such as SeleniumHQ/selenium#16336 were still needed now that the project is moving toward CDDL-based generation. pujagani confirmed that the Java CDDL generator work is underway and that manual changes should become unnecessary once that work lands.

The group discussed leaving comments on existing manual PRs so contributors understand the direction and avoid redundant work. pujagani also planned to notify the TLC channel when the generator code is available.

Documentation and website maintenance

diemol said he would bring a documentation and website maintenance proposal to the next meeting. The proposal is expected to focus on a small scope of work and possible use of Open Collective rather than depending on specific organizations.

Selenium release and npm trusted publishing

The meeting ended with a release status question. diemol said release work was in progress, but npm trusted publishing requires revisiting the Node version used for the npm publishing path.

titusfortner noted that the Bazel release process does not rely on the system Node setup in the way initially assumed, and that Selenium’s policy currently uses the oldest supported Node version. Because trusted publishing requires a more recent Node version, diemol agreed to investigate whether a GitHub Actions-based setup could be used for that publishing path.

Action Items

  • titusfortner will update the Selenium 5 release charter PR to remove classic fallback from the release scope.
  • titusfortner will revise the BiDi implementation boundary ADR to clarify internal code marking and the driver API boundary.
  • titusfortner will review the related open BiDi ADRs and check whether one should be closed in favor of the others.
  • pujagani will help comment on manual Java BiDi implementation PRs as needed and notify the TLC channel when the CDDL generator code is available.
  • pujagani and titusfortner will follow up offline on CDDL event generation questions.
  • diemol will draft a small-scope documentation and website maintenance proposal for a future meeting.
  • diemol will investigate the Node and GitHub Actions approach for npm trusted publishing.