2. Руководство по SEP
Что такое SEP
SEP (Specification Enhancement Proposal) — это формальный процесс подачи предложений по изменению спецификации iFay. Любое существенное изменение спецификации iFay — будь то добавление нового модуля, изменение поведения протокола или корректировка модели данных iFay Profile — должно проходить через процесс SEP.
Зачем нужны SEP
iFay — это экосистема открытых стандартов с реализациями от множества поставщиков, и каждое изменение спецификации может потенциально затронуть всех разработчиков реализаций. Процесс SEP обеспечивает упорядоченное, прозрачное и отслеживаемое развитие спецификации, предоставляя всем заинтересованным сторонам возможность участвовать в обсуждении и рецензировании.
Жизненный цикл SEP
SEP проходит следующие этапы от предложения до окончательной реализации:
1. Draft (Черновик)
Автор предложения создаёт Issue SEP на GitHub, используя стандартный шаблон, описывая мотивацию, предлагаемое решение и влияние. SEP на этапе Draft может быть неполным, но должен содержать достаточно информации, чтобы сообщество могло понять намерение предложения.
2. Discussion (Обсуждение)
SEP вступает в период публичного обсуждения продолжительностью не менее 14 дней. В течение этого периода:
- Члены сообщества и соответствующие рабочие группы обсуждают предложение
- Автор предложения дорабатывает и совершенствует предложение на основе обратной связи
- Мейнтейнеры связанных подпроектов оценивают влияние предложения на свои домены
3. Review (Рецензирование)
После окончания периода обсуждения Core Maintainers проводят формальное рецензирование SEP. В ходе рецензирования автору предложения может быть предложено внести дополнительные правки или дополнения, например:
- Добавить анализ обратной совместимости
- Завершить оценку влияния на тесты iFACTS
- Предоставить сравнительный анализ альтернативных подходов
4. Accepted / Rejected (Принято / Отклонено)
Core Maintainers определяют окончательный результат SEP путём голосования:
- Accepted (Принято): SEP утверждается и переходит на этап реализации
- Rejected (Отклонено): SEP отклоняется с указанием причин. Автор предложения может доработать и повторно подать предложение на основе обратной связи
5. Implemented (Реализовано)
Принятый SEP переходит на этап реализации. Работу по реализации может выполнять автор предложения или другие участники. В ходе реализации:
- Необходимо обновить соответствующие документы спецификации
- Необходимо реализовать эталонный код (при необходимости)
- Необходимо написать или обновить тестовые случаи iFACTS
6. Final (Финальный)
После завершения реализации и прохождения рецензирования SEP переходит в финальное состояние. На этом этапе:
- Документы спецификации обновлены
- Набор тестов iFACTS соответственно обновлён
- Связанная документация и руководства обновлены
Шаблон SEP
При подаче SEP, пожалуйста, включите следующее:
- Заголовок: Краткое описание предложения
- Мотивация: Зачем нужно это изменение? Какую проблему оно решает?
- Детальный дизайн: Технические подробности и план реализации предложения
- Обратная совместимость: Анализ влияния на существующие спецификации и реализации
- Влияние на iFACTS: Какие тесты на соответствие необходимо добавить или изменить
- Альтернативы: Другие рассмотренные подходы и их сравнительные преимущества и недостатки
Кто может подать SEP
Любой человек может подать SEP. Независимо от того, являетесь ли вы Core Maintainer, мейнтейнером, участником или пользователем экосистемы iFay, если вы считаете, что спецификация нуждается в улучшении, мы приглашаем вас подать предложение.
Особые замечания
SEP, затрагивающие изменения протоколов, требуют особого внимания: поскольку каждый протокол iFay (Faying, Telepathy, ICP, CAP, DTP, SSP) соответствует независимому подпроекту, мейнтейнеры соответствующих протоколов должны участвовать в рецензировании. Например, SEP, изменяющий поведение Control Authority Protocol (CAP), требует, чтобы мейнтейнеры рабочей группы WG-Protocols оценили его влияние на связанные модули, такие как Device Driver Hub и среда выполнения FayGer.
