Skip to content

contributing.md

Latest commit

 

History

History
144 lines (98 loc) · 6.43 KB

contributing.md

File metadata and controls

144 lines (98 loc) · 6.43 KB
Raw

Contributing Guide — Accellens

Версия: 1.0 Дата: 10 ноября 2025

1. Как начать

  1. Откройте issue или задачу в планировании.
  2. Создайте ветку от develop (feature/<scope>, fix/<issue>).
  3. Убедитесь, что локально проходят lint и test перед PR.

2. Требования к Pull Request

  • ⚠️ Язык: PR title и description должны быть на английском языке. См. Language Requirements.
  • Заполните PR template (описание изменений, чеклист тестов, влияние на документацию).
  • Добавьте ссылки на связанные issues/roadmap.
  • Приложите скриншоты/видео для UI изменений (desktop + mobile, включите accessibility overlay, если релевантно).
  • Минимум один reviewer из команды + accessibility specialist для изменений правил/симуляции.
  • Обновите документацию (docs/) при изменении API/архитектуры/процессов.
  • Зафиксируйте изменения в CHANGELOG.md и, при архитектурных решениях, инициируйте RFC (см. раздел 11).

3. Code Review Checklist

  • Соответствие SOLID/KISS/DRY.
  • Строгая типизация (Python/TypeScript).
  • Нет временных заглушек или закомментированного кода.
  • Unit/Integration тесты добавлены/обновлены.
  • Проверены сценарии деградации (fallback, error handling).
  • Обновлены feature флаги и конфиги, если требуется.

4. Стандарты коммитов

  • Conventional Commits (feat:, fix:, docs:, refactor:, test:, build:, ci:, chore:).
  • Коммиты атомарные; всё что не входит в scope — в отдельную ветку.
  • Не пушить сгенерированные файлы (кроме lock/manifest если нужно).

5. Style Guides

  • Python — см. coding-standards.md.
  • TypeScript/React — ESLint + Prettier, Storybook на каждый публичный компонент.
  • Документация — Markdown lint (markdownlint-cli2), соблюдение структуры.

6. Branching & Releases

  • develop — основная ветка разработки.
  • main — staging.
  • Release ветки release/x.y.z, теги vX.Y.Z.
  • Hotfix: ветка от main, после merge cherry-pick в develop.

7. Issue Labels

  • type:feature, type:bug, type:docs, type:refactor.
  • area:backend, area:frontend, area:scanners, area:ai, area:ops.
  • priority:p0/p1/p2.
  • status:blocked, status:needs-review, status:ready.

8. Communication

  • Slack канал #accellens-dev — оперативные вопросы.
  • Аудио/видео демо — по пятницам.
  • Для значимых изменений архитектуры/процессов используйте RFC (см. раздел 11).
  • При принятии решения оформляйте итог в документации и CHANGELOG.md.

9. Security & Privacy

  • Не копируйте пользовательские данные в репозиторий.
  • Проверяйте YAML/JSON на наличие секретов перед push.
  • Сообщайте о security issues в приватный канал/электронную почту security team (security@accellens.dev).

10. Благодарности

  • Каждое значимое улучшение фиксируется в CHANGELOG.md.
  • Авторство указывается в релиз-нотах.

11. RFC Process

11.1 Назначение

RFC (Request for Comments) фиксируют крупные продуктовые, архитектурные и процессные решения до их реализации. Цель — получить обратную связь, прозрачно задокументировать контекст и принять согласованное решение.

11.2 Когда требуется

  • Изменения, влияющие на архитектуру, инфраструктуру, безопасность или compliance.
  • Выбор/отказ от ключевых технологий, платформ, внешних сервисов.
  • Крупные продуктовые инициативы (MVP+, влияющие на roadmap и метрики).
  • Изменения, требующие координации нескольких команд или долгосрочной поддержки.

11.3 Структура

Файл размещается в docs/rfc/ (создайте директорию, если отсутствует) с именем YYYY-MM-DD-short-title.md.

Рекомендуемый шаблон:

# RFC: <Название>

- **Автор(ы)**:
- **Дата**:
- **Статус**: Draft / In review / Approved / Rejected

## 1. Краткое описание
## 2. Контекст и проблема
## 3. Предлагаемое решение
## 4. Альтернативы
## 5. Влияние (инженерное, продуктовое, риски)
## 6. План внедрения и миграции
## 7. Открытые вопросы

11.4 Процесс

  1. Создайте черновик RFC и откройте PR с меткой type:docs, area:architecture (или подходящей).
  2. Оповестите заинтересованные команды (backend, frontend, AI, ops, product, accessibility).
  3. Соберите review и согласование; финальный статус — Approved или Rejected.
  4. Зафиксируйте решение в CHANGELOG.md и обновите связанные документы (architecture, developer guide, roadmap и т.д.).

История изменений RFC и коммуникацию по ним ведём в том же PR/issue.