Правила PR и политики

Правила для PR

• Предпочитаем небольшие PR.
• При наличии доступа на запись можно использовать стопки PR через Graphite; доступ выдают активным контрибьюторам.
• Архитектурные изменения лучше обсудить в issue или Discussion заранее.

Политика разработки

• Ориентация на данные (data-oriented design).
• Простые и документированные API.
• Если реализация позаимствована, указывайте источник.

Производительность

• Любые проблемы производительности считаем багами — и во время выполнения, и времени компиляции.
  • Ориентир — Rust Performance Book.
  • По возможности избегайте crate regex; предпочитайте итераторы и строковые методы Rust.
• Время компиляции нужно удерживать низким.
  • Меньше сторонних зависимостей.
  • Избегать тяжёлых макросов, избыточной обобщённости и приёмов, раздувающих бинарник или замедляющих сборку.
  • CI должен укладываться примерно в 3 минуты; регрессии нужно чинить.

Политика сопровождения

• Следить за покрытием и удалять мёртвый код; цель — порядка 99% покрытия.
• Сокращать время CI для быстрого мержа; сейчас GitHub Actions около 3 минут.
• Документация — источник правды: обновляйте её и давайте ссылки вместо повторных ответов; см. подход GitLab handbook-first.
• Порядок импортов: от «далёких» к «близким»:
  • std
  • внешние crate
  • crate Oxc
  • локальный crate (crate)
  • super
  • mod

Conventional Commits

Используем Conventional Commits:

• fix — исправление бага.
• feat — новая возможность.
• BREAKING CHANGE: после типа/scope ставится !, например feat(parser)!: ....
• В качестве scope — имена crate.
• Типы: feat, fix, chore, ci, docs, style, refactor, perf, test.

Принцип действий

Из ценностей Astral:

Мы склонны к действию даже при неопределённости. Предпочитаем прагматичное делание долгим спорам; просить прощения, а не разрешения. Ценим решительность там, где выбор неочевиден и особенно когда его можно откатить.

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