Summary

  • The August 2026 Tools Update says thousands of GitHub issues, including about 1.1k for Datatracker, mostly lack a related-work structure and have not been assessed for effort or priority.
  • The Tools Team plans to organize the backlog as Goal -> Project -> Epic -> Task, estimate the lowest-level tasks, take an initial priority pass at Goal and Project level, and then seek community feedback through a mechanism still to be determined.
  • A public issue proves that a request was recorded. It does not prove validation, acceptance, estimation, funding, scheduling, implementation or a commitment by the IETF.
  • A public issue-to-roadmap disposition receipt should expose each safe transition and its authority while keeping private planning data, security-sensitive material and individual performance information protected.

The open issue with no public route

Datatracker issue #9204 asks for Designated Expert roles to appear on a person's Datatracker page. On the public issue page, the request looks modest. It was opened in July 2025 and, at this Article's cutoff, showed no assignee, project, milestone, relationship, branch or pull request. None of those empty fields establishes that the request was ignored. They establish only that GitHub's public issue view does not display a route from the reported need to an institutional decision.

The August Tools Update supplies the missing complexity. Before the feature can work, IANA may need an API specification. The data model has to represent different forms of Designated Expert responsibility: a person, an Area Director role, a list or a set of chairs. IANA and Datatracker data have to be reconciled. A live import then has to be established. What appears to be one interface request is therefore a project with multiple dependencies under a broader goal: an accurate and comprehensive record of the standards process, roles and personal contribution.

This example is more useful than an abstract complaint about backlog size. It shows why an issue count cannot be read as a queue length, why creation time cannot by itself determine priority, and why a public label such as “enhancement” is not an effort estimate. One issue may be a duplicate. Another may expose a security problem that should not be fully public. A third may depend on an external data contract. A fourth may be technically simple but impose a permanent operations cost. The count flattens these differences precisely when planning must recover them.

Visibility is not acceptance

The August report gives a startling but carefully bounded inventory: thousands of outstanding GitHub issues, with roughly 1.1k for Datatracker as an example. It says almost all sit as individual issues, without a structure of related work, and have not been assessed for effort or priority. It does not say every issue is valid, current, independent or desired by a broad community. It does not say the oldest issue should be implemented first. It does not say that opening an issue places the IETF under an obligation to deliver it.

Those distinctions are the constitution of a service backlog. Intake answers, “What was reported?” Triage asks, “What is it?” Estimation asks, “What would it take?” Priority asks, “Why before the alternatives?” Resource authorization asks, “Who may spend capacity or money on it?” A roadmap answers, “What state and time range has actually been communicated?” Release and closure answer what ultimately happened. Collapsing these states into “open” turns a public repository into a promise it was never designed to make.

The reverse mistake is also possible. Because an issue is not a promise, an institution may conclude that no public explanation is owed. That leaves a contributor unable to distinguish an unreviewed request from a valid but deferred task, a duplicate from an out-of-scope demand, or a strategic dependency from a forgotten record. Transparency at intake without transparency at disposition can increase frustration: it makes the request visible while leaving the allocation decision opaque.

A roadmap already failed at the join

The present planning reset did not begin with the August retreat. In December 2025, the Tools Team explained why an earlier roadmap had been withdrawn. Multi-quarter projects had been split into phases without clarity about the work in each phase. Organizational goals and detailed projects were mixed. Most important for this Article, roadmap projects were not linked to the work items held as GitHub issues across individual repositories.

The replacement used a read-only GitHub project maintained by the Tools Team. It separated goals from projects and asked the community whether the structure was useful, whether the levels made planning understandable and influenceable, and whether the proposed goals and projects were right for 2026. That was a serious attempt to expose strategic shape without opening the planning record to uncontrolled edits.

It did not settle the problem. A public Executive Director report in February said the roadmap meeting attracted relatively low community participation, though those who attended supported the approach. In March, one participant asked where to see whether a roadmap item targeted for the first quarter was on track or behind. That question is not a community verdict, but it identifies the missing state transition: a target displayed without a current progress or disposition path invites readers to infer more certainty than the record supports.

In April, roadmap work was set aside while the Tools Team concentrated on the RFC Production Center modernization. In June, the update said the roadmap still had not been updated and that planning and community engagement would be discussed at the retreat. Those pauses are not proof of abandonment. They demonstrate the very allocation pressure a roadmap must explain: urgent, multi-year operational work can consume the same capacity needed to improve the planning system.

Three phases, three different acts

The August plan should not be described as one act called “prioritization.” Phase 1 is classification. The team intends to review outstanding issues and arrange them as Goal -> Project -> Epic -> Task. Most of that work occurs in a Tools Team ZenHub instance that is not visible to the community, with an intention to link the result back to public repositories. Urgent matters may be identified during this work, but most issues are not yet estimated or prioritized. The update also says three weeks may be insufficient and another sprint may be required.

Phase 2 is estimation. The developer most likely to implement a lowest-level task supplies the initial level-of-effort estimate. The team meets to calibrate estimates with estimation poker. Higher-level effort is then calculated from the tasks, and a task that exceeds the largest permitted estimate is split. This is a planning technique, not a performance score and not a commitment date.

Phase 3 is priority formation and engagement. Priority is generally to be set at Goal and Project level. The Tools Team makes a first pass, creating a starting point rather than claiming a community mandate. The result is then opened for community feedback through a mechanism that was still undetermined on 6 August. Feedback may expose a missing dependency, a misread user need, a continuity risk or an unjustified preference. It does not automatically settle the trade-off.

Keeping the three acts separate protects everyone. A classified issue has not necessarily been accepted. An estimate does not reserve capacity. A high-level priority does not prove that every child task is ready. A feedback comment does not become a vote. A roadmap target does not become a standards requirement. And a Tools Team planning judgment remains administrative work, not IETF technical consensus.

Community evidence without a popularity contest

The IETF has strong reasons to invite community input. Its tools mediate document submission, working-group state, reviews, ballots, meetings, mail, publication and historical records. A poor interface or missing workflow can impose costs across the standards process. The Tools Architecture and Strategy Team was explicitly expected to consult widely, while leaving implementation and operation of individual tools with the Tools Team.

But an open comment channel does not create a representative electorate. People who have already worked around a defect may be less likely to comment than people encountering it today. Chairs and authors may see different costs. Maintenance, security and migrations attract fewer public reactions than a visible feature, even when failure would cause more damage. February's low participation cannot be converted into opposition or indifference; there is no complete denominator against which to measure it.

The feedback mechanism should therefore ask for evidence classes, not tally enthusiasm. A response can identify the affected workflow, frequency, severity, people or roles exposed, existing workaround, continuity consequence, deadline source and evidence link. The Tools Team can then publish a bounded disposition: accepted and reclassified; accepted but deferred; already covered by another project; rejected as out of scope; protected because of security; or unchanged, with a reason. This preserves influence without pretending that reactions, message volume or meeting attendance allocate engineering capacity.

The issue-to-roadmap disposition receipt

The public layer should start with the source issue and creation date. It should add the latest triage date and a responsible team role; a validity state such as needs clarification, confirmed, duplicate, superseded, out of scope or security-sensitive; and the safe links into public Goal, Project, Epic and Task records. Dependencies and blocker classes should be visible where disclosure does not create security or contractual harm.

Estimation needs a date and confidence. A band is often more honest than a precise number, especially before dependencies are resolved. “Not yet estimated” is a legitimate state and should not be replaced by a blank that readers interpret at will. Priority likewise needs a class, date, current authority holder and bounded rationale—or the explicit state “not yet prioritized.”

Community engagement needs its own fields: the feedback window and channel, the kinds of evidence requested, what denominator is and is not known, and a disposition showing which submissions changed classification or priority. The record need not quote every message or expose personal information. It must make the institutional response attributable.

Finally, the receipt should show roadmap state and a target range only when those have actually been authorized. Later links can identify implementation, release, closure, supersession and correction. Each correction adds a state rather than silently rewriting history. The result should be generated from the planning system, not maintained as a second hand-edited backlog destined to drift.

What must stay private

Public accountability does not require a public copy of the Tools Team's ZenHub workspace. Private notes may contain preliminary judgments, contractor information, security-sensitive issues, exploit paths, personal data or individual workload detail. Publishing attributed estimates as if they were employee scorecards would distort estimation and invite defensive padding. Publishing every rejected alternative would make ordinary planning performative.

The useful boundary is a public projection of institutional state. It names the classification, evidence class, current authority and disposition without exposing protected content. A security-sensitive issue can reveal that its public twin is restricted, who owns the next safe state and when a public update is expected, without publishing the vulnerability. A contractor dependency can be described as a procurement or external-service blocker without disclosing confidential terms.

This boundary also prevents the proposed receipt from becoming a second authority. The Tools Team retains the first priority pass described in the August plan. The Executive Director and IETF LLC structure retain their administrative, contracting and resource responsibilities. The community retains the ability to supply evidence and challenge reasons. Technical standards authority remains where the IETF process puts it. The receipt records those acts; it does not redistribute them by database design.

Sources

  1. August Tools Update
  2. Introducing a new roadmap framework
  3. Public Executive Director Report, 18 February 2026
  4. March tools update discussion
  5. IETF tools update 2026-04
  6. June tools update
  7. The Tools Team
  8. Tools Architecture and Strategy Team
  9. RFC 8711
  10. IETF Administrative Strategic Plan 2020
  11. Datatracker issue #9204