lastochka-messenger/CONTRIBUTING.md

Участие в проекте «Ласточка»

Принципы

Честность

Мы не приукрашиваем статус проекта и не обещаем того, чего нет. Если компонент в статусе «stub» — мы так и пишем. Если E2E-шифрование не реализовано — мы говорим об этом прямо, а не маскируем маркетингом. От контрибьюторов мы ожидаем того же: если задача сложнее, чем казалась, или решение не работает — скажите сразу. Скрытые проблемы убивают проекты быстрее, чем плохой код.

Открытость

Все решения, обсуждения и дорожная карта публичны. Никаких закрытых встреч для «избранных». Код доступен, документация доступна, задачи доступны. Если у вас есть идея — создайте issue. Если хотите предложить другой подход — создайте PR или начните обсуждение. Мы не требуем согласия со всем, что решено до вас — мы требуем аргументации своей позиции.

Уважение

Мы работаем с людьми, а не с тикетами. Код ревью — это диалог, а не экзамен. Критика направлена на код, а не на автора. «Я не согласен с этим подходом, потому что...» — нормально. «Это плохой код» — нет.

Право на ошибку

Все приходят в проект с разным опытом. Если ваш PR отклонили — это не приговор, это объяснение, почему именно так. Если вы не знаете, как подойти к задаче — спросите. Глупых вопросов нет, есть вопросы, которые никто не задал вовремя.

---

Организация работы

Задачи

Все задачи ведутся через GitHub Issues. Каждая задача:

• Имеет понятное описание что нужно сделать и зачем
• Помечена приоритетом: P0 (критический), P1 (важный), P2 (обычный), P3 (можно подождать)
• Помечена меткой компонента: backend, web, android, ios, compliance, infra, docs

Если задача кажется размытой — уточняйте в комментариях. Не начинайте работу, пока не поняли, что именно нужно делать.

Ветвление

• main — стабильная ветка, production-ready код
• develop — интеграционная ветка, сюда мержатся фичи
• feature/название — ваша ветка для работы (создавайте от develop)
• fix/название — ветка для багфиксов

Pull Request

1. Создайте ветку от develop
2. Пишите осмысленные коммиты: feat: добавить reply-панель в чат, а не update
3. Перед PR убедитесь, что код компилируется и тесты проходят
4. В описании PR: что сделано, почему так, какие тесты прошли, скриншоты (для UI)
5. Один PR = одна задача. Не мешайте фичу, рефакторинг и фикс в одну кучу

Code Review

• Каждый PR проходит ревью хотя бы одним контрибьютором
• Ревью — это не «одобрю/отклоню», это «вот здесь проблема, потому что...»
• Автор PR отвечает на комментарии, вносит правки или аргументированно объясняет, почему оставил как есть
• Финальное решение по спорным вопросам — за мейнтейнером, но это крайняя мера

---

Коммуникация

Где общаемся

• GitHub Issues — конкретные задачи, баг-репорты, фич-реквесты
• GitHub Discussions — общие вопросы, идеи, обсуждения архитектуры
• Telegram-чат — оперативная коммуникация, вопросы «как тут у вас всё устроено»
• Документация — всё, что должно быть зафиксировано, пишем в docs/ и instructions/

Правило: если обсуждение привело к решению — зафиксируйте его в документации. Telegram-чат не является источником истины.

Как принимать решения

1. Малые решения (стиль кода, мелкий рефакторинг, уточнение документации) — принимает тот, кто работает над задачей
2. Средние решения (выбор библиотеки, изменение UI-паттерна, добавление нового экрана) — обсуждаются в Discussions или PR, решение принимается с учётом мнений контрибьюторов
3. Крупные решения (изменение архитектуры, смена технологии, новый компонент) — обсуждаются публично, решение документируется в docs/ARCHITECTURE.md или отдельном ADR (Architecture Decision Record)

---

Финансирование

Текущее состояние

Проект финансируется из личных средств основателя. Это значит:

• Все серверы (VPS, домены, SSL) оплачиваются лично
• Нет бюджета на оплату труда контрибьюторов
• Нет бюджета на маркетинг, дизайн-заказы, внешние подрядчиков

Мы это не скрываем и не создаём иллюзий.

Планы

После достижения MVP и проверки гипотезы (есть ли спрос) планируется подача на грантовую поддержку:

• Гранты на open-source проекты (Фонд содействия инновациям, IT-гранты)
• Возможно — краудфандинг, если будет востребованность от сообщества

Если грант получен — будет публичная отчётность о расходовании средств.

Что это значит для контрибьюторов

На текущий момент участие — волонтёрство. Вы вкладываете время и опыт в проект, который:

• Открытый — ваш код будет виден всем
• Реальный — это не pet-project, это production-сервис с живыми пользователями
• Портфолио — вы можете указывать это в резюме и показывать код на собеседованиях

Мы не просим работать бесплатно «вечно». Мы просим помочь дойти до точки, где проект сможет привлечь внешнее финансирование.

---

Роли в проекте

Контрибьютор

Любой, кто сделал PR и он был смержен. Даёт право:

• Упоминание в списке контрибьюторов
• Право создавать ветки в репозитории
• Право ревьюить чужие PR

Мейнтейнер

Человек, который принимает решения по направлению (backend, web, android, infra). Обязанности:

• Ревью PR в своём направлении
• Приоритизация задач
• Разрешение технических споров
• Поддержание качества кода

Мейнтейнер — не начальник, а ответственный. Он не раздаёт задачи, а координирует.

Основатель

Задаёт общее направление, принимает финальные решения по архитектуре, занимается инфраструктурой и финансированием.

---

С чего начать

1. Прочитайте PROJECT_CONTEXT.md — общее понимание проекта
2. Прочитайте PLAN.md — дорожная карта и приоритеты
3. Посмотрите открытые Issues — выберите задачу по силам
4. Напишите в комментарии к задаче: «Беру в работу» — чтобы не дублировать
5. Если подходящей задачи нет — создайте Discussion с предложением

---

Лицензии

Компонент	Лицензия
lastochka-server (форк Tinode)	GPL v3
compliance (наш сервис)	TBD (отдельная лицензия, не GPL)
lastochka-ui (Web)	TBD
lastochka-android (Android)	TBD
Документация	CC BY-SA 4.0

Лицензии для клиентских компонентов будут определены до начала активной работы контрибьюторов. Если у вас есть мнение по этому вопросу — welcome в Discussions.