10. Roles and ownership

#10.1 The role map today

The operation depends on four roles:

• Technical Advisor, engaged externally. Performs TC Administration.
• Director of IT. Holds the platforms and the accounts they run on.
• Chief Operating Officer. Holds organizational oversight.
• A standards role that would own policy. Not filled.

The staff member who ran publication and public-review administration left OASIS in June 2026. Since then one person holds the TC Administrator and staff contact role for these TCs, and handles both the publication and the opening and running of the public review. The handoff in which one person published the files and another opened the review no longer exists. This is recorded here as a role fact, and again in 11.1 as a fragility.

TC Administration is an OASIS staff authority, not an outside approval. Staff authorize and determine. No OASIS document should describe TC Administration as an outside party whose consent must be obtained; the document is usually written by TC Administration itself.

#10.2 What the incoming standards hire inherits

This section tells a person taking the standards role what is actually in their hands on day one. It is an inventory, not a job description.

They inherit the operation this handbook describes:

• Publication to the docs site end to end, from intake through the acceptance criteria, the repository chain, the manual four-layer deploy and the review that confirms the live site (chapter 4).
• Balloting, including the roster arithmetic, the Special Majority Vote and the route from Committee Specification through Candidate OASIS Standard to OASIS Standard (chapter 5).
• Opening, running and closing public reviews, where the announcement is itself the act that starts the clock (chapter 6).
• The announcements and TC-facing correspondence attached to all of it (chapter 7).
• The access grants on every system involved, which are granted separately rather than bundled behind one login (chapter 8).
• The records in chapter 9, which are what makes any of the rest auditable afterwards.

They also inherit the fragilities in chapter 11 without exception:

• The deploy is manual and runs from a staff workstation.
• Two of the automated deploy steps stopped working after an infrastructure migration and were never replaced.
• Two of the systems the operation used to rely on no longer work, and are worked around rather than fixed.
• The request tracker cannot report on its own contents by request type or by requester.

These are the current working conditions for whoever holds the role next.

What they do not inherit is a written policy mandate for the mechanics. The intent described to date is that the standards role owns policy, meaning how OASIS interprets and applies the TC Process, and that the day-to-day publication and balloting mechanics move to a dedicated support position reporting into it once that position exists [VERIFY].

#10.3 TC-side roles and where staff involvement stops

The TC owns four kinds of decision:

• what the specification says
• the companion artifacts that travel with it
• the per-specification publication preferences
• the TC-wide publication defaults

Consensus on all four is reached inside the committee before a request reaches staff. The TC does not have to maintain:

• the rendering toolchain
• the render filters
• the PDF configuration
• the deployment pipeline

OASIS operates and refines those under the stated contract.

Staff involvement stops at the content.

Each of these is a stated limit in the contract OASIS gives its TCs, which makes it as binding as the promises beside it.

The same posture governs the ballot. Statements of Use and their links are taken at face value:

• conformance is not audited
• Primary Representative endorsements are not chased
• the comment facility is not policed as a prerequisite

Those are real policy, handled only if someone objects. The role is to run the mechanics cleanly, not to gatekeep the committee.

At delivery the boundary is a handover, not a shared workspace. TC editors deliver the final package through the TC document portal or by email, and staff move it into the internal publishing repositories. A TC is never instructed to upload to those repositories: they are OASIS's internal publication bookkeeping, not a committee workflow. A TC may keep whatever it wants in its own space, and a package may arrive fully rendered or as source for staff to render. The requirement that does not change is that the final published form conforms to the naming directives, the template and the acceptance criteria, whatever form it arrived in.