Skip to content

CONTRIBUTING.ru-RU.md

Latest commit

 

History

History
224 lines (155 loc) · 13.7 KB

CONTRIBUTING.ru-RU.md

File metadata and controls

224 lines (155 loc) · 13.7 KB
Raw

Участие в разработке OpenCodeReview

Спасибо за интерес к развитию OpenCodeReview! Важен любой вклад — будь то исправленная опечатка, сообщение о баге или новая функциональность.

English | 简体中文版 | 日本語版 | 한국어 | Русский

Кодекс поведения

Участвуя в этом проекте, вы соглашаетесь поддерживать уважительную и инклюзивную атмосферу. Пожалуйста, будьте доброжелательны и конструктивны в любом взаимодействии.

Как можно помочь

Помимо написания кода, есть много способов внести вклад:

  • Сообщайте о багах — нашли поломку? Заведите issue с шагами воспроизведения.
  • Предлагайте улучшения — есть идея? Начните обсуждение в GitHub Discussions или заведите issue Feature Request.
  • Улучшайте документацию — исправляйте опечатки, проясняйте формулировки, добавляйте примеры. Чтобы сообщить о проблеме, можно также завести Documentation Issue.
  • Ревьюйте pull request'ы — помогайте нам проверять код других контрибьюторов.
  • Пишите код — исправляйте баги, добавляйте функциональность, улучшайте производительность.

С чего начать

Требования

Настройка

# 1. Сделайте форк репозитория на GitHub

# 2. Склонируйте свой форк
git clone https://github.com/<your-username>/open-code-review.git
cd open-code-review

# 3. Добавьте remote upstream (для синхронизации с основным репозиторием)
git remote add upstream https://github.com/alibaba/open-code-review.git

# 4. Соберите проект
make build

# 5. Запустите тесты
make test

Если всё прошло успешно — вы готовы контрибьютить.

Примечание: remote upstream для контрибьюторов доступен только на чтение — он используется, чтобы подтягивать свежие изменения из основного репозитория. Пушить напрямую в upstream нельзя. Все изменения отправляются в ваш форк (origin) и подаются через Pull Request.

Процесс разработки

Ветки

Создайте feature-ветку от main:

git checkout main
git pull upstream main
git checkout -b feat/your-feature-name

Используйте префиксы, обозначающие тип изменения:

Префикс Назначение
feat/ Новая функциональность
fix/ Исправление бага
docs/ Только документация
refactor/ Рефакторинг (без изменения поведения)
test/ Добавление или обновление тестов
chore/ Сборка, CI или инструментарий

Сообщения коммитов

Следуйте формату Conventional Commits:

<type>(<scope>): <краткое описание>

[необязательное тело]

Примеры:

feat(agent): add support for custom tool definitions
fix(llm): handle timeout errors in Anthropic API calls
docs(README): update configuration examples

Качество кода

Перед отправкой изменений убедитесь, что они проходят все проверки:

# Форматирование и линт (стандартный инструментарий Go)
go fmt ./...
go vet ./...

# Тесты с детектором гонок
make test

# Успешная сборка
make build

Структура проекта

├── cmd/opencodereview/   # Точка входа CLI
├── internal/
│   ├── agent/            # Логика ревью-агента
│   ├── config/           # Управление конфигурацией
│   ├── diff/             # Разбор git-диффов
│   ├── llm/              # Клиент LLM API (Anthropic и OpenAI)
│   ├── model/            # Модели данных
│   ├── session/          # Управление сессиями ревью
│   ├── tool/             # Встроенные инструменты (file_read, code_search и др.)
│   ├── telemetry/        # Интеграция с OpenTelemetry
│   └── viewer/           # WebUI-просмотрщик сессий
├── pages/                # Фронтенд WebUI
├── scripts/              # Скрипты сборки и установки
└── bin/                  # NPM-обёртка

Вклад в документацию

Документация — важнейшая часть OpenCodeReview. Мы приветствуем улучшения README-файлов, комментариев в коде, примеров конфигурации и любых текстов, обращённых к пользователю.

Что считается вкладом в документацию

  • Исправление опечаток, грамматических ошибок и битых ссылок
  • Прояснение запутанных объяснений и добавление недостающего контекста
  • Добавление примеров использования команд и параметров конфигурации
  • Обновление устаревшего содержимого (например, после изменения функциональности)
  • Перевод и улучшение локализованной документации (README.zh-CN.md, README.ja-JP.md, README.ko-KR.md, README.ru-RU.md, CONTRIBUTING.zh-CN.md, CONTRIBUTING.ja-JP.md, CONTRIBUTING.ko-KR.md, CONTRIBUTING.ru-RU.md)

Процесс работы с документацией

  1. Если вы заметили проблему, но не планируете исправлять её сами, заведите Documentation Issue.
  2. Если хотите исправить сами — сделайте форк, внесите изменения и подайте PR с префиксом ветки docs/ (например, docs/fix-config-example).
  3. PR, затрагивающие только документацию, не требуют изменений в тестах, но, пожалуйста, проверяйте точность всех приводимых команд и фрагментов кода.

Файлы документации

Файл Назначение
README.md Основная документация проекта (английский)
README.zh-CN.md Китайский перевод
README.ja-JP.md Японский перевод
README.ko-KR.md Корейский перевод
README.ru-RU.md Русский перевод
CONTRIBUTING.md Руководство контрибьютора (английский)
CONTRIBUTING.zh-CN.md Руководство контрибьютора (китайский)
CONTRIBUTING.ja-JP.md Руководство контрибьютора (японский)
CONTRIBUTING.ko-KR.md Руководство контрибьютора (корейский)
CONTRIBUTING.ru-RU.md Руководство контрибьютора (русский)

Отправка изменений

Заведение issue

Прежде чем браться за существенное изменение, пожалуйста, сначала заведите issue и обсудите подход. Это предотвращает дублирование работы и гарантирует, что ваш вклад согласуется с направлением развития проекта.

Сообщая о баге, укажите:

  1. Версию OpenCodeReview (ocr version)
  2. ОС и архитектуру
  3. Шаги воспроизведения
  4. Ожидаемое и фактическое поведение
  5. Релевантные логи или сообщения об ошибках

Процесс Pull Request

  1. Держите PR сфокусированным — одно логическое изменение на PR. Несколько независимых изменений лучше подать отдельными PR.
  2. Пишите тесты — добавляйте или обновляйте тесты при любых изменениях поведения.
  3. Обновляйте документацию — если изменение затрагивает видимое пользователю поведение, обновите соответствующую документацию.
  4. Подпишите CLA — прежде чем PR может быть принят, все контрибьюторы должны подписать Contributor License Agreement (см. ниже).
  5. Заполните шаблон PR — опишите, что делает ваше изменение и зачем оно нужно.

Формат заголовка PR

Используйте тот же формат Conventional Commits, что и для сообщений коммитов:

feat(agent): add support for custom tool definitions

Процесс ревью

  • Мейнтейнер посмотрит ваш PR — обычно в течение нескольких рабочих дней.
  • Мы можем попросить внести изменения — это нормальная совместная работа, а не противостояние.
  • После одобрения мейнтейнер смёржит ваш PR.

Лицензионное соглашение контрибьютора (CLA)

Прежде чем мы сможем принять ваш вклад, необходимо подписать Alibaba Open Source Contributor License Agreement. Это гарантирует, что проект может распространяться на условиях своей лицензии.

Когда вы откроете свой первый PR, CLA-бот оставит комментарий с инструкциями. Просто перейдите по ссылке и подпишите соглашение электронно — это занимает минуту.

Новичкам

Впервые в проекте? Ищите issues с метками:

  • good first issue — небольшие, хорошо очерченные задачи, идеальные для старта.
  • help wanted — задачи, где мы будем рады помощи сообщества.

С чего удобно начать:

  • Улучшение сообщений об ошибках и вывода CLI
  • Написание тестов для непокрытых участков кода
  • Улучшение документации

Сообщество

Лицензия

Внося вклад в OpenCodeReview, вы соглашаетесь с тем, что ваш вклад будет лицензирован на условиях Apache License 2.0.