New TSC chair

[dstebila]

This March will mark 2 years since the OQS TSC was stood up as part of the transition to the LF/PQCA. As discussed at the January TSC meeting, I would like to pass the role of TSC chair on to someone else. This issue is to identify and eventually vote on a new TSC chair.

[ashman-p]

@dstebila, Douglas, I take this opportunity now to express my appreciation and gratitude for all you have done and how you have led this project over the years.

Secondly, I would like to nominate @bhess, Basil Hess, to be the next OQS TSC chair.

[baentsch]

Thanks to @dstebila also from my side. You and everyone at UWaterloo did a great job in moving this software forward, all the while keeping this project free from commercial domination since 2016: It was thus no coincidence, imo even a result of your approach, that by far most code in the project so far stems from university and other independent contributors. Additionally, thanks also on behalf of all end users --even unknowingly-- interested in truly free PQ OSS!!

Now, Cisco nominating IBM to chair a project under (PQCA TAC) chairmanship of AWS --besides being a foregone conclusion-- in my eyes increases the risk of this project succumbing to commercial pressure, where marketing claims trump technical realities, where marketing buttons are more relevant than active code contributions and maintenance.

On the positive side it also creates the opportunity for corporate members to feel more motivated to contribute free from the (possibly perceived) ties and aspirations of "academic" leadership, of spending more time in support of the wider OSS community, of protecting end users of quantum threats.

That said, three wishes to @bhess in my support of this nomination: Please, 1) keep the concern/risk above in the back of your mind, 2) help to make the above stated opportunity become reality and 3) do not see this as a doubt on your personal integrity: It is a fact of life that corporate employees may bend to the commercial interests of their employers. Those unfortunately often conflict with the interest of end users of FOSS, e.g., being informed about the true state of the code they are --again, often unknowingly-- using. You might want to consider a litmus test being the work time (percentage) an employee is permitted to devote to this: IMO, the task of OQS TSC chair is worthy of at least 20% of it, @bhess -- with more leading to better results: Greetings to your management chain :-).

In sum, this is to ask everyone to ensure this transition does not make the project lose its "way" of aiming to be beneficial to everyone.

[bhess]

I’d also like to thank Douglas for his leadership over the past years.

Thanks for the nomination. I truly appreciate the trust.
I need to decline the chair role.

One possible idea the TSC could consider is a co-chair structure to help distribute responsibilities, but that’s just a suggestion, I’m happy to support however I can as a member.

[dstebila]

One possible idea the TSC could consider is a co-chair structure to help distribute responsibilities, but that’s just a suggestion, I’m happy to support however I can as a member.

I think the co-chair approach would be good. It could be that the co-chairs alternately facilitate meetings, or split up the duties some other way. If two new co-chairs come forward, that's great! I'm also willing to stay on as a co-chair with someone who would like to take that up.

[baentsch]

Isn't the chair role more than one of facilitating meetings? Isn't it (or should it be) driving the project forward, actively participating in GH discussions (particularly TSC ones), externally representing the project, quite literally setting its agenda?

The dead-lock situation discussed in #216 (comment) clearly indicates these questions should be answered positively -- at least also that this is the expectation of the PQCA TAC chair, @brian-jarvis-aws. Further, people seeing the title "TSC chair" in presentations do have this expectation and the person thus gets invited based on this role, no?

Now, my primary concern with having more than one person tasked to do this "driving" is that it's all too often in such setups that no-one does, even if only relying on the other to handle things: On the road such arrangement typically leads to disaster. In the best case, co-chair arrangements lead to increased synchronization efforts. And if there's something this project does not have, then it's an appetite for more efforts not directed at solving already existing issues: Creating new hassles seems counter-productive to effective progress.

@dstebila honestly and clearly stated he has other priorities, served this role (in my sense of understanding it) thankfully for years and cannot provide sufficient time any more, so can I ask @bhess for the reasons to decline the (full) role? Lack of time? Lack of interest? Lack of challenge? (Imminent) Change of role?

To sound out alternatives, can I ask the same from everyone in the TSC: How much time can you @open-quantum-safe/tsc make available for the project, incl. possibly being its chair? Do you agree with my view (and arguably that of @brian-jarvis-aws ) what a chair should do or would you think it's indeed not much more than meeting facilitation (which indeed could be a shared responsibility or even one maybe delegated to an AI)? Again also tagging @brian-jarvis-aws for his take as to what he expects a TSC chair to do.

[dstebila]

As requested in today's status meeting, here is a draft list of responsibilities of the TSC chair, informed by the TSC charter and my own thoughts.

Things they really have to do:

• Organizing and presiding over meetings of the TSC
• Running TSC votes on GitHub
• Responding to queries from other parts of the PQCA

Things that hopefully they will do:

• Drive forward progress on TSC issues

Things that might or might not be in scope:

• Running OQS status meetings

Suggestions and opinions welcome.

[baentsch]

Thanks for this start, @dstebila .

Assuming PQCA operates as an open source project should, i.e., by open communication via the GH community, "queries from other parts of the PQCA" should come via GH TSC issues. Hence, "Drive forward progress on TSC issues", i.e., the 4th bullet) is a requirement for a chair, too, if we accept the 3rd bullet as a requirement. Sample case: #216: PQCA waiting for your input, not that of a simple TSC member.

The alternative would be to completely disconnect all PQCA aspects from OQS (TSC chair) and leave that to the PQCA liaison person. I still think a TSC chair should be driving to conclusion TSC issues, though.

What's really missing in the above is the external representation aspect that imo also needs to be covered: A project's chair is naturally the go-to person for external inquiries pertaining to the project (beyond GH inquiries): Presentations at conferences, (at such venues) establishing connections ("rapport") with project- as well as up- and downstream contributors is a key aspect of the role.

Running OQS status meetings is imo not directly in scope but it would be beneficial for joining up the external and internal view, of connecting user (up-&downstream) needs with contributor interest and availability, such as to guide priority-setting suitably.

[baentsch]

A good week until the next TSC meeting. As there has been no response to my questions above, I think it is fair to conclude that no TSC member currently has sufficient time available to take on the chair role as I (and arguably @brian-jarvis-aws) have described it.
If that assumption is wrong, now is the time to say so.
Otherwise the fallback appears to be a co-chair arrangement. I remain skeptical that this solves the underlying problem — if no single person has sufficient time, two people sharing the role risks producing the same outcome with added coordination overhead. Beyond internal efficiency, there is also the question of external clarity: the project's chair is its natural public face — the go-to person for conference invitations, external inquiries, and representing OQS to the broader PQC community. A co-chair structure makes that representation inherently ambiguous.

[RodriM11]

Hi! as per the last TSC meeting, some comments / suggestions off the top of my head:

• I would ask first what percentage of time would one have to provide to the role to "appropriately" cover the chair role? (Note that the key word is "appropriately", as from just running the TSC meetings to steering the project there is a wide gap, as @baentsch mentioned.
• I would also ask, particularly with regards to people that may be relatively new to the project, what degree of knowledge with "previous" events are needed in order to properly do the job?
• How long would the chair term be?
• Regarding the TSC co-chair role, maybe a different approach that could satisfy everyone would be a mixed approach: X time co-chair role (designed to introduce the new chair onto the role) + Y time new chain in solitary. This could help, for example, alleviate the concern regarding knowledge.

[dstebila]

* I would ask first what percentage of time would one have to provide to the role to "appropriately" cover the chair role? (Note that the key word is "appropriately", as from just running the TSC meetings to steering the project there is a wide gap, as [@baentsch](https://github.com/baentsch) mentioned.

Hard to say. I probably put in a couple of hours a week; this may not be adequate to drive things forward with great momentum, but it's all I can do.

* I would also ask, particularly with regards to people that may be relatively new to the project, what degree of knowledge with "previous" events are needed in order to properly do the job?

I think most of us will still be around, so that knowledge will be there.

* How long would the chair term be?

Undefined; but I think a 1-year term might be a good duration.

* Regarding the TSC co-chair role, maybe a different approach that could satisfy everyone would be a mixed approach: X time co-chair role (designed to introduce the new chair onto the role) + Y time new chain in solitary. This could help, for example, alleviate the concern regarding knowledge.

Good suggestion.

[baentsch]

Regarding the TSC co-chair role, maybe a different approach that could satisfy everyone would be a mixed approach: X time co-chair role (designed to introduce the new chair onto the role) + Y time new chain in solitary. This could help, for example, alleviate the concern regarding knowledge.

Good suggestion.

+1. As literally no-one has made any concrete suggestions how to move forward otherwise, let alone stated willingness to take on the role, what about this:

I'd nominate Rodrigo as TSC (member and) chair, asking Douglas to stay available as "mentoring co-chair" for say the next 4 months but then with Rodrigo being sole chair until say August 2027. This would definitely alleviate my concerns stated above and I think personally that Rodrigo's motivation to take on the various tasks outlined above currently is second to none.

[RodriM11]

First of all, let me thank @baentsch for the proposal and the support. I am grateful of the OQS project in general and of the work all of you have been doing during these years. I believe that there is still a relevant part to play by the project and I would like to be part of it.

Therefore, I accept the nomination, if @dstebila would be willing to serve as said "mentoring co-chair" for a specific amount of time. I will give my best to the role and the project, to ensure it continues to strive.

Maybe to avoid changing things in August, when a lot of people might be on vacation, we can serve on a co-chair role until September 2026, and then me being sole chain until September 2027. But the specifics of that can be debated, if people agree with the proposal.

Thank you in advance to everyone for the consideration.