Technical Steering Committee

The Technical Steering Committee (TSC) is the technical heart of the TOSSI Foundation. It owns the technical direction of the entire open telecom stack TOSSI integrates - and nothing else. The TSC does not control the budget, marketing, or trademark; those belong to the Governing Board. This separation keeps technical decisions free of commercial pressure.

The model follows a proven technical-oversight pattern from mature open-source foundations: a small, elected, merit-based body that stewards projects through a transparent lifecycle.

Status: forming

The TSC described here has not yet been seated. Seat counts, term lengths, the founding membership, and meeting cadence are the initial proposal and will be finalized at the foundation’s first TSC bootstrap election. Treat every specific number on this page as a placeholder pending ratification.

Composition

Seats

A proposed 7 voting members, elected by and from the active maintainer community across all pillars. Odd-numbered to avoid ties.

Terms

Staggered two-year terms, with roughly half the seats up for election each year to preserve continuity.

Neutrality cap

No more than ~40% (at most 2 of 7) of seats may be held by individuals from any single employer. If an election would breach the cap, the next-eligible candidate is seated.

Chair

A Chair (and Vice-Chair) elected by the TSC from among its members. The Chair runs meetings and represents the TSC to the Governing Board as a non-voting liaison; the Chair does not hold a tie-breaking vote.

Seats are held by individuals, not companies. Members serve in their personal capacity, on the strength of their technical contribution and judgment. Eligibility to vote and stand is tied to demonstrated, sustained contribution (the active-maintainer roll), not to membership tier or company sponsorship.

Responsibilities

The TSC is accountable for the coherence, quality, and neutrality of the integrated stack.

Technical direction

Sets cross-cutting architecture, the integration strategy across pillars, and the foundation’s technical priorities and roadmap horizons.

Project lifecycle

Accepts new projects into the sandbox, promotes projects through incubation to graduation, and archives projects that are no longer viable.

Conformance & interop policy

Owns what “validated” means: the conformance criteria, interoperability test policy, and how results are published - vendor-agnostically.

Cross-project arbitration

Resolves disputes that span more than one project or pillar, where no single maintainer group has authority.

Standards alignment

Maintains liaison with 3GPP, the O-RAN ALLIANCE, the IETF, and ETSI so integration tracks the real specifications.

Delegation & SIGs

Charters Special Interest Groups and working groups, and delegates day-to-day authority to maintainers - keeping decisions at the lowest competent level.

The TSC deliberately delegates as much as possible. Routine, project-local decisions belong to maintainers; the TSC handles only what genuinely spans the foundation.

Project lifecycle

Every TOSSI project moves through three maturity stages on a sandbox → incubating → graduated ladder. The stage signals maturity and adoption risk to users, not the project’s worth.

1. Sandbox experimental

   The entry point for early or experimental work. Low bar, low commitment, clear signal to users that the project is young.

   • Entry: a sponsor on the TSC, an Apache-2.0 license, a clean IP/DCO posture, and adherence to the Code of Conduct.
   • Expectation: users should treat sandbox projects as experimental.
   • Review: sandbox projects are reviewed periodically; those that go dormant are archived.

2. Incubating adoption growing

   Projects with demonstrated traction and a healthy contributor base.

   • Entry: multiple production or serious pilot users, a growing and reasonably diverse set of committers, a documented and tested integration, and a public roadmap.
   • Expectation: suitable for users comfortable with evolving software; APIs may still change.
   • Review: the TSC reviews incubation status and progress toward graduation.

3. Graduated production-grade

   The mark of a mature, neutrally governed, production-grade project.

   • Entry: adopters in production across multiple independent organizations, committers from at least two organizations (no single-vendor capture), a completed independent security review, a passing conformance suite, documented release and support cadence, and a CII/OpenSSF-style best-practices posture.
   • Expectation: safe for broad production adoption.
   • Decision: graduation requires a supermajority (two-thirds) TSC vote.

The stage is a signal, not a verdict

A sandbox project is not “lesser” - it is younger. The lifecycle exists so adopters can calibrate risk at a glance, and so the foundation never overstates the maturity of what it ships. Projects can also be archived from any stage when they are no longer maintained; archival is honest, not punitive.

How decisions are made

The TSC works the same way the rest of the foundation does - in the open, by consensus first, by vote only when it must.

1. Lazy consensus is the default. Most decisions are made on public issues, pull requests, or TOSSI Enhancement Proposals (TEPs). If no member with standing objects within the review window, the decision carries. Silence is assent.

2. Discussion is public. TSC meetings have public agendas and minutes; recordings are posted. Anyone may attend and observe; the floor is open during community segments.

3. Voting is the backstop. When consensus fails, the TSC votes. Routine matters pass by simple majority; high-impact matters - graduation, charter amendments, lifecycle policy changes - require a two-thirds supermajority.

4. Quorum. A vote requires two-thirds of voting members present (or voting asynchronously) to be valid.

5. The record is the source of truth. Every formal decision, its rationale, and the vote tally are published. If it isn’t in the public record, it didn’t happen.

What needs a formal TSC vote

Decision	Mechanism
Routine cross-project change, SIG charter	Lazy consensus
Accept a project into sandbox	Sponsor + simple-majority confirmation
Promote a project to incubating	Simple majority
Promote a project to graduated	Two-thirds supermajority
Archive a project	Simple majority
Amend lifecycle or conformance policy	Two-thirds supermajority
Amend the charter (technical portions)	Two-thirds supermajority

Meetings & transparency

• Cadence: a proposed bi-weekly public TSC call, plus asynchronous decision-making on the tracker between calls.
• Open access: agendas posted ahead of time; minutes and recordings posted afterward; decisions logged in the public repository.
• Community input: community-call topics and TEPs feed into the TSC agenda. See Community for how to bring something forward.

Status: forming

Until the first TSC is seated, technical proposals are gathered in the open repository and triaged by the founding maintainers. The cadence and meeting links above will be published when the committee is established.

Related pages

Governance charter Mission, scope, neutrality, structure, decision-making, and IP/licensing policy.

Code of Conduct The community standards all participation - including TSC business - is held to.

Roadmap The Now / Next / Later horizons the TSC stewards across the pillars.

Contributing How to raise a proposal, sign off with the DCO, and get involved.