# OpenStack elections (2026): why PTL & TC votes shape the roadmap

- Link: https://thestackobserver.com/openstack-elections-2026-why-ptl-tc-votes-shape-the-roadmap/
- Published: 2026-02-05T08:57:50-05:00
- Author: Stackxx

Open source communities don’t just ship code; they ship _direction_. In OpenStack,
that direction is shaped through a governance model where maintainers and elected
roles—especially Project Team Leads (PTLs) and the Technical Committee (TC)—turn
an enormous set of proposals, reviews, and operational feedback into coherent project
priorities.

That’s why the opening of the **OpenStack 2026 technical election cycle** (nominations
starting February 4, 2026) is more than a calendar item. It’s one of the moments
where the community’s next six to twelve months become “real”: what gets funded,
which integration work is prioritized, how strict compatibility promises are, what
kinds of AI/HPC demands are treated as first-class, and how the project positions
itself amid changing infrastructure economics.

## What’s happening right now: nominations and the timeline

According to the OpenStack election dashboard, nominations for both **TC seats**
and **PTL seats** open on **Feb 04, 2026 23:45 UTC** and run through **Feb 18, 2026
23:45 UTC**. Campaigning follows, then balloting for both TC and PTL elections begins**
Feb 25, 2026** and runs until **Mar 18, 2026**.

If you’ve never paid attention to these dates, it’s worth understanding what each
stage effectively controls:

 * **Nominations:** who is willing to be accountable for a project team or for cross-
   project technical direction.
 * **Campaigning:** the opportunity to state priorities, tradeoffs, and how a candidate
   will handle tension between operators and contributors.
 * **Voting:** where active contributors choose who should arbitrate the hard decisions(
   and who should hold the pen on the roadmap).

## PTLs vs the Technical Committee: different levers, same impact

In OpenStack, PTLs and the TC are often described as “governance,” but their effects
are deeply technical.

### Project Team Leads (PTLs): the shape of day-to-day change

PTLs are elected for a six-month cycle and are responsible for helping their project
teams execute: coordinating reviews, setting priorities, and representing their 
project in cross-team planning. If you operate OpenStack, PTL priorities show up
as:

 * how quickly bugfixes land and are backported,
 * whether “operator pain” issues are prioritized alongside features,
 * how aggressively API changes are discussed (and how compatibility is enforced),
 * and the tone of collaboration with adjacent projects (Neutron/Nova/Cinder/Ironic,
   etc.).

For workloads like AI/HPC, PTLs increasingly influence whether integration work—
GPU scheduling primitives, bare metal workflows, network offload compatibility, 
storage performance—gets steady attention or becomes a series of one-off patches.

### The Technical Committee (TC): cross-project technical coherence

The TC, by contrast, is the body that steers overall technical direction and governance
across the whole ecosystem. For this election, the dashboard indicates that **five
TC seats** are being renewed for one-year terms. The TC’s decisions tend to surface
as:

 * project-wide standards (policies, testing expectations, release coordination),
 * how official projects are recognized and maintained,
 * how the community resolves disputes when “local project needs” conflict with “
   ecosystem health.”

If you want fewer surprise breakages and more predictable upgrade paths, TC-level
culture matters.

## Why this election cycle is especially relevant in 2026

Two ecosystem shifts are putting governance choices under a brighter light.

### 1) Infrastructure economics are changing (again)

AI-driven demand is raising the stakes for efficient, high-utilization infrastructure.
OpenStack is often deployed where operators need control: private clouds, regulated
environments, or regions where sovereignty matters. Decisions about what counts 
as “core,” which integrations are prioritized (Kubernetes, Kata Containers, bare
metal), and how tightly projects coordinate can determine whether OpenStack feels
like a modern platform or an accumulation of legacy workflows.

### 2) Contributor identity and voting eligibility are operationally important

The election dashboard explicitly notes practical requirements: voters should confirm
their preferred email address in Gerrit by Feb 18, 2026, and ensure CIVS emails 
can be received. It also references a membership renewal process following OpenInfra’s
integration with the Linux Foundation in 2025. That’s not bureaucracy for its own
sake—these steps influence who participates, and therefore whose priorities are 
represented.

## How to engage (even if you’re “just an operator”)

Operators sometimes assume elections are for “upstream developers,” but OpenStack’s
electorate definition includes contributors in the relevant timeframe, and the nomination
process is intentionally open to those in the electorate. Even if you don’t plan
to run, there are high-leverage ways to engage:

 * **Read candidate statements** and look for concrete commitments: testing, backports,
   operator feedback loops, and cross-project coordination.
 * **Ask technical questions** during campaigning: upgrade policy, deprecation strategy,
   security posture, and how AI/HPC requirements will be handled.
 * **Encourage maintainers you trust** to run—especially those who have proven they
   can balance feature work with operational stability.

Healthy open source governance is simply the mechanism by which a technical community
aligns incentives. When it works, the codebase becomes easier to run, easier to 
secure, and easier to evolve.

## Sources

 * [OpenStack Governance — Election dashboard (2026 schedule and process)](https://governance.openstack.org/election/)
 * [OpenInfra Foundation — “Inside Open Infrastructure: January 2026” (mentions OpenStack election season opening Feb 4)](https://openinfra.org/blog/openinfra-newsletter-january-2026/)