Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
275 lines (192 loc) · 23.4 KB

CONTRIBUTING.md

File metadata and controls

275 lines (192 loc) · 23.4 KB
Raw

English • Català • Deutsch • Español • Français • हिंदी • Italiano • Nederlands • Русский

日本語 • 한국어 • Polski • Português (BR) • Türkçe • Tiếng Việt • 简体中文 • 繁體中文

Вклад в Roo Code

Roo Code — это проект, управляемый сообществом, и мы очень ценим каждый вклад. Чтобы процесс был максимально простым и эффективным для всех, мы работаем по принципу "Issue-First". Это значит, что вся работа должна быть связана с GitHub Issue до отправки Pull Request (подробности см. в нашей PR-политике). Пожалуйста, внимательно прочитай это руководство, чтобы понять, как внести свой вклад. Это руководство объясняет, как внести вклад в Roo Code — будь то исправление ошибок, добавление новых функций или улучшение документации.

Содержание

I. Перед тем как внести вклад

Сначала ознакомься с нашими стандартами сообщества и направлением проекта.

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

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

2. Понимание дорожной карты проекта

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

  • Согласовать свой вклад с целями проекта
  • Найти области, где твой опыт будет наиболее ценен
  • Понять контекст некоторых проектных решений
  • Вдохновиться на новые функции, поддерживающие наше видение

Текущая дорожная карта фокусируется на шести ключевых направлениях:

Поддержка провайдеров

Мы хотим хорошо поддерживать как можно больше провайдеров:

  • Больше поддержки "OpenAI Compatible"
  • xAI, Microsoft Azure AI, Alibaba Cloud Qwen, IBM Watsonx, Together AI, DeepInfra, Fireworks AI, Cohere, Perplexity AI, FriendliAI, Replicate
  • Улучшенная поддержка Ollama и LM Studio

Поддержка моделей

Мы хотим, чтобы Roo работал с как можно большим количеством моделей, включая локальные:

  • Поддержка локальных моделей через кастомные системные промпты и рабочие процессы
  • Бенчмаркинг, оценки и тест-кейсы

Поддержка систем

Мы хотим, чтобы Roo хорошо работал на любом компьютере:

  • Кроссплатформенная интеграция терминала
  • Надежная и стабильная поддержка Mac, Windows и Linux

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

Мы хотим обеспечить полную и доступную документацию для всех пользователей и участников:

  • Расширенные руководства и учебники
  • Четкая документация по API
  • Лучшие рекомендации для участников
  • Многоязычные ресурсы документации
  • Интерактивные примеры и фрагменты кода

Стабильность

Мы хотим значительно снизить количество ошибок и увеличить автоматизированное тестирование:

  • Переключатель логирования отладки
  • Кнопка "Скопировать информацию о машине/задаче" для запросов о багах/поддержке

Интернационализация

Мы хотим, чтобы Roo говорил на языке каждого:

  • 我们希望 Roo Code 说每个人的语言
  • Queremos que Roo Code hable el idioma de todos
  • हम चाहते हैं कि Roo Code हर किसी की भाषा बोले
  • نريد أن يتحدث Roo Code لغة الجميع

Особенно приветствуются вклады, которые способствуют достижению целей дорожной карты. Если ты работаешь над чем-то, что связано с этими направлениями, укажи это в описании PR.

3. Присоединяйся к сообществу Roo Code

Вступление в сообщество Roo Code — отличный способ начать:

  • Основной способ:
    1. Присоединяйся к сообществу Roo Code в Discord.
    2. После присоединения отправь личное сообщение (DM) Hannes Rudolph (Discord: hrudolph), чтобы обсудить свой интерес и получить советы.
  • Альтернатива для опытных участников: Если тебе удобно работать по принципу Issue-First, можешь участвовать напрямую через GitHub, следя за Kanban-доской и общаясь через issues и pull requests.

II. Поиск и планирование вклада

Определи, над чем хочешь работать и как это сделать.

1. Виды вклада

Мы приветствуем разные виды вклада:

  • Исправление ошибок: Исправление проблем в существующем коде
  • Новые функции: Добавление новых возможностей
  • Документация: Улучшение руководств, добавление примеров или исправление опечаток

2. Ключевой принцип: подход Issue-First

Весь вклад должен начинаться с GitHub Issue. Это важно для согласования и предотвращения лишней работы.

  • Найти или создать Issue:
    • Перед началом работы проверь GitHub Issues, есть ли уже issue для твоего вклада.
    • Если есть и не назначено, оставь комментарий, что хочешь заняться этим. Мейнтейнер назначит его тебе.
    • Если нет, создай новое, используя подходящий шаблон на нашей странице issues:
      • Для багов — шаблон "Bug Report"
      • Для новых функций — шаблон "Detailed Feature Proposal". Дождись одобрения мейнтейнера (особенно @hannesrudolph) перед началом реализации.
      • Примечание: Общие идеи или предварительные обсуждения функций можно начать в GitHub Discussions. Когда идея станет конкретной, создай issue "Detailed Feature Proposal".
  • Заявка и назначение:
    • Ясно укажи, что хочешь работать над issue, комментируя его.
    • Дождись, пока мейнтейнер официально назначит его тебе в GitHub. Так мы избегаем дублирования работы.
  • Последствия несоблюдения:
    • Pull Requests (PR), отправленные без соответствующего, одобренного и назначенного issue, могут быть закрыты без полного рассмотрения. Эта политика нужна для согласования вклада с приоритетами проекта и уважения времени всех участников.

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

3. Решение, над чем работать

  • Good First Issues: Ознакомься с разделом "Issue [Unassigned]" в нашем проекте Roo Code Issues на GitHub.
  • Документация: Хотя этот CONTRIBUTING.md — основной гид по вкладу в код, если хочешь внести вклад в другую документацию (например, руководства пользователя или API), смотри репозиторий Roo Code Docs или спроси в сообществе Discord.
  • Предложение новых функций:
    1. Идея/обсуждение: Для общих или начальных идей начни обсуждение в GitHub Discussions.
    2. Формальное предложение: Для конкретных, готовых к рассмотрению предложений создай issue "Detailed Feature Proposal" с шаблона на нашей странице issues. Это ключевая часть нашего подхода Issue-First.

4. Сообщение об ошибках или проблемах

Если нашел ошибку:

  1. Проверь существующие issues: Посмотри GitHub Issues, нет ли уже такого сообщения.
  2. Создай новое issue: Если уникально, используй шаблон "Bug Report" на нашей странице issues.

🔐 Уязвимости безопасности: Если обнаружил уязвимость, сообщи о ней приватно через GitHub Security Advisory Tool. Не создавай публичное issue для уязвимостей.

III. Процесс разработки и отправки

Следуй этим шагам для написания и отправки кода.

1. Настройка среды разработки

  1. Fork & Clone:
    • Сделай форк репозитория на GitHub.
    • Клонируй свой форк локально: git clone https://github.com/ТВОЙ_ПОЛЬЗОВАТЕЛЬ/Roo-Code.git
  2. Установи зависимости: npm run install:all
  3. Запусти Webview (Dev Mode): npm run dev (для приложения Vite/React с HMR)
  4. Отладка расширения: Нажми F5 в VS Code (или Run → Start Debugging), чтобы открыть новое окно Extension Development Host с Roo Code.

Изменения в webview (webview-ui) появятся сразу благодаря Hot Module Replacement. Изменения в основной части расширения (src) требуют перезапуска Extension Development Host.

Также можно собрать и установить пакет .vsix:

npm run build
code --install-extension bin/roo-cline-<версия>.vsix

(Замени <версия> на фактический номер версии сгенерированного файла).

2. Руководство по написанию кода

  • Фокусированные PR: Одна функция/исправление на PR.
  • Качество кода:
    • Пройти проверки CI (линтинг, форматирование)
    • Исправить предупреждения или ошибки ESLint (npm run lint)
    • Реагировать на обратную связь от автоматических инструментов code review
    • Следовать лучшим практикам TypeScript и поддерживать типобезопасность
  • Тестирование:
    • Добавить тесты для новых функций
    • Запустить npm test, чтобы убедиться, что все тесты проходят
    • Обновить существующие тесты, если твои изменения их затрагивают
  • Сообщения коммитов:
    • Писать четкие, описательные сообщения коммитов
    • Ссылаться на соответствующие issues через #номер-issue (например, Fixes #123)
  • Чеклист перед отправкой PR:
    • Перебазировать свою ветку на последний main из upstream
    • Убедиться, что код собирается (npm run build)
    • Все тесты должны проходить (npm test)
    • Удалить любой отладочный код или console.log

3. Отправка кода: процесс Pull Request (PR)

Черновики Pull Request

Используй черновики PR для работы, которая еще не готова к полной проверке, но для которой ты хочешь:

  • Запустить автоматические проверки (CI)
  • Получить ранний фидбек от мейнтейнеров или других участников
  • Показать, что работа в процессе

Отметь PR как "Ready for Review" только когда все проверки пройдены и ты считаешь, что он соответствует критериям "Руководства по написанию кода" и "Описание Pull Request".

Описание Pull Request

Описание PR должно быть полным и следовать структуре нашего шаблона Pull Request. Основные моменты:

  • Ссылка на одобренный GitHub Issue, который решается
  • Четкое описание внесенных изменений и их цели
  • Подробные шаги для тестирования изменений
  • Список любых breaking changes
  • Для изменений в UI: скриншоты или видео до/после
  • Укажи, требует ли твой PR обновления пользовательской документации и какие документы/разделы затрагиваются

Политика Pull Request (PR)

Цель

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

Подход Issue-First
  • Обязательно: Перед началом работы должно быть существующее, одобренное и назначенное GitHub Issue ("Bug Report" или "Detailed Feature Proposal").
  • Одобрение: Issues, особенно для крупных изменений, должны быть одобрены мейнтейнерами (особенно @hannesrudolph) до начала кодирования.
  • Ссылка: PR должны явно ссылаться на эти предварительно одобренные issues в описании.
  • Последствия: Несоблюдение этого процесса может привести к закрытию PR без полной проверки.
Условия для открытых PR
  • Готов к слиянию: Проходит все проверки CI, соответствует дорожной карте (если применимо), связан с одобренным и назначенным Issue, имеет четкую документацию/комментарии, включает скриншоты/видео до/после для изменений в UI
  • Для закрытия: Ошибки CI, серьезные конфликты слияния, несоответствие целям проекта или длительная неактивность (>30 дней без обновлений после фидбека)
Процедура
  1. Квалификация и назначение Issue: @hannesrudolph (или другие мейнтейнеры) проверяют и назначают новые и существующие issues.
  2. Первичная triage PR (ежедневно): Мейнтейнеры быстро проверяют новые PR на срочность или критические вопросы.
  3. Детальная проверка PR (еженедельно): Мейнтейнеры тщательно проверяют PR на готовность, соответствие одобренному Issue и общее качество.
  4. Детальный фидбек и итерация: По результатам проверки мейнтейнеры дают фидбек (Approve, Request Changes, Reject). Ожидается, что участники ответят и доработают PR.
  5. Этап принятия решения: Одобренные PR сливаются. PR с нерешаемыми проблемами или несоответствием могут быть закрыты с объяснением.
  6. Follow-up: Авторы закрытых PR могут доработать их по фидбеку и открыть новые, если проблемы решены или направление проекта изменилось.
Ответственности
  • Квалификация Issue и соблюдение процесса (@hannesrudolph & мейнтейнеры): Следить, чтобы все вклады следовали подходу Issue-First. Помогать участникам с процессом.
  • Мейнтейнеры (Dev Team): Проверять PR, давать технический фидбек, принимать решения об одобрении/отклонении, сливать PR.
  • Участники: Связывать PR с одобренным и назначенным Issue, соблюдать стандарты качества, быстро реагировать на фидбек.

Эта политика обеспечивает ясность и эффективную интеграцию.

IV. Юридическая информация

Соглашение о вкладе

Отправляя pull request, ты соглашаешься, что твой вклад будет лицензирован по лицензии Apache 2.0 (или текущей лицензии проекта), как и сам проект.