Что это. Движок интернет-магазина без витрины: каталог, корзина, заказы и платежи отдаются через GraphQL, а как это выглядит — решает тот, кто строит витрину. Сам проект описывает себя так: «the high performance, composable, headless commerce API».

Возраст. Первый коммит — 12 февраля 2013 года, автор Patryk Zawadzki, сообщение Initial commit. Он же коммитит в репозиторий и в 2026-м. Проект ведёт компания Saleor Commerce.

Размер. 23 300 звёзд, 6 100 форков, 11 300 влитых PR на сентябрь 2026. Открытых PR при этом чуть больше пятидесяти — очередь не копится.

Правила лежат в двух местах: общие — в документации, а для основного репозитория — в CONTRIBUTING.md.

Чужая идея проходит три двери, и без первой не откроют остальные:

Discord Discussion → Feature Request Issue → Pull Request … Feature Requests without prior discussion on Discord and a GitHub issue will not be considered.

Обсуждение в Discord → задача с предложением → PR … Предложения без предварительного обсуждения в Discord и задачи на GitHub рассматриваться не будут.

На первом шаге просят говорить о нужде, а не о реализации: «we avoid discussing technical details and focus on the use case instead» — технические детали мы не обсуждаем, только сценарий. И это касается не только идей:

All code contributions need discussion and approval through a GitHub issue first.

Любой код сначала обсуждается и одобряется в задаче.

Тесты не ходят в интернет — и это не рекомендация, а запрет на уровне инструмента:

We are also using pytest-socket to ensure that our tests do not hit any external API without explicitly allowing this.

Мы используем pytest-socket, чтобы тесты не ходили ни в какой внешний API без явного разрешения.

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

adding new validation in a mutation logic - it may break storefronts and apps

Новая проверка в мутации — может сломать витрины и приложения.

То есть если корзина стала строже относиться к данным, для Saleor это такая же поломка, как переименованное поле. Именно так проект и повёл себя в истории про удалённую строку: научив корзину сообщать о проблемах вместо ошибки, оставил старое поведение за настройкой канала useLegacyErrorFlow — для тех, кто ещё не готов.

Наблюдения из PR #7239 (2021), issue #12943 (2023) и PR #17027 (2024):

• Ревьюер не считает, что его услышали с первого раза. Одно и то же замечание — «We also should update the quantity field» — написано пять раз в трёх файлах, под каждым местом, где оно применимо.
• Возражает числами. «over 500k checkout objects … around 100k queries» — и в скобках «Correct me if I am wrong». Не «мне не нравится», а оценка стоимости с приглашением её оспорить.
• Отвечает быстро и без обороны. Через пятнадцать минут после возражения: «I will try to find more optimised solution». Итог — из модели убрали целое поле.
• Свою старую ошибку называет вслух. Тот, кто в 2021-м пропустил удаление строк в ревью, в 2024-м сам его убирает и пишет в описании: «we could change the checkout content without informing the user» — мы меняли корзину, не сообщая покупателю.
• Меняет знак у теста, а не удаляет его. ..._removes_checkout_lines стал ..._dont_remove_checkout_lines, assert not стал assert. История поведения остаётся читаемой по диффу.
• Отказывает вежливо, но без ответа на последний вопрос. В истории про монету вопрос «то есть без копеек мне нельзя?» остался без реплики — через три месяца задача закрыта как not planned.

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

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

It should contain less than 50 characters … Introduce what has changed, using imperatives: fix, add, modify, etc.

Каждый PR привязан к задаче — «All Pull Requests should be linked to their corresponding GitHub issues». Не пожелание, а правило.

Запись в changelog — имя PR, номер и автор, по образцу из самого файла:

Раздел делится на Breaking changes и Other changes, и на вопрос «я чиню только что влитую фичу, писать ли отдельную строку?» ответ записан: changelog — не история сборки фичи, а сообщение другим разработчикам, что фича появилась; если релиза ещё не было, дописывают номер починки к прежней строке.

Тест делится на три части словами:

We recommend using given, when, then to distinguish between different test parts.

Файл не называют utils.py:

Module names should make their purpose obvious. Avoid generic file names such as utils.py.

Имя модуля должно говорить о назначении. Избегайте общих имён вроде utils.py.

Блокировки берут в одном порядке — «lock the Order model before OrderLine» — и объясняют, зачем: чтобы не было взаимных блокировок.

Всё ниже — из документации проекта, а не из наших догадок.

Сначала — разговор, и не о коде. Обсуждение в Discord должно описать проблему и получить одобрение мейнтейнеров; только после этого вас попросят завести задачу. Задача без ссылки на обсуждение не считается.

Задача получает метку accepted — и только с ней можно открывать PR. В описании PR — ссылка на задачу.

Куда пойти новичку — сказано прямо:

"Good First Issues" are issues that are suitable for beginners to contribute to. They are typically well-defined and don't require a deep understanding of the codebase. "Help Wanted" issues can be more extensive and require a deeper understanding of the codebase.

«Good First Issues» — задачи для начинающих: хорошо очерченные, без глубокого знания кода. «Help Wanted» — объёмнее и требуют понимания устройства.

Миграции — без остановки сервиса. Отдельная политика zero-downtime: проект живёт у настоящих магазинов, и «выключим на пять минут» не вариант.

Каждое поле API — с описанием, точкой в конце и версией, в которой появилось. Удаление поля — сначала DEPRECATED, потом удаление. Ошибка PermissionDenied обязана назвать, каких прав не хватило.

Люди, встреченные в наших разборах этого проекта. Подробные карточки — в «Определителе».

• korycins — Maciej Korycinski, Saleor. В 2021-м возразил против ста тысяч запросов; в 2023-м сформулировал «сообщать, а не падать» и сделал problems; в 2024-м убрал удаление строк, которое сам когда-то пропустил в ревью.
• d-wysocki — Damian Wysocki, Saleor. Автор удаления строк (2021) и решения убрать поле quantity из модели после возражения — через пятнадцать минут после него.
• fowczarek — Filip Owczarek, Saleor. Пять раз напомнил про одно и то же поле; ревьюер починок 2023 и 2024 годов.
• IKarbowiak — Iga Karbowiak, Saleor. Сама завела задачу о скидке, округлявшейся не в ту сторону, и починила за два дня; ревьюер починок 2024 года.
• maarcingebala — Marcin Gębala. Ревьюер переноса 2021 года и починки 2023-го.
• szczecha — Anna Szczęch, Saleor; kadewu; yellowee — Renata. Ревьюеры починок 2023–2024.
• timuric — Timur Carpeev. Автор issue #12938 — о корзине, которая перестаёт отвечать, когда товар кончился.
• uroybd — Utsob Roy. Пришёл с бангладешской такой, у которой нет монет для дробей, и честно сказал, что решения у него нет.
• ilonamanole — Ilona Manole. Поставила DEFAULT_DECIMAL_PLACES = 0, сломала корзину и задала вопрос, на который не ответили.

• «Строка, которую убрали молча» — товар сняли с канала, строки из корзин стёрли без предупреждения; через три с половиной года тот же проект переписал тест в обратную сторону.
• «Монета, которой нечем заплатить» — три человека за три года просят цен без копеек, потому что копеек нет в обращении; ответ каждый раз: округление задаёт валюта, а не магазин.

Карточка собрана 02.09.2026 из открытых источников: репозиторий, документация проекта, переписка в PR и задачах. Фотографий и личных данных здесь нет и не будет. Нашли неточность или хотите, чтобы вас убрали, — напишите, поправим без вопросов.