2. The Technical Committees this manual serves

The rest of this handbook describes an operation. This chapter is about the people that operation serves: the OASIS Technical Committees (TCs), how they work, and how they differ from each other in ways that change the intake, the tools and the correspondence path. The numbers below come from a two-year audit of TC requests and activity covering 21 July 2024 to 20 July 2026, members only, with OASIS staff and automated accounts left out, and the data gathered between 20 and 23 July 2026. They are dated findings, not policy, here so a successor can see what shape the committees are in before working with any of them.

#2.1 Activity, as measured by tool usage

OASIS sees only a fraction of what a TC does. Most of the work happens in calls, in email and in Word documents that OASIS cannot query. What it can query is tool usage: the marks a TC leaves in the systems OASIS runs. Everything in this chapter is activity measured that way, and the first thing to know is that a TC can be busy and leave almost no mark at all.

There are four kinds of tool data. A TC that is quiet in one is often busy in another:

1. Developer tools: commits, issues, pull requests and comments on the two GitHub organisations, Jira issues, and wiki edits.
2. Booked meetings: calls scheduled on the member platform calendar.
3. Publications: specifications deposited on docs.oasis-open.org in the window.
4. Member discussion: discussion posts written by a member rather than staff. This one is read by hand; the other three a query can count.

No TC is judged on one kind of data alone, because each kind catches TCs the others miss:

• Publications alone show LegalDocML and Energy Interoperation as active. Both do no developer-tool work and book no meetings, yet each published a normative specification in the window.
• The calendar alone shows AMQP, SAM and ESAT as active. None did developer-tool work or published in the window, but all three book meetings on a forward cadence.
• The discussion threads alone show BDXR and PMRM as active. Both are quiet everywhere else, yet post agendas and minutes every month under a named member.
• DITA and CACAO appear only in the developer tools.

Judging any of these on a single kind of data would classify it incorrectly as inactive.

As of the 20 July 2026 pull, counting how many of the four kinds of data each TC appears in, the 33 open TCs the audit covers look like this:

Six TCs appear in none of the four. That says something about the data, not about the committees. For five of them, eMIX, WS-Calendar, AMQP-BINDMAP, OpenCSA and LP, the most recent thing in their community is a staff notice about the 2024 platform migration. For LegalRuleML, no member has posted since 2022. Being absent from all four kinds of data is worth a second look. Being absent from one is not: a TC that never touches the calendar shows zero meetings whether it meets weekly or never.

#2.2 Three operating models, and why the model changes the operation

Looking across all four kinds of data shows a distinction that a single activity score would miss. TCs fall into three operating models, and the model determines where a successor looks for the work, which tools the TC actually touches, and how correspondence reaches its members:

• Meeting-driven TCs run on regular calls, agendas and minutes with little or no repository work, and several author their specifications in Word rather than in a repository: AMQP, SAM, ESAT, PMRM, BDXR and Emergency Management.
• Asynchronous TCs do real repository work and book no meetings at all on the calendar: DITA, TOSCA, UBL, VIRTIO and OpenC2.
• Both keep a live meeting record and a live repository together: CSAF, OData, PKCS#11, KMIP, XACML, OpenEoX, CTI and ODF.

"No meetings booked" is a fact about the calendar, not proof of no meetings. Some asynchronous TCs record their calls as posted minutes instead. BDXR is one example, and UBL's weekly Atlantic-call minutes sit on its discussion feed rather than on the calendar.

The model matters to the operation in three concrete ways:

1. Intake differs. A meeting-driven, Word-native TC delivers a rendered package and its approving minutes, while an asynchronous TC's work and its vote record may sit in a repository or in per-issue ballots.
2. The tools differ. A request about a meeting-driven TC will not be answered by looking at GitHub.
3. The comms path differs. A TC reachable through its Higher Logic community is reached differently from one whose editors coordinate by call.

#2.3 LegalDocML: an active TC that manages its work elsewhere

LegalDocML is an example for the working-channel check at intake. On repository activity alone, LegalDocML appears inactive: its GitHub repository was last pushed on 2 June 2022, and its Jira project exists but has never held a single issue. The committee is active. It published Akoma Ntoso v2.0 as a Committee Specification (cs01) on 8 May 2026 and passed a Special Majority Vote that closed on 15 July 2026, in which all six eligible Voting Members voted Yes and none voted No. Its work runs through its Higher Logic community and the TC Administrator process, not through the developer tools that were set up for it and never adopted.

For intake, apply this check consistently. Confirm the working channel per TC at intake, from the request and the approving minutes, the way the publishing and balloting chapters require, rather than inferring it from whichever kind of data is easiest to read.

#2.4 What TCs actually ask for

Inbound requests belong to one process seen at different stages. Public reviews, ballots and publication requests are stages of one path from a draft to an approved standard, which is why the operation records far more publications than publication requests.

Across the 24-month window, once a single 20-ticket automated spam burst from June 2026 is excluded, there were 122 genuine requests, of which 85 carry a confirmed member name. As of the 23 July 2026 pull the mix was:

The 24 publication requests sit against 67 in-window publications because most stages publish as a stage of the review and ballot flow rather than as a separately requested event; see the publishing operation and balloting chapters for how one request carries a document through several published stages. The 19 template and starter-document requests are drafts beginning, the intake end of the same pipeline. The most frequent named requesters include people from the Word-native, meeting-driven TCs, such as Valerie Fenwick for PKCS#11 and Judith Furlong for KMIP, whose TC work is recorded in requests, documents and minutes, outside repository activity.

Requests reach the queue two ways:

1. A member emails or posts and staff open the ticket on their behalf. The requester's identity is carried into the ticket.
2. A public web request form writes a ticket directly. The form is a Gravity Forms request page that writes into the request tracker as a service account and creates a TCADMIN ticket, as chapter 8 records. It submits as the service account rather than as the person, so the ticket does not carry the requester's identity, and the form is open to anyone, which is how the 20-ticket spam burst reached the queue.

Every genuine request still gets a ticket, opened on behalf of the requester where the form did not, as chapter 9 records.

#2.5 How TCs decide, and who signs the work

A TC's formal decisions are recorded in its ballots, and the ballot record shows how decisions are made. Of the 120 most recent closed ballots in the public archive, 93 are attributed to these TCs, and as of the July 2026 pull they break down into:

• 42 per-issue resolution votes, all of them VIRTIO, which governs by ballot and holds 47 ballots in total;
• 34 spec-stage approvals of drafts, Committee Specifications, notes and charters;
• 15 candidates for OASIS Standard and calls for consent;
• 2 officer elections and other.

The standards ladder is visible in the ballot titles themselves: TOSCA v2.0 took six ballots from draft approval to the OASIS Standard call for consent, and ODF v1.4 took four, including a vote to continue after comments. The LegalDocML Special Majority Vote in 2.3 is one such ballot, and with exactly six Voting Members on the roster and six of six voting Yes, that voter list is the voting roster.

Published specifications identify the editors responsible for the text, and in many cases that editor set is small. Editors carry named, signed responsibility for the text, and the editor set can be small even when the contributor list is large:

• Energy Interoperation listed Toby Considine as the single editor for all four of its in-window drafts.
• UBL listed Kenneth Bengtsson as the single editor for its Committee Specification.
• KMIP and much of PKCS#11 list three Cryptsoft names as editors, Tim Hudson, Greg Scott and Tony Cox.
• Stefan Hagen is a named editor on seven specifications spanning five TCs, and Tim Hudson on five across four committees.

Contributor appendices run to hundreds of names, CTI credits 310 and VIRTIO 204, while formal signed responsibility is assigned to one or two people per Work Product. The named-editor set is the relevant continuity record, and it is legible only in the published record.

#2.6 The tools, and the mailing-list change that reshaped the comms path

Five tools serve the TCs, and each is different:

• The member platform (Higher Logic) is the member-facing service and record location for rosters, ballots, meeting calendars, document libraries and discussion. It covers 32 of the roughly 50 active TCs by the site taxonomy, it is the only tool six of them use, and 28 of 34 open communities had a post within the trailing 12 months.
• GitHub carries the specification text and the argument about it, across two organisations rather than one, so any count limited to a single organisation undercounts the total.
• Jira is a genuine day-to-day tracker for only two TCs, UBL and ODF; its licence is free and unlimited and the other projects are historical record, so the question about Jira is service quality, not cost.
• The wikis have no recent edit activity: five members, two TC namespaces, no edit anywhere since 22 May 2025, and no edits at all in the trailing 12 months [VERIFY].
• docs.oasis-open.org is the publication service, where approved work is published, not a tool members work in; 67 publications came from 21 directories out of 119 in the window.

The February 2024 platform migration changed how TC communications are routed.

For two decades the classic mailing lists carried member discussion: 427,256 messages from October 1999 to the freeze, across 963 lists and 12,680 distinct contributors. In February 2024 the Higher Logic migration retired the classic list server, and all TC lists stopped carrying new traffic. The mail-forum model was a low-friction participation channel. DocBook, the largest list community at 40,133 messages, left OASIS in the migration year, and its practitioners rebuilt their site independently. The record itself was preserved: the full archive is read-only and searchable at lists-archive.oasis-open.org.

This routing change is relevant to the review and communications chapters. The public-review comment routing described in the public reviews and communications chapters depends on this fact, so it is stated there in full.