Contents › 1. About this handbook
1. About this handbook
1.1 What it covers and what it does not
The public TC Handbook documents the rules a Technical Committee works under. This handbook documents the operation that carries those rules out. For every task in publishing a specification, running a ballot and running a public review, it records whose remit it is today, what system it runs on, what access it needs, how long it takes, and what record it leaves behind.
The audience is the Technical Committee and Standards Publishing Admin, the role that runs OASIS Technical Committee operations and standards publishing, whoever holds it. It is written so a successor can run the operation from it.
The handbook is served at ops-handbook.oasis-infra.net. It is not on the public web: a reader signs in with Google and only an oasis-open.org account is admitted, so the handbook reaches OASIS staff without being public. How that gate and the deploy are wired is in 8.4.
It covers:
- the publishing operation from intake to the audit record
- balloting
- public reviews
- the communications tied to those tasks
- the systems and access they depend on
- the records they produce
- the roles that hold them
- the known weak points in the operation, and what would fix each
It does not cover four things:
- It does not interpret OASIS policy: the TC Process and the public TC Handbook govern that, and section 1.3 sets out what happens when the two appear to disagree.
- It does not decide platform or infrastructure architecture.
- It does not address legal, membership or intellectual property questions.
- It carries no credentials, no host addresses, no account, bucket, distribution or zone identifiers, and no paths into anyone's machine or into the infrastructure.
It does name files inside its own repository, because a reader has to be able to find the fact registry. Systems are named by what they do, because this document circulates internally and outlives any one person's access.
Every operational claim traces back to an entry in the fact registry, with the source document and the exact section that proves it, and worked evidence from the live systems backs the text: real tickets, published artifacts and annotated screen captures. Figures that move, like the number of rules the acceptance criteria run, are re-derived from the system that owns them and dated, never quoted as fixed.
1.2 How to read an operations entry
Every operational section follows the same shape: a few sentences of plain prose that describe the task and why it exists, then, where it applies, a block of five facts.
- Owner
- whose remit this is today.
- System
- where it happens, named by function.
- Permission
- the access a person needs before they can do it.
- Timing
- how long it takes, or the clock it starts.
- Record
- the artifact left behind, such as a ticket, a published file, a report or an announcement.
Not every section carries all five. A section that describes a relationship rather than a discrete action states only the fields that apply. The values come from the registry entry behind the claim. None of them is inferred, and no owner or permission is written into this handbook that has not been observed in the real operation.
The second thing to read in an entry is its authority. Every operational claim carries one of four natures, and the wording signals which one:
| Nature | What it means | How it reads |
|---|---|---|
| Obligation | OASIS is bound by written policy, and the governing clause can be named | "OASIS must ...", with the clause cited |
| Practice | OASIS holds itself to this. It was earned from real work, and no single clause requires it | "OASIS does this, though no clause requires it" |
| Convention | An internal working agreement, adopted because it prevents a known failure | "The working convention is ..." |
| Finding | An observed state of the world, true on a stated date | "As of date, ..." |
Read those as a scale of how hard something is to change:
- An obligation changes only when policy changes.
- A practice changes whenever OASIS decides to stop doing it, and nothing outside OASIS obliges it to continue.
- A convention changes at any time by agreement among the people running the operation.
- A finding changes when the world does, which is why every finding carries a date.
From any entry, a reader should be able to say whether OASIS is bound or has chosen. Chapter 3 is built entirely on that difference.
A claim marked [VERIFY] could not be confirmed against a source when it was written. It is not evidence, and it must not be repeated to a TC. Appendix A lists every one of them and what was needed to close it.
1.3 Relationship to the TC Handbook and OASIS policy
The OASIS TC Process, the Committee Operations Process, the Naming Directives and the public TC Handbook are authoritative on policy:
- what a TC must do to advance a specification
- what each ballot requires
- what a public review must include
This handbook does not restate them and never overrides them. Where it needs a policy fact it points to the entry in the public TC Handbook's own registry rather than writing the rule out a second time, so a policy revision has exactly one place to be corrected.
The rule for conflicts is the one OASIS already states to TCs in its publication documentation.
It is not reconciled in prose, and it is not resolved by describing the operation as though the policy said something else.
One citation trap belongs here because it recurs across internal documents. Internal sources cite it both ways.
This handbook is internal. It is not published to TC members or to the public, and it is never handed to a TC in place of the public TC Handbook. It describes current practice rather than setting a fixed specification, and it changes as roles, systems and staff change. Draft 0.4 records the operation as it stood in July 2026.
1.4 OASIS Open, its Technical Committees, and its Open Projects
OASIS Open is the non-profit standards consortium: the organisation that runs the work this handbook supports. It operates two parallel programs, and this handbook documents one of them.
Technical Committees are the formal, member-based standards-development program under the OASIS TC Process. A TC is chartered by members, decides by ballot, and advances a specification through public review and the stages to OASIS Standard, with the approved work published to docs.oasis-open.org. Publishing, balloting and public reviews, the whole of the rest of this handbook, are TC operations.
Open Projects are the parallel program for open-source work: collaborative communities that develop code, APIs, reference implementations and specifications under OSI-approved open-source licences. An Open Project is funded by organisational sponsorship under lightweight stakeholder governance, individuals contribute without dues, and it is centred on a GitHub organisation with a mailing group, calendar, roster and ballot provided around it. Its work carries free public access in perpetuity, and its deliverables can move through the OASIS Standards approval process with the option to submit to ISO, IEC or ITU.
An Open Project is entered differently from a TC: one or more Project Sponsors meeting a Board-set dues threshold, together with named contributors, submit a project charter to the Open Project Administrator, and the project is governed by a sponsor-funded project governing board on its own GitHub organisation (oasis-open-projects), separate from the TC organisation (oasis-tcs).
The scope line is therefore exact: this handbook documents Technical Committee standards publishing. Where an Open Project differs operationally, a task written here for a TC does not transfer to it unchanged. It differs in three ways:
- GitHub-organisation-centric
- sponsor-funded
- entered a different way
The engagement measurement in chapter 2 already spans two GitHub organisations, the TCs and the Open Projects, for exactly this reason.