Skip to content

Commit dd477c4

Browse files
committed
Document how to manage a custom terms type
1 parent 0a3194d commit dd477c4

File tree

1 file changed

+70
-0
lines changed

1 file changed

+70
-0
lines changed
Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
---
2+
title: Manage a custom terms type
3+
weight: 6
4+
---
5+
6+
# How to manage a custom terms type
7+
8+
When tracking terms and conditions across different services, you might encounter situations where a service uses terms types that aren't yet supported by Open Terms Archive.
9+
This guide will help you handle these custom terms types effectively, whether you're working on a new collection or expanding an existing one.
10+
11+
## Understanding the validation
12+
13+
Open Terms Archive validates terms types to ensure consistency and quality across collections. When you encounter a validation error like:
14+
15+
```shell
16+
1) Service declarations validation
17+
<service_name>
18+
valid declaration schema:
19+
Error:
20+
21+
data/terms must be equal to one of the allowed values (in entire file)
22+
```
23+
24+
This means the terms type you're trying to use isn't in the official list of supported types.
25+
26+
## Before going further
27+
28+
Before proceeding with using a custom terms type, please double-check that the type you're considering doesn't already exist in the supported terms types list. Different services often use different names for the same type of terms. For instance, "Terms and Conditions" might be called "Terms of Use" or "Terms of Service" by different services.
29+
30+
Review the [supported types list](https://github.com/OpenTermsArchive/terms-types/blob/main/termsTypes.json) carefully to ensure the terms type you want to track is not already supported under a different name. If it does, use the associated type in your declaration. If you are sure it's not supported, you can proceed with the following steps. If you're unsure, you can ask for help in the [Open Terms Archive community]({{< relref "community/how-to/join" >}}).
31+
32+
## Long-term solution
33+
34+
The recommended approach is to contribute your new terms type to the official list. This helps maintain consistency across collections and enables better comparison of terms across different services.
35+
36+
You can propose your new terms type for inclusion in the official list of supported types via the [dedicated repository](https://github.com/OpenTermsArchive/terms-types), following the [contribution process](https://github.com/OpenTermsArchive/terms-types/blob/main/CONTRIBUTING.md#add-new-terms-types).
37+
38+
This process has the following benefits:
39+
40+
- Your terms type becomes available to all collections
41+
- You don't need to maintain a custom fork
42+
- It helps build a more comprehensive and useful shared list
43+
- Enables better comparison of terms across different services
44+
45+
This solution can take some time to have your terms type to be approved, so if you need a faster solution, you can proceed with the following temporary solutions.
46+
47+
## Temporary solutions
48+
49+
### For proof of concept or development
50+
51+
As the validation is primarily intended for production environments to maintain consistency, if you're working on a proof of concept or development environment that won't be deployed to production, you can safely ignore these validation errors, the whole tracking process will still work.
52+
53+
### Using a forked version
54+
55+
If you need a faster solution for production use, you can fork the terms-types repository and add your custom type:
56+
57+
1. Fork the [terms-types repository](https://github.com/OpenTermsArchive/terms-types)
58+
2. Add your custom terms type to the `termsTypes.json` database file
59+
3. Update your collection's `package.json` to use your fork:
60+
61+
```json
62+
{
63+
"dependencies": {
64+
"@opentermsarchive/engine": "5.0.3",
65+
"@opentermsarchive/terms-types": "<your-organization-or-username>/terms-types#main"
66+
}
67+
}
68+
```
69+
70+
This solution is only recommended as a temporary solution, it is strongly recommended that you also submit the new terms type through the process describe in previous section. This way, you'll contribute to the community by helping maintain consistency across collections and enables better comparison of terms across different services, and also eventually stop maintaining a custom fork.

0 commit comments

Comments
 (0)