From 2cecbc0b17a9c5750ba9726fbd693e3887d12d34 Mon Sep 17 00:00:00 2001 From: Sam Mesterton-Gibbons Date: Fri, 6 Feb 2026 14:21:28 +0000 Subject: [PATCH 1/5] governance: Add decision-making principles Adds a set of principles that define what TAMS is, and how we make decisions and evolve it, to aid technical decision making by the TSC (and others!). --- GOVERNANCE.md | 2 ++ PRINCIPLES.md | 38 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 40 insertions(+) create mode 100644 PRINCIPLES.md diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 251ad2f5..85f1b30a 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -70,6 +70,8 @@ In general, the TSC is responsible for: - Deciding how any certification or compatibility programme operates - Coordinating any marketing, events, or communications regarding the project. +To aid in decision making, a set of principles guiding what TAMS is and how it develops are set out in [PRINCIPLES.md](./PRINCIPLES.md) + Furthermore during the Setup and Transition Periods, the TSC is charged with: - Finding a suitable legal and administrative framework through which the project should operate diff --git a/PRINCIPLES.md b/PRINCIPLES.md new file mode 100644 index 00000000..5775dde6 --- /dev/null +++ b/PRINCIPLES.md @@ -0,0 +1,38 @@ +# Principles + +These principles describe both what TAMS is (and isn’t) as a technology, and also some of the principles that define it’s direction and development. +The TSC use these to guide technical decision making and shape the direction of the project. + +## What is TAMS? + +Overall, TAMS and the TAMS API is an interface for writing media to and reading it from a store. +It provides a framework for sharing that media between systems, solutions and organisations using a content-centric, cloud-native approach, all focused around a store (or a number of stores). + +1. TAMS is designed to be interoperable. + Having TAMS support should enable integration with other TAMS solutions, removing or minimising the need for bespoke integrations. +2. TAMS is agnostic to clouds, codecs, and containers. + It may describe how to integrate with a particular technology, but the core API can be implemented in many ways for many purposes. +3. TAMS is for media. + While it also works for data (and has data as a supported type) it is primarily designed for media-like workflows on a timeline. +4. TAMS supports fast-turnaround/near-live workflows, but also works well for file-based workflows, and in some cases can take the place of live signal-centric workflows, if appropriate latency tradeoffs can be made. +5. TAMS does not implement a MAM. + It should contain the minimum possible content discovery and library management features. + Anything else should go in a system designed for that purpose. +6. TAMS is open source to reduce barriers to entry and maximise adoption: anyone should be able to participate in the ecosystem, providing maximum choice. +7. TAMS is a living specification. + It will evolve over time to meet the needs of the community. +8. The TAMS repository contains the core specification and schemas, along with various examples to help implementers and Application Notes covering best practices and possible approaches to specific areas or technologies. + +## Guiding Principles + +1. TAMS is a small sharp tool. + It does not solve all problems in all ways. +2. TAMS and the API should be as simple as possible, and always strike a balance across aspects such as complexity, capability, scalability. +3. TAMS API servers and clients with compatible versions should interoperate. + The specification is prescriptive and opinionated where necessary to enable this. +4. However we aim to give users as much flexibility as possible while ensuring interoperability +5. Optional features and capabilities are used cautiously, to simplify client implementations and reduce integration engineering work. +6. We re-use patterns and approaches where possible: both within TAMS, and drawing on existing approaches in other technologies +7. Breaking changes are possible, but we strike a balance to minimise impact and maximise benefit. + We make decisions with strong engineering justification and consider the impact of change, through an open decision process +8. The TAMS community is governed by a balanced mix of users (broadcasters, content owners etc.) and technology/solution vendors From ff51662bf970be3080ef06a79e604083f7ec2ac5 Mon Sep 17 00:00:00 2001 From: Sam Mesterton-Gibbons Date: Fri, 6 Feb 2026 14:22:07 +0000 Subject: [PATCH 2/5] readme: Add link to governance doc --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 2b5e3615..57b15aba 100644 --- a/README.md +++ b/README.md @@ -32,6 +32,7 @@ Users of TAMS are insulated from the details of the underlying storage. - [Rendered Specification](https://bbc.github.io/tams) - [Supporting Documentation (Application notes and Decision Records)](./docs/README.md) - [Example API Usage Scripts](./examples/README.md) +- [Description of governance process](./GOVERNANCE.md) ## Design From 96ba97115e3725c470da16de100e3b810c0bcbb1 Mon Sep 17 00:00:00 2001 From: Sam Mesterton-Gibbons Date: Tue, 10 Feb 2026 15:15:38 +0000 Subject: [PATCH 3/5] fixup! governance: Add decision-making principles --- PRINCIPLES.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/PRINCIPLES.md b/PRINCIPLES.md index 5775dde6..aafd4cf9 100644 --- a/PRINCIPLES.md +++ b/PRINCIPLES.md @@ -30,9 +30,9 @@ It provides a framework for sharing that media between systems, solutions and or 2. TAMS and the API should be as simple as possible, and always strike a balance across aspects such as complexity, capability, scalability. 3. TAMS API servers and clients with compatible versions should interoperate. The specification is prescriptive and opinionated where necessary to enable this. -4. However we aim to give users as much flexibility as possible while ensuring interoperability +4. However we aim to give users as much flexibility as possible while ensuring interoperability. 5. Optional features and capabilities are used cautiously, to simplify client implementations and reduce integration engineering work. -6. We re-use patterns and approaches where possible: both within TAMS, and drawing on existing approaches in other technologies +6. We re-use patterns and approaches where possible: both within TAMS, and drawing on existing approaches in other technologies. 7. Breaking changes are possible, but we strike a balance to minimise impact and maximise benefit. - We make decisions with strong engineering justification and consider the impact of change, through an open decision process -8. The TAMS community is governed by a balanced mix of users (broadcasters, content owners etc.) and technology/solution vendors + We make decisions with strong engineering justification and consider the impact of change, through an open decision process. +8. The TAMS community is governed by a balanced mix of users (broadcasters, content owners etc.) and technology/solution vendors. From 503784a55c971546a506611cb3fdc1fe11d91165 Mon Sep 17 00:00:00 2001 From: Sam Mesterton-Gibbons Date: Tue, 10 Feb 2026 15:15:56 +0000 Subject: [PATCH 4/5] governance: Sharpen some of the principles Improves the wording of some of the principles, following review suggestions Co-authored-by: James Sandford --- PRINCIPLES.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/PRINCIPLES.md b/PRINCIPLES.md index aafd4cf9..ac426a2d 100644 --- a/PRINCIPLES.md +++ b/PRINCIPLES.md @@ -8,7 +8,7 @@ The TSC use these to guide technical decision making and shape the direction of Overall, TAMS and the TAMS API is an interface for writing media to and reading it from a store. It provides a framework for sharing that media between systems, solutions and organisations using a content-centric, cloud-native approach, all focused around a store (or a number of stores). -1. TAMS is designed to be interoperable. +1. TAMS is designed as an interoperable media framework. Having TAMS support should enable integration with other TAMS solutions, removing or minimising the need for bespoke integrations. 2. TAMS is agnostic to clouds, codecs, and containers. It may describe how to integrate with a particular technology, but the core API can be implemented in many ways for many purposes. @@ -16,7 +16,7 @@ It provides a framework for sharing that media between systems, solutions and or While it also works for data (and has data as a supported type) it is primarily designed for media-like workflows on a timeline. 4. TAMS supports fast-turnaround/near-live workflows, but also works well for file-based workflows, and in some cases can take the place of live signal-centric workflows, if appropriate latency tradeoffs can be made. 5. TAMS does not implement a MAM. - It should contain the minimum possible content discovery and library management features. + It should contain the minimum possible content discovery and library management features required for effective interoperability. Anything else should go in a system designed for that purpose. 6. TAMS is open source to reduce barriers to entry and maximise adoption: anyone should be able to participate in the ecosystem, providing maximum choice. 7. TAMS is a living specification. @@ -36,3 +36,4 @@ It provides a framework for sharing that media between systems, solutions and or 7. Breaking changes are possible, but we strike a balance to minimise impact and maximise benefit. We make decisions with strong engineering justification and consider the impact of change, through an open decision process. 8. The TAMS community is governed by a balanced mix of users (broadcasters, content owners etc.) and technology/solution vendors. +9. When common requirements arise, or the need for a common piece of functionality becomes clear, we attempt to standardise an approach either in the API Specification or an Application Note to enable interoperability. From 1aabedffae11138c18a2598689a85d6a74beac5d Mon Sep 17 00:00:00 2001 From: Sam Mesterton-Gibbons Date: Mon, 16 Feb 2026 12:39:36 +0000 Subject: [PATCH 5/5] fixup! governance: Sharpen some of the principles --- PRINCIPLES.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/PRINCIPLES.md b/PRINCIPLES.md index ac426a2d..e1a3d26f 100644 --- a/PRINCIPLES.md +++ b/PRINCIPLES.md @@ -10,10 +10,10 @@ It provides a framework for sharing that media between systems, solutions and or 1. TAMS is designed as an interoperable media framework. Having TAMS support should enable integration with other TAMS solutions, removing or minimising the need for bespoke integrations. -2. TAMS is agnostic to clouds, codecs, and containers. +2. TAMS is agnostic to clouds, codecs, and containers and is intended to deploy anywhere, including on-premise and at the edge. It may describe how to integrate with a particular technology, but the core API can be implemented in many ways for many purposes. 3. TAMS is for media. - While it also works for data (and has data as a supported type) it is primarily designed for media-like workflows on a timeline. + It is primarily designed for media-like workflows on a timeline, however it also works for data-as-media that is accessed through the index of time (and as such, has data as a supported type). 4. TAMS supports fast-turnaround/near-live workflows, but also works well for file-based workflows, and in some cases can take the place of live signal-centric workflows, if appropriate latency tradeoffs can be made. 5. TAMS does not implement a MAM. It should contain the minimum possible content discovery and library management features required for effective interoperability. @@ -31,9 +31,10 @@ It provides a framework for sharing that media between systems, solutions and or 3. TAMS API servers and clients with compatible versions should interoperate. The specification is prescriptive and opinionated where necessary to enable this. 4. However we aim to give users as much flexibility as possible while ensuring interoperability. -5. Optional features and capabilities are used cautiously, to simplify client implementations and reduce integration engineering work. -6. We re-use patterns and approaches where possible: both within TAMS, and drawing on existing approaches in other technologies. -7. Breaking changes are possible, but we strike a balance to minimise impact and maximise benefit. +5. The specification is agnostic to implementation, and we avoid implementation details driving decision-making (however we strike a balance in writing a specification that can be implemented) +6. Optional features and capabilities are used cautiously, to simplify client implementations and reduce integration engineering work. +7. We re-use patterns and approaches where possible: both within TAMS, and drawing on existing approaches in other technologies. +8. Breaking changes are possible, but we strike a balance to minimise impact and maximise benefit. We make decisions with strong engineering justification and consider the impact of change, through an open decision process. -8. The TAMS community is governed by a balanced mix of users (broadcasters, content owners etc.) and technology/solution vendors. -9. When common requirements arise, or the need for a common piece of functionality becomes clear, we attempt to standardise an approach either in the API Specification or an Application Note to enable interoperability. +9. The TAMS community is governed by a balanced mix of users (broadcasters, content owners etc.) and technology/solution vendors. +10. When common requirements arise, or the need for a common piece of functionality becomes clear, we attempt to standardise an approach either in the API Specification or an Application Note to enable interoperability.