Proposed escalation policy

Dear @Jon Ericson
It will not work, I'm afraid.

No process without obligations/SLA would work. OTC meetings had an evaluation of the issues as a part of the regular agenda. This process doesn't imply any obligations.

@Dmitry Belyavsky But the TAC does not replace OTC: the TAC has no decisional power by design.

When something is brought to the attention of the TAC by any member of our communities we can engage our respective communities to collect feedback, discuss it together, and then advice the Foundation on some course of action or some critical requirements. But that is it: when we wear our TAC hats our own personal expert opinions should not shadow the feedback we collected from our communities.

We should try to avoid conflating what the OTC did with what the TAC does: if some of our communities feel like there is an operational void left by dismantling the OTC, we can discuss about defining what is missing and try to get consensus bottom-up on suggesting the Foundation to establish a body that can solve that problem.

I'm with @Dmitry Belyavsky here. The process needs an obligation on someone to discuss and make a ruling. The TAC cannot do the latter but it seems reasonable for the TAC to at least have a discussion and make a recommendation. Failing that, the decision would have to go directly to the directors and it would then be made without TAC involvement.

In addition to an obligation to resolve an issue, there needs to be a time limit within which a response must be forthcoming. The response could be "we need more time" but there must be something apart from silence.

@Paul Dale what stops anyone from coming here and ask their TAC representative to bring any advice to a discussion that might result in a recommendation for the boards of directors?

I get the impression that instead Dmitry is asking for something to escalate the resolution of a PR/issue by the decision of the TAC. But to me this is completely outside of the TAC purpose or capability.

Neither BAC nor TAC can make a ruling. That was one of the roles of OTC but the boards have dismantled that on purpose: so now if you want a ruling you must go directly to the boards of directors.

Currently the only ask that can be made to TAC/BAC is about advising the boards on business or technical matters based on community feedback.

At the last F-TAC meeting, Dmitry brought our attention to a PR, but the TAC couldn’t do anything about it. The only effect was that it got board members sitting on the call to notice the PR and leave reviews.

The only action item on the TAC for that whole discussion was a request from the board members to inquire with our communities if they would want the TAC to recommend an exception to eventually backport that change to 3.6 if merged to master.

Once more it is at most a recommendation, the boards will internally decide what to do with it.

A joint BAC/TAC recommendation might be explored about making available the proceedings of the decision process of the boards on BAC/TAC recommendations: that seems to align with the OpenSSL Mission and with the scope of the advisory committees.

But AFAIU what you and Dima wish for is an OTC replacement that can make ruling and adjudicate on contentious discussions on PRs/issues: that is not the TAC , but the TAC could recommend the creation of such a body (as long as it is aligned with the OpenSSL missions): I’d suggest you to draft a proposal for a recommendation so we can engage our communities to appraise consensus and collect feedback before the TAC moves through its decision process to put forward a structured recommendation.

I think if someone needed to escalate an issue, the mechanism should be via GitHub Issues as a comment. Perhaps a tag could be added requesting an escalation. It seems a bit awkward to me to have to look for information on an issue in multiple places.

@Randall Becker Thanks! That was exactly my concern when I encountered this quagmire the first time: https://openssl-communities.org/d/dpuCvbRz/post-quantum-cryptography-pqc-group-recommendations-for-tls-1-3/2

The TAC and BAC are advisory bodies, not decision-making authorities.

Their role is to observe activity within their communities, identify important or recurring needs, and bring those topics forward for discussion at the TAC/BAC level. From there, the committees may develop advice or recommendations for the appropriate Board of Directors.

It’s a common misconception that community members must route their input through a specific TAC or BAC representative. While knowing your representative can help, it’s not required. Raising issues directly within your community is enough — representatives are expected to stay engaged and spot emerging needs.

Likewise, TAC and BAC members may take topics back to their communities to gather broader opinions or validate perspectives before forming advice. The goal is a two-way flow of insight between communities and the advisory committees, without adding unnecessary process or gatekeeping.

• The TAC/BAC do not enforce or adjudicate decisions — they surface and analyze concerns so that the boards can make informed choices.
• The purpose of escalation could only be to make sure community signals are seen and discussed, not to create a new approval layer.
• Accountability for decisions ultimately rests with the respective boards, not the TAC or BAC.
• Discussions can start anywhere: GitHub, forum, or within a community... what matters is that they are visible enough for representatives to recognize and elevate them.
• The process is meant to remain lightweight and responsive, avoiding bureaucracy while ensuring that important feedback reaches the right level of consideration.

The duties previously handled by the OTC are not being transferred to either TAC or BAC. In the past, OpenSSL Project had only a small number of engineers working on the library, which made the OTC structure suitable for that time. Today, with a larger and more experienced pool of engineers from both the Corporation and the Foundation, the project has sufficient expertise to make the technical decisions that the OTC once managed.

When uncertainty arises, we can always reach out to a broader group of committers and other communities for input. The key principle is to keep decisions open, transparent, and contestable — by discussing them publicly, either on GitHub or on the Communities site, depending on where the topic best fits.

@Anton Arapov This is all fine and good -- with one caveat: If too many people are involved, it's all to easy that no one takes responsibility/thinks someone else handles -- or things simply "taper away". I'm particularly concerned about this reading statements about "lightweight processes" or "avoiding bureaucracy"... Thus I very much side with @Dmitry Belyavsky on this one: I'd phrase it (maybe too colourfully) There's got to be a place stating "The Buck Stops Here." That's the Board of Directors. The TACs don't have the technical depth of the old OTC (really, a completely different mission) for that. Conceptually the proposal by @Jon Ericson is imo OK, if one would augment it with clear "Buck handling procedures" to stay in the picture, e.g. follow-up tasks for such new GH label, e.g., an assigned set of the many qualified engineers automatically taking a look at issues with such label and making an equally qualified recommendation (response to the issue/PR labelled) within a well-defined time period, thus removing the label. So, maybe call the label "Hold: Engineering decision needed". If the decision is not accepted, another label "Hold: Escalation" could be applied (that might mean community involvement, more discussions, possibly votes, but ultimately would mean the Boards of Directors need to make a statement afterwards also removing the label -- for good, or maybe with a label "Hold: Not: Again: Decision made" :). In any case, there should be a (small) set of people responsible for moving an issue through this Escalation chain. Or some automation (call it AI :).