@opentermsarchive/engine 0.16.0 → 0.17.1

package/.github/workflows/test.yml

@@ -1,77 +0,0 @@
-name: Test
-
-on:
-  push:
-    branches-ignore:
-      - main # tests will be launched by workflow_call from the deploy workflow
-  pull_request:
-    types: [ opened, reopened ]
-  workflow_call:
-    outputs:
-      release_type:
-        description: "The release type extracted from changelog"
-        value: ${{ jobs.check_changelog.outputs.release_type }}
-
-jobs:
-  check_changelog:
-    runs-on: [ubuntu-latest]
-    outputs:
-      release_type: ${{ steps.set_release_type_output.outputs.release_type }}
-    steps:
-      - uses: actions/checkout@v2
-      - name: Get release type in changelog
-        run: echo "RELEASE_TYPE=$(cat CHANGELOG.md | grep -E '^## Unreleased \[(patch|minor|major)\]$' | grep -E -w -o "patch|minor|major" | tr -d '\n')" >> $GITHUB_ENV
-      - name: Make release type available to subsequent jobs
-        if: env.RELEASE_TYPE
-        id: set_release_type_output
-        run: |
-          echo "Found release type '${{ env.RELEASE_TYPE }}'"
-          echo "release_type=${{ env.RELEASE_TYPE }}" >> $GITHUB_OUTPUT
-      - name: Fail and display error if no proper release type is found in changelog
-        if: env.RELEASE_TYPE == ''
-        run: echo "No valid release type found in changelog. The title of the 'Unreleased' section must contain one of the following tags '[patch]', '[minor]', '[major]'. For example, '## Unreleased [minor]'."; exit 1
-
-
-  test:
-    strategy:
-      matrix:
-        operating_system: [ ubuntu-20.04, windows-latest, macos-latest ]
-      fail-fast: false # run tests on other operating systems even if one fails
-
-    runs-on: ${{ matrix.operating_system }}
-
-    steps:
-      - run: |
-          git config --global core.autocrlf false
-      - uses: actions/checkout@v2
-      - uses: ankane/setup-mongodb@ce30d9041565cb469945895d5bde3384a254dd2e # use commit ID until action is versioned, see https://github.com/ankane/setup-mongodb/issues/2
-        with:
-          mongodb-version: 5.0
-      - uses: actions/setup-node@v2
-        with:
-          node-version: 16
-      - run: npm ci
-      - run: npm test
-
-  validate_declarations:
-    strategy:
-      matrix:
-        operating_system: [ ubuntu-latest, windows-latest, macos-latest ]
-      fail-fast: false # run tests on other operating systems even if one fails
-
-    runs-on: ${{ matrix.operating_system }}
-
-    steps:
-      - run: |
-          git config --global core.autocrlf false
-      - uses: actions/checkout@v2
-      - uses: actions/checkout@v2
-        with:
-          repository: OpenTermsArchive/contrib-declarations
-          path: ./contrib-declarations
-      - uses: actions/setup-node@v2
-        with:
-          node-version: 16.x
-      - run: cd ./contrib-declarations && npm install
-      - run: npm ci
-      - run: ./node_modules/.bin/cross-env NODE_ENV=ci npm run declarations:validate:schema

package/CHANGELOG.md

@@ -1,14 +0,0 @@
-# Changelog
-
-All notable changes to this project will be documented in this file.
-
-This project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html) and the format is based on [Common Changelog](https://common-changelog.org).\
-Unlike Common Changelog, the `unreleased` section of [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) is preserved with the addition of a tag to specify which type of release should be published and to foster discussions about it inside pull requests. This tag should be one of the names mandated by SemVer, within brackets: `[patch]`, `[minor]` or `[major]`. For example: `## Unreleased [minor]`.
-
-## Unreleased
-
-## 0.16.0 - 2022-12-05
-### Added
-- Publish package on NPM under name `@opentermsarchive/engine`.
-- Export `filter`, `pageDeclaration` and `fetch` in NPM module.
-- Add changelog.

package/CODE_OF_CONDUCT.md

@@ -1,128 +0,0 @@
-# Contributor Covenant Code of Conduct
-
-## Our Pledge
-
-We as members, contributors, and leaders pledge to make participation in our
-community a harassment-free experience for everyone, regardless of age, body
-size, visible or invisible disability, ethnicity, sex characteristics, gender
-identity and expression, level of experience, education, socio-economic status,
-nationality, personal appearance, race, religion, or sexual identity
-and orientation.
-
-We pledge to act and interact in ways that contribute to an open, welcoming,
-diverse, inclusive, and healthy community.
-
-## Our Standards
-
-Examples of behavior that contributes to a positive environment for our
-community include:
-
-* Demonstrating empathy and kindness toward other people
-* Being respectful of differing opinions, viewpoints, and experiences
-* Giving and gracefully accepting constructive feedback
-* Accepting responsibility and apologizing to those affected by our mistakes,
-  and learning from the experience
-* Focusing on what is best not just for us as individuals, but for the
-  overall community
-
-Examples of unacceptable behavior include:
-
-* The use of sexualized language or imagery, and sexual attention or
-  advances of any kind
-* Trolling, insulting or derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or email
-  address, without their explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
-  professional setting
-
-## Enforcement Responsibilities
-
-Community leaders are responsible for clarifying and enforcing our standards of
-acceptable behavior and will take appropriate and fair corrective action in
-response to any behavior that they deem inappropriate, threatening, offensive,
-or harmful.
-
-Community leaders have the right and responsibility to remove, edit, or reject
-comments, commits, code, wiki edits, issues, and other contributions that are
-not aligned to this Code of Conduct, and will communicate reasons for moderation
-decisions when appropriate.
-
-## Scope
-
-This Code of Conduct applies within all community spaces, and also applies when
-an individual is officially representing the community in public spaces.
-Examples of representing our community include using an official e-mail address,
-posting via an official social media account, or acting as an appointed
-representative at an online or offline event.
-
-## Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported to the community leaders responsible for enforcement at
-moderators@opentermsarchive.org.
-All complaints will be reviewed and investigated promptly and fairly.
-
-All community leaders are obligated to respect the privacy and security of the
-reporter of any incident.
-
-## Enforcement Guidelines
-
-Community leaders will follow these Community Impact Guidelines in determining
-the consequences for any action they deem in violation of this Code of Conduct:
-
-### 1. Correction
-
-**Community Impact**: Use of inappropriate language or other behavior deemed
-unprofessional or unwelcome in the community.
-
-**Consequence**: A private, written warning from community leaders, providing
-clarity around the nature of the violation and an explanation of why the
-behavior was inappropriate. A public apology may be requested.
-
-### 2. Warning
-
-**Community Impact**: A violation through a single incident or series
-of actions.
-
-**Consequence**: A warning with consequences for continued behavior. No
-interaction with the people involved, including unsolicited interaction with
-those enforcing the Code of Conduct, for a specified period of time. This
-includes avoiding interactions in community spaces as well as external channels
-like social media. Violating these terms may lead to a temporary or
-permanent ban.
-
-### 3. Temporary Ban
-
-**Community Impact**: A serious violation of community standards, including
-sustained inappropriate behavior.
-
-**Consequence**: A temporary ban from any sort of interaction or public
-communication with the community for a specified period of time. No public or
-private interaction with the people involved, including unsolicited interaction
-with those enforcing the Code of Conduct, is allowed during this period.
-Violating these terms may lead to a permanent ban.
-
-### 4. Permanent Ban
-
-**Community Impact**: Demonstrating a pattern of violation of community
-standards, including sustained inappropriate behavior,  harassment of an
-individual, or aggression toward or disparagement of classes of individuals.
-
-**Consequence**: A permanent ban from any sort of public interaction within
-the community.
-
-## Attribution
-
-This Code of Conduct is adapted from the [Contributor Covenant][homepage],
-version 2.0, available at
-https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
-
-Community Impact Guidelines were inspired by [Mozilla's code of conduct
-enforcement ladder](https://github.com/mozilla/diversity).
-
-[homepage]: https://www.contributor-covenant.org
-
-For answers to common questions about this code of conduct, see the FAQ at
-https://www.contributor-covenant.org/faq. Translations are available at
-https://www.contributor-covenant.org/translations.

package/CONTRIBUTING.md

@@ -1,143 +0,0 @@
-First of all, thanks for taking the time to contribute! 🎉👍
-
-## Table of Contents
-
-- [Workflow](#workflow)
-  - [Pull requests](#pull-requests)
-  - [Commit messages](#commit-messages)
-  - [Continuous delivery](#continuous-delivery)
-  - [Changelog](#changelog)
-- [Development](#development)
-  - [Documentation](#documentation)
-- [Naming](#naming)
-  - [Instances and repositories](#instances-and-repositories)
-  - [Namespaces](#namespaces)
-- [Practices](#practices)
-  - [Errors handling](#errors-handling)
-
----
-
-## Workflow
-
-### Pull requests
-
-We follow the [GitHub Flow](https://guides.github.com/introduction/flow/): all code contributions are submitted via a pull request towards the `main` branch.
-
-Opening a pull request means you want that code to be merged. If you want to only discuss it, send a link to your branch along with your questions through whichever communication channel you prefer.
-
-#### Peer reviews
-
-All pull requests must be reviewed by at least one person who is not their original author.
-
-To help reviewers, make sure to describe your pull request with a **clear text explanation** of your changes.
-
-### Continuous delivery
-
-GitHub Actions is used to deploy the application on every merge to the main branch.
-
-Branch protection is active, meaning that a merge to the main branch can only take place once all tests pass in CI, and that the peer review policy has been fulfilled.
-
-### Commit messages
-
-We strive to follow this [recommendation](https://chris.beams.io/posts/git-commit) to write our commit messages, which contains the following rules:
-
-- [Separate subject from body with a blank line](https://chris.beams.io/posts/git-commit/#separate).
-- [Limit the subject line to 50 characters](https://chris.beams.io/posts/git-commit/#limit-50).
-- [Capitalize the subject line](https://chris.beams.io/posts/git-commit/#capitalize).
-- [Do not end the subject line with a period](https://chris.beams.io/posts/git-commit/#end).
-- [Use the imperative mood in the subject line](https://chris.beams.io/posts/git-commit/#imperative).
-- [Wrap the body at 72 characters](https://chris.beams.io/posts/git-commit/#wrap-72).
-- [Use the body to explain what and why vs. how](https://chris.beams.io/posts/git-commit/#why-not-how).
-
-We add this additional rule:
-
-- Do not rely on GitHub issue reference numbers in commit messages, as we have no guarantee the host system and its autolinking will be stable in time. Make sure the context is self-explanatory. If an external reference is given, use its full URL.
-
-### Changelog
-
-All changes to the codebase that impact users must be documented in the [`CHANGELOG.md`](./CHANGELOG.md) file. The format to use is documented in the file itself.
-
-## Development
-
-### Documentation
-
-#### CLI
-
-##### docopt
-
-For command-line examples and documentation, we follow the [docopt usage patterns](http://docopt.org) syntax. Quick recap of the main points:
-
-- mandatory arguments are given between `<` and `>`;
-- optional elements are given between `[` and `]`;
-- mutually exclusive elements are given between `(` and `)` and separated by `|`.
-
-```diff
-- npm start [ $service_id ] [, $service_id, ...]
-+ npm start [service_id]...
-```
-
-##### Long options
-
-In order to improve the understandability of commands, we document all CLI options and examples with the long version of the options.
-
-
-```diff
-- ansible-playbook -i production.yml app.yml -l france -t stop
-+ ansible-playbook --inventory production.yml app.yml --limit france --tag stop
-```
-
-## Naming
-
-### Instances and repositories
-
-An “instance” of Open Terms Archive is comprised of a server running Open Terms Archive and up to three repositories. An instance has a _name_ describing the scope of services it aims at tracking. This scope is defined by one or several dimensions: jurisdiction, language, industry…
-
-> For example, the `france` instance tracks documents in the French jurisdiction and French language, while the `dating` instance tracks services from the dating industry.
-
-The instance name is written in lowercase and is made of one word for each dimension it focuses on, separated by dashes.
-
-> For example, the `france-elections` instance tracks services in the French jurisdiction and French language that could impact the French electoral processes.
-
-This name is used consistently in all communication, written references, and in the inventory of instances that are managed automatically. It is also used as the base for naming the database repositories, by suffixing it with each type:
-
-- The repository containing the declarations of services to be tracked is named `$instance_name-declarations`. You can [create it from a template](https://github.com/OpenTermsArchive/template-declarations/generate).
-- The repository containing the snapshots of the tracked documents (unless the instance is storing them in an alternative database) is named `$instance_name-snapshots`. You can [create it from a template](https://github.com/OpenTermsArchive/template-snapshots/generate).
-- The repository containing the versions of the tracked documents (unless the instance is storing them in an alternative database) is named `$instance_name-versions`. You can [create it from a template](https://github.com/OpenTermsArchive/template-versions/generate).
-
-### Namespaces
-
-We deploy identifiers for packages and namespaces across different universes: package managers, social networks, URLs… In order to unify these names across constraints, we reserve everywhere the name `opentermsarchive`, with no space, no dash, no underscore, no capital.
-
-> For example, NPM does not allow uppercase and spaces; Ansible does not allow dashes and spaces; Twitter does not allow spaces. The name `ota` is too unlikely to be available everywhere.
-
-## Practices
-
-### Errors handling
-
-First of all it's important to distinguish two fundamentally different kinds of errors: **operational** and **programmer** errors.
-
-- **Operational errors represent run-time problems experienced by correctly-written programs**. These are not bugs in the program. These are usually problems with something else: the system itself (e.g. out of memory), the system’s configuration (e.g. no route to a remote host), the network (e.g. socket hang-up), or a remote service (e.g. a 500 error).
-
-- **Programmer errors are bugs in the program**. These are things that can always be avoided by changing the code. They can never be handled properly, since by definition the code in question is broken (e.g. tried to read property of `undefined`, or forget to `await` an asynchronous function).
-
-So the very important distinction is that operational errors are part of the **normal operation of a program** whereas programmer errors are **bugs**.
-
-Also noteworthy, failure to handle an operational error is itself a programmer error.
-
-#### Handling operational errors
-
-There are five ways to handle operational errors:
-- **Deal with the failure directly**. For example, create directory if it's missing.
-- **Propagate the failure**. If you don’t know how to deal with the error, the simplest thing to do is to abort whatever operation you’re trying to do, clean up whatever you’ve started, and propagate the error.
-- **Retry the operation**. For example, try to reconnect if the connection is lost.
-- **Log the error — and do nothing else**. If it's a minor error and there’s nothing you can do about, and there is no reason to stop the whole process.
-- **Crash immediately**. If the error cannot be handled and can affect data integrity.
-
-In our case, we consider all `fetch`-related errors as expected, so as operational errors and we handle them by logging but we do not stop the whole process. We handle errors related to the `notifier` in the same way.
-In contrast, we consider errors from the `recorder` module as fatal, and we crash immediately.
-
-#### Handling programmer errors
-
-**The best way to handle programmer errors is to crash immediately.** Indeed, it is not recommended to attempt to recover from programmer errors — that is, allow the current operation to fail, but keep handling requests. Consider that a programmer error is a case that you didn’t think about when you wrote the original code. How can you be sure that the problem won’t affect the program itself and the data integrity?
-
-This section is highly inspired, and in part extracted, from [this error handling guide](https://console.joyent.com/node-js/production/design/errors).

package/MIGRATING.md

@@ -1,42 +0,0 @@
-## 2022-03-29 Unify repository names
-
-All services declarations, snapshots and versions repo has been renamed and moved to the [OpenTermArchive organization](https://github.com/OpenTermsArchive) on github.
-
-Documentation on the new naming system can be found [here](https://github.com/ambanum/OpenTermsArchive/blob/main/CONTRIBUTING.md#instances-and-repositories-names)
-
-If you already have some of those projects locally, you can run
-
-```
-mv services-all contrib-declarations
-mv services-dating dating-declarations
-mv declarations-france-elections france-elections-declarations
-mv declarations-france france-elections
-mv declarations-france-elections-experiment france-elections-experiment-declarations
-```
-
-## 2021-11-25 Externalize services declarations
-
-Services declarations are now declared in their [own repository](https://github.com/OpenTermsArchive/services-all).
-
-In order to use all the defined services locally, you now have to clone that new repository in the parent folder of the OpenTermsArchive one:
-
-```
-    # From your local clone of the OpenTermsArchive repository
-    cd ..
-    git clone git@github.com:OpenTermsArchive/contrib-declarations.git
-```
-
-## 2021-02-24 Name change
-
-`CGUs` is now called `OpenTermsArchive`.
-
-To reflect this change, if you already have this project locally, execute:
-
-```
-    # From your local clone of the OpenTermsArchive repository
-    cd ..
-    mv CGUs OpenTermsArchive
-    cd OpenTermsArchive
-    git remote set-url origin https://github.com/ambanum/OpenTermsArchive.git
-```
-

package/README.fr.md

@@ -1,110 +0,0 @@
-<img src="https://disinfo.quaidorsay.fr/assets/img/logo.png" width="140">
-
-# Open Terms Archive
-
-Les services en ligne ont des conditions générales qui évoluent dans le temps. _Open Terms Archive_ permet aux défenseurs des droits des utilisateurs, aux régulateurs et à toute personne intéressée de suivre les évolutions de ces conditions générales en étant notifiée à chaque publication d'une nouvelle version, et en explorant leur historique.
-
-## Table des matières
-
-- [Fonctionnement](#fonctionnement)
-- [Naviguer dans l'historique des versions](#naviguer-dans-lhistorique-des-versions)
-  - [Remarques](#remarques)
-- [Recevoir des notifications](#recevoir-des-notifications)
-  - [Par courriel](#par-courriel)
-    - [Recevoir les mises à jour de services ou documents spécifiques](#recevoir-les-mises-%C3%A0-jour-de-services-ou-documents-sp%C3%A9cifiques)
-  - [Par RSS](#par-rss)
-    - [Récapitulatif des flux RSS disponibles](#r%C3%A9capitulatif-des-flux-rss-disponibles)
-  - [Désabonnement](#désabonnement)
-- [Contribuer](#contribuer)
-  - [Ajouter un nouveau service](#ajouter-un-nouveau-service)
-
-## Fonctionnement
-
-_Note: Les mots en gras sont les [termes du domaine](https://fr.wikipedia.org/wiki/Conception_pilot%C3%A9e_par_le_domaine)._
-
-Les **services** sont **déclarés** dans l'outil _Open Terms Archive_ grâce à un **fichier de déclaration** listant les **documents** qui forment l'ensemble des **conditions** régissant l'usage du **service**. Ces **documents** peuvent être de plusieurs **types** : « conditions d'utilisation », « politique de confidentialité », « contrat de développeur »…
-
-Afin de **suivre** leurs **évolutions**, les **documents** sont régulièrement mis à jour, en les **téléchargeant** depuis une **adresse** web et en **sélectionnant leur contenu** dans la **page web** pour supprimer le **bruit** (publicités, menus de navigation, champs de connexion…). En plus de simplement sélectionner une zone de la page, certains documents possèdent du **bruit** supplémentaire (hashs dans des liens, jetons CSRF...) créant de faux positifs en terme d'**évolutions**. En conséquence, _Open Terms Archive_ supporte des **filtres** spécifiques pour chaque **document**.
-
-Néanmoins, le **bruit** peut changer de forme avec le temps. Afin d'éviter des pertes d'information irrécupérables pendant l'étape de **filtrage du bruit**, un **instantané** de la page Web est **enregistré** à chaque **évolution**. Après avoir **filtré l'instantané** de son **bruit**, si le **document** résultant a changé par rapport à sa **version** précédente, une nouvelle **version** est **enregistrée**.
-
-Vous pouvez disposer de votre propre instance **privée** de l'outil _Open Terms Archive_ et suivre vous-même les **évolutions**. Néanmoins, nous **publions** chaque **version** sur une [instance **publique**](https://github.com/OpenTermsArchive/contrib-versions) facilitant l'exploration de l'**historique** et **notifiant** par courriels l'**enregistrement** de nouvelles **versions**. Les **utilisateurs** peuvent [**s'abonner** aux **notifications**](#recevoir-des-notifications).
-
-_Note: Actuellement, nous ne suivons que les **conditions** rédigées en anglais et concernant la juridiction européenne._
-
-## Naviguer dans l'historique des versions
-
-À partir de la **page d'accueil du dépôt** [contrib-versions](https://github.com/OpenTermsArchive/contrib-versions), ouvrez le dossier du **service de votre choix** (prenons par exemple [WhatsApp](https://github.com/OpenTermsArchive/contrib-versions/tree/main/WhatsApp)).
-
-L'**ensemble des documents suivis** pour ce service s'affichent, cliquez ensuite sur **celui dont vous souhaitez suivre l'historique** (par exemple la [politique d'utilisation des données de WhatsApp](https://github.com/OpenTermsArchive/contrib-versions/blob/main/WhatsApp/Privacy%20Policy.md)). Le document s'affiche alors dans sa **dernière version** (il est actualisé toutes les heures).
-
-Pour afficher l'**historique des modifications** subies par ce document, cliquez sur **History** en haut à droite du document (pour l'exemple précédent nous arrivons [ici](https://github.com/OpenTermsArchive/contrib-versions/commits/main/WhatsApp/Privacy%20Policy.md)). Les **modifications** sont affichées **par dates**, de la plus récente à la plus ancienne.
-
-Cliquez sur une modification pour voir en quoi elle consiste (par exemple [celle-ci](https://github.com/OpenTermsArchive/contrib-versions/commit/58a1d2ae4187a3260ac58f3f3c7dcd3aeacaebcd)). Vous disposez de **deux types d'affichage**, sélectionnables à partir des icônes dans la barre grisée qui chapeaute le document.
-
-- Le premier, appelé _source diff_ (bouton avec des chevrons) permet d'**afficher côte-à-côte l'ancienne version et la nouvelle** (pour notre [exemple](https://github.com/OpenTermsArchive/contrib-versions/commit/58a1d2ae4187a3260ac58f3f3c7dcd3aeacaebcd#diff-e8bdae8692561f60aeac9d27a55e84fc)). Cet affichage a le mérite de **montrer explicitement** l'ensemble des ajouts/suppressions.
-- Le second, appelé _rich diff_ (bouton avec l'icône document) permet d'**unifier l'ensemble des modifications sur un seul document** (pour notre [exemple](https://github.com/OpenTermsArchive/contrib-versions/commit/58a1d2ae4187a3260ac58f3f3c7dcd3aeacaebcd?short_path=e8bdae8#diff-e8bdae8692561f60aeac9d27a55e84fc)). La couleur **rouge** montre les éléments **supprimés**, la couleur **jaune** montre les paragraphes **modifiés**, et la couleur **verte** montrent les éléments **ajoutés**. Attention, cet affichage **ne montre pas certaines modifications** comme le changement des hyperliens et le style du texte.
-
-### Remarques
-
-- Pour les longs documents, les **paragraphes inchangés ne seront pas affichés par défaut**. Vous pouvez manuellement les faire apparaître en cliquant sur les petites flèches juste au-dessus ou juste en-dessous des paragraphes affichés.
-- Vous pouvez utiliser le bouton **History n'importe où** dans le dépôt contrib-versions, qui affichera alors l'**historique des modifications subies par tous les documents se trouvant dans le dossier** où vous vous trouvez (y compris dans les sous-dossiers).
-
-## Recevoir des notifications
-
-### Par courriel
-
-#### Pour tous les documents d'un coup
-
-Vous pouvez [vous abonner](https://59692a77.sibforms.com/serve/MUIEAKuTv3y67e27PkjAiw7UkHCn0qVrcD188cQb-ofHVBGpvdUWQ6EraZ5AIb6vJqz3L8LDvYhEzPb2SE6eGWP35zXrpwEFVJCpGuER9DKPBUrifKScpF_ENMqwE_OiOZ3FdCV2ra-TXQNxB2sTEL13Zj8HU7U0vbbeF7TnbFiW8gGbcOa5liqmMvw_rghnEB2htMQRCk6A3eyj) pour recevoir un courriel à chaque modification d'un document dans l'ensemble de la base.
-
-**Attention, vous risquez de recevoir de nombreuses notifications !** Vous pourrez vous désabonner en répondant à n'importe quel courriel reçu.
-
-#### Recevoir les mises à jour de services ou documents spécifiques
-
-Vous pouvez vous rendre sur le site officiel [opentermsarchive.org] (https://opentermsarchive.org). De là, vous pouvez sélectionner un service, puis le type de document correspondant.
-Après avoir entré votre adresse électronique et cliqué sur "S'inscrire", nous ajouterons votre adresse à la liste de diffusion correspondante dans [SendInBlue](https://www.sendinblue.com/) et nous ne la conserverons nulle part ailleurs.
-Ensuite, chaque fois qu'une modification sera trouvée sur le document correspondant, nous vous enverrons un e-mail.
-
-Vous pouvez vous désinscrire à tout moment en cliquant sur le lien "désinscription" en bas de l'email reçu.
-
-### Par RSS
-
-Vous pouvez recevoir une notification pour un service ou un document spécifique en vous abonnant à des flux RSS.
-
-> Un flux RSS est un type de page accessible en ligne qui contient des informations sur les derniers contenus publiés par un site web comme leur date de publication et l'adresse pour les consulter. Lorsque cette ressource est mise à jour, une application de type lecteur de flux vous notifie automatiquement et vous pouvez ainsi consulter la mise à jour.
-
-Pour obtenir l'adresse du flux RSS auquel vous abonner :
-
-1. [Naviguez](#naviguer-dans-lhistorique-des-versions) jusqu’à la page qui présente l’historique des modifications qui vous intéressent. _Dans l'exemple de WhatsApp donné plus haut, il s’agit de [cette page](https://github.com/OpenTermsArchive/contrib-versions/commits/main/WhatsApp/Privacy%20Policy.md)._
-2. Copiez l’adresse de cette page depuis la barre d’adresse de votre navigateur. _Dans l’exemple de WhatsApp, il s’agit de `https://github.com/OpenTermsArchive/contrib-versions/commits/main/WhatsApp/Privacy%20Policy.md`._
-3. Ajoutez `.atom` à la fin de cette adresse. _Dans l’exemple de WhatsApp, cela donnerait `https://github.com/OpenTermsArchive/contrib-versions/commits/main/WhatsApp/Privacy%20Policy.md.atom`._
-4. Abonnez votre lecteur de flux RSS à l’adresse résultante.
-
-#### Récapitulatif des flux RSS disponibles
-
-| Mis à jour pour                       | URL                                                                                                                                                                                                        |
-| ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| l'ensemble des services et documents  | `https://github.com/OpenTermsArchive/contrib-versions/commits.atom`                                                                                                                                        |
-| l'ensemble des documents d'un service | Remplacer `$serviceId` par l'identifiant du service :<br>`https://github.com/OpenTermsArchive/contrib-versions/commits/main/$serviceId.atom`                                                             |
-| un document spécifique d'un service   | Remplacer `$serviceId` par l'identifiant du service et `$documentType` par le type du document :<br>`https://github.com/OpenTermsArchive/contrib-versions/commits/main/$serviceId/$documentType.md.atom` |
-
-Par exemple :
-
-- Pour recevoir toutes les mises à jour des documents de `Facebook`, abonnez-vous à `https://github.com/OpenTermsArchive/contrib-versions/commits/main/Facebook.atom`.
-- Pour recevoir toutes les mises à jour des `Privacy Policy` de `Google`, abonnez-vous à `https://github.com/OpenTermsArchive/contrib-versions/commits/main/Google/Privacy%20Policy.md.atom`.
-
-### Désabonnement
-
-Afin de ne plus recevoir d'e-mails de mise à jour des services, deux liens sont inclus dans chaque e-mail reçu :
-
-- un pour ne plus recevoir tous les e-mails de bot@opentermsarchive.org
-- un pour ne plus recevoir les e-mails d'un document particulier
-
-Ce dernier lien consiste à envoyer un courriel à contact@opentermsarchive.org pour être retiré manuellement de la liste correspondante.
-
-## Contribuer
-
-### Ajouter un nouveau service
-
-Voir le fichier [CONTRIBUTING](CONTRIBUTING.md) (en anglais).

package/Vagrantfile

@@ -1,38 +0,0 @@
-# -*- mode: ruby -*-
-# vi: set ft=ruby :
-
-Vagrant.configure("2") do |config|
-  config.vm.hostname = "vagrant"
-
-  config.vm.box = "debian/bullseye64" # Unable to locate package mongodb-org
-
-  # in order to have the same config for both Docker and VirtualBox providers, we load the key manually
-  # if necessary, create the key with `ssh-keygen -f ~/.ssh/ota-vagrant -q -N ""`
-  # CAUTION: use of `~` in path causes problems with ssh
-  config.vm.provision "file", source: File.join(ENV['HOME'], ".ssh", "ota-vagrant.pub"), destination: "/home/vagrant/.ssh/authorized_keys"
-
-  # based on https://github.com/rofrano/vagrant-docker-provider#example-vagrantfile
-  config.vm.provider :docker do |docker, override|
-    override.vm.box = nil
-    docker.image = "rofrano/vagrant-provider:debian"
-    docker.remains_running = true
-    docker.has_ssh = true
-    docker.privileged = true
-    docker.volumes = ["/sys/fs/cgroup:/sys/fs/cgroup:rw"]
-    docker.create_args = ["--cgroupns=host"]
-
-    # python is not installed by default in the vagrant-provider image
-    # and deploying results in  /bin/sh: 1: /usr/bin/python: not found
-    # use a provision to fix that
-    # only with debian, no need with ubuntu
-    # Also need to name the provisioner, so that it runs only once https://github.com/hashicorp/vagrant/issues/7685#issuecomment-308281283
-    config.vm.provision "install_python3", type: "shell", inline: $installPython3
-  end
-end
-
-$installPython3 = <<-SCRIPT
-echo Updating apt...
-sudo apt-get update --fix-missing # Needed to fix "No package matching 'chromium' is available"
-echo Installing python...
-sudo apt-get --assume-yes install python3 python3-pip
-SCRIPT

package/ansible.cfg

@@ -1,13 +0,0 @@
-[defaults]
-
-inventory = ops/inventories/dev.yml
-roles_path = ops/roles
-
-
-# The two following lines allow to have human readable output
-# Use the YAML callback plugin.
-stdout_callback = yaml
-# Use the stdout_callback when running ad-hoc commands.
-bin_ansible_callbacks = true
-
-vault_password_file = vault.key

package/decision-records/0001-service-name-and-id.md

@@ -1,73 +0,0 @@
-# Choosing service name and service ID
-
-- Date: 2020-10-14
-
-## Context and Problem Statement
-
-To scale up from 50 to 5,000 services, we need a clear way for choosing the service name and the service ID.
-
-### We need
-
-A name that reflects the common name used by the provider itself, to be exposed in a GUI. This name is currently exposed as the name property in the service declaration.
-An ID of sorts that can be represented in the filesystem. This ID is currently exposed as the filename of the service declaration, without the .json extension.
-
-### Use cases
-
-The service name is presented to end users. It should reflect as closely as possible the official service name, so that it can be identified easily.
-The ID is used internally and exposed for analysis. It should be easy to handle with scripts and other tools.
-
-### Constraints for the ID
-
-As long as this ID is stored in the filesystem:
-
-- No `/` for UNIX.
-- No `\` for Windows.
-- No `:` for APFS and HFS.
-- No case-sensitive duplicates to support case-insensitive filesystems.
-- No more than 255 characters to support transfer over [FAT32](https://en.wikipedia.org/wiki/File_Allocation_Table#FAT32).
-
-UTF, spaces and capitals are all supported, even on case-insensitive filesystems.
-
-### However
-
-- UTF in filenames can be [a (fixable) problem with Git and HFS+](https://stackoverflow.com/questions/5581857/git-and-the-umlaut-problem-on-mac-os-x).
-- UTF in filenames is by default quoted in Git, leading for example `été.txt` to be displayed as `"\303\251t\303\251.txt"`.
-- Most online services align their brand name with their domain name. Even though UTF is now officially supported in domain names, support is limited and most services, even non-Western, have an official ASCII transliteration used at least in their domain name (e.g. “qq” by Tencent, “rzd.ru” for “РЖД”, “yahoo” for “Yahoo!”).
-- We currently use GitHub as a GUI, so the service ID is presented to the user instead of the service name. The name is used in email notifications.
-
-## Decision Outcome
-
-1. The service name should be the one used by the service itself, no matter the alphabet.
-
-- _Example: `туту.ру`_.
-
-2. We don't support non-ASCII characters in service IDs, at least as long as the database is Git and the filesystem, in order to minimise risk. Service IDs are derived from the service name through normalization into ASCII.
-
-- _Example: `туту.ру` → `tutu.ru`_.
-- _Example: `historielærer.dk` → `historielaerer.dk`_.
-- _Example: `RTÉ` → `RTE`_.
-
-3. We support punctuation, except characters that have meaning at filesystem level (`:`, `/`, `\`). These are replaced with a dash (`-`).
-
-- _Example: `Yahoo!` → `Yahoo!`_.
-- _Example: `Last.fm` → `Last.fm`_.
-- _Example: `re:start` → `re-start`_.
-- _Example: `we://` → `we---`_.
-
-4. We support capitals. Casing is expected to reflect the official service name casing.
-
-- _Example: `hi5` → `hi5`_.
-- _Example: `DeviantArt` → `DeviantArt`_.
-- _Example: `LINE` → `LINE`_.
-
-5. We support spaces. Spaces are expected to reflect the official service name spacing.
-
-- _Example: `App Store` → `App Store`_.
-- _Example: `DeviantArt` → `DeviantArt`_.
-
-6. We prefix the service name by the provider name when self-references are ambiguous, separated by a space. For example, Facebook refers to their Self-serve Ads service simply as “Ads”, which we cannot use in a shared database. We thus call the service “Facebook Ads”.
-
-- _Example: `Ads` (by Facebook) → `Facebook Ads`_.
-- _Example: `Analytics` (by Google) → `Google Analytics`_.
-- _Example: `Firebase` (by Google) → `Firebase`_.
-- _Example: `App Store` (by Apple) → `App Store`_.