Доступ, роли и ревью

Проблема: у экспериментов не должно быть «владельца в вакууме». Если команда запускает рискованное изменение, должно быть понятно, кто обязан проверить и кто несёт ответственность за допуск к запуску.

0.1 Цель

Платформой пользуются разные типы пользователей:

• одни создают и ведут эксперименты,
• другие проверяют и одобряют перед запуском,
• третьи смотрят результаты,
• и есть те, кто администрирует правила и доступы.

Система должна обеспечивать контроль доступа и обязательность ревью там, где это требуется. Здесь ревью — это проверка эксперимента перед запуском с итогом «одобрено» или «отклонено».

0.2 Роли и права

Admin

• Управляет пользователями: создание, изменение, назначение ролей.
• Настраивает правила ревью (согласования перед запуском): кто может одобрять и сколько одобрений требуется.

Experimenter

• Создаёт и ведёт эксперименты.
• Отправляет эксперименты на ревью и получает решение ревьюеров (одобрение или отклонение), при необходимости — комментарии и причины.

Approver

• Ревьюит эксперименты.
• Может одобрять/отклонять в рамках своих полномочий.

Viewer

• Доступ только на чтение: без создания, ревью и администрирования.

0.3 Аппрувер‑группы

Для каждого Experimenter система должна позволять настраивать:

• список Approver’ов, которые могут одобрять его эксперименты;
• минимальный порог одобрений — сколько аппруверов должно одобрить эксперимент до запуска.

Сценарий без явно заданной аппрувер‑группы

Проблема: если для Experimenter не задана аппрувер‑группа, процесс ревью становится неоднозначным и может блокировать запуск эксперимента.

Требование: в таком сценарии система должна иметь однозначное и воспроизводимое fallback-поведение:

• кто может одобрять эксперимент;
• какой минимальный порог одобрений используется.

Граница свободы: конкретная модель fallback определяется участником, но должна быть явно описана в документации и подтверждаться на проверке.