Contributing

GetOLT — коммерческий продукт с моделью «open-with-access»: код открыт для тех, кто получил доступ к репозиторию, защита от несанкционированной коммерческой эксплуатации — на стороне LicenseGuard. Внешние патчи приветствуются, но проходят через ручное ревью основателя, и для каждого PR ожидается предварительное обсуждение в @getolt_pub или на support@getolt.online.

Как сообщить о баге

Самый быстрый канал — Telegram @getolt_pub: можно скинуть скриншот, прикрепить логи, получить ответ в этот же день.

Если нужен более подробный репорт, напишите на support@getolt.online с описанием:

1. Версия GetOLT — нижняя плашка интерфейса или cat /opt/getolt/.env | grep VERSION.
2. Канал инсталляции — Docker compose или bare-metal (см. Production-deploy).
3. Шаги воспроизведения — что нажимали, что ожидали увидеть, что увидели.
4. Логи — /opt/getolt/logs/application.log за интересующий период (sanitize пароли и ключи перед отправкой).
5. Скриншот ошибки в UI, если применимо.

Чем точнее воспроизведение, тем быстрее фикс.

Как предложить функцию

Telegram, email, или в форме контактов на главной странице сайта. Для GetOLT действует Validation-First — функции добавляются под подтверждённый клиентский запрос, а не «потому что было бы круто». Поэтому будет полезен контекст: какая боль, у скольких ваших коллег она проявляется, какой сценарий вы видите.

Подача патчей

Если хотите подать патч — сначала откройте обсуждение в одном из контактов выше. Это сэкономит время с обеих сторон: иногда нужная функция уже в работе, иногда подход в спорной области требует согласования.

После согласования:

1. Ветка от main. Назовите осмысленно: feat/snmp-discovery, fix/gateray-2020-banner-parse.
2. Атомарные коммиты: один коммит — одно логическое изменение.
3. Сообщения коммитов — на русском. Без AI-подписей (🤖 Generated with Claude, Co-Authored-By: Claude и т.п. блокируются commit-msg хуком). Префиксы: feat(модуль):, fix(модуль):, docs(тема):, test(модуль):.
4. Тесты обязательны на новый код. Для багфиксов — regression-тест, который без фикса падает, а с фиксом проходит.
5. mvn verify -P integration должен проходить локально перед PR.

Code style

• Стандартный Java — mvn compile без warning’ов, никакого @SuppressWarnings("null") ради тишины.
• Lombok-аннотации (@Getter, @Builder, @RequiredArgsConstructor) используются широко — продолжайте в том же духе.
• Имена методов и переменных — на английском. Комментарии — допустим русский, если объясняют почему, а не что (имена должны говорить «что» сами).
• Не вводить новые тяжёлые зависимости (Spring Cloud, Reactive, ORM-обёртки) без обсуждения — стек намеренно минималистичный.

Тестовая стратегия

• Unit-тесты — на каждый новый сервис и парсер vendor-адаптера.
• Интеграционные тесты — на путь «реальный MySQL + Spring context». Запуск: mvn verify -P integration.
• HTTP-моки — только Mockito.mock() клиента, не WireMock. Подробности — в Структуре проекта → Тесты.
• Тесты UI — Playwright (на стороне getolt-landing, для основного продукта пока вручную).

Документация

Если ваш патч меняет публичное поведение — обновите соответствующую страницу в getolt-landing/src/content/docs/. PR без обновлённой документации возвращается на доработку.

---

Спасибо, что хотите внести вклад. Любые вопросы — в @getolt_pub или на support@getolt.online.