Рекомендации для рецензентов

Просмотр открытых запросов на добавление (PR) помогает продвигать проект. Мы также приветствуем участие людей извне проекта; это отличный способ ознакомиться с кодовой базой.

Кто может быть рецензентом?

Обзоры могут поступать извне команды NumPy – мы приветствуем вклад экспертов в предметной области (например, linalg или fft) или разработчиков других проектов. Вам не нужно быть разработчиком NumPy (членом команды NumPy с правом слияния PR) для проведения обзора.

Если мы вас еще не знаем, рассмотрите возможность представить себя на форуме или в Slack до начала просмотра запросов на добавление.

Список проверок для рецензента

Ясно ли заданное поведение при всех условиях? Вот на что стоит обратить внимание:
- Что происходит с неожиданными входными данными, такими как пустые массивы или значения nan/inf?
- Тестируются ли аргументы axis или shape для int или tuples?
- Тестируются ли необычные dtypes, если функция поддерживает их?
Следует ли улучшить имена переменных для ясности или согласованности?
Следует ли добавить комментарии или, возможно, удалить бесполезные или лишние?
Соответствует ли документация руководству NumPy? Правильно ли отформатированы строковые документации?
Соответствует ли код стилистическим рекомендациям NumPy?
Если вы являетесь разработчиком и это не очевидно из описания PR, добавьте в сообщение о слиянии краткое объяснение того, что сделал ветвь, а также, если закрывается проблема, добавьте «Закрывает gh-123», где 123 – номер проблемы.
Для изменений в коде как минимум один разработчик (то есть тот, у кого есть права на коммит) должен просмотреть и одобрить запрос на добавление. Если вы первый просмотрели PR и одобрили изменения, используйте инструмент GitHub одобрения обзора, чтобы отметить его как таковой. Если PR прост, например, это явная исправление ошибки, его можно объединить сразу. Если он более сложный или изменяет общедоступный API, оставьте его открытым как минимум на пару дней, чтобы другие разработчики имели возможность провести обзор.
Если вы последующий рецензент уже одобренного PR, используйте тот же метод обзора, что и для нового PR (сосредоточьтесь на более крупных проблемах, избегайте искушения добавлять только несколько мелких замечаний). Если у вас есть права на коммит и вы считаете, что больше обзоров не требуется, объедините PR.

Для разработчиков

Убедитесь, что все автоматические тесты CI проходят до слияния PR и что строительство документации выполняется без ошибок.
В случае конфликтов слияния попросите автора PR перебазироваться на главную ветку.
Для PR, добавляющих новые функции или каким-либо образом сложные, подождите как минимум день или два, прежде чем объединять их. Таким образом, другие получат возможность прокомментировать, прежде чем код будет внесен. Подумайте о добавлении в заметки о выпуске.
При слиянии вкладов разработчик несет ответственность за то, чтобы они соответствовали требованиям, изложенным в руководстве по процессам разработки для NumPy. Также проверьте, обсуждались ли новые функции и разрывы обратной совместимости на форуме numpy-discussion.
Сжатие коммитов или очистка сообщений о коммитах в PR, который вам кажется слишком беспорядочным, допустимо. Помните, сохраняйте имя исходного автора при выполнении этого. Убедитесь, что сообщения о коммитах соответствуют правилам для NumPy.
Когда вы хотите отклонить PR: если это очевидно, вы можете просто закрыть его и объяснить почему. Если нет, то неплохо сначала объяснить, почему вы считаете, что PR не подходит для включения в NumPy, а затем позволить второму разработчику прокомментировать или закрыть.

Поток работ GitHub

При просмотре запросов на добавление, пожалуйста, используйте функции отслеживания потока работ в GitHub, если это необходимо:

После завершения обзора, если вы хотите попросить отправителя внести изменения, измените статус обзора на «Требуются изменения». Это можно сделать в GitHub, на странице PR, вкладка «Измененные файлы», Обзор изменений (кнопка в правом верхнем углу).
Если вас устраивает текущее состояние, отметьте запрос на добавление как одобренный (так же, как и «Требуются изменения»). В качестве альтернативы (для разработчиков): объедините запрос на добавление, если считаете, что он готов к слиянию.

Возможно, будет полезно иметь копию кода запроса на добавление, проверенного на вашем собственном компьютере, чтобы вы могли поработать с ним локально. Вы можете использовать GitHub CLI, нажав кнопку Open with в правом верхнем углу страницы PR.

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

Стандартные ответы для обзора

Возможно, будет полезно сохранить некоторые из них в сохранённых ответах GitHub для обзоров:

Вопрос по использованию

You are asking a usage question. The issue tracker is for bugs and new features.
I'm going to close this issue, feel free to ask for help via our [help channels](https://numpy.org/gethelp/).

Вы можете обновить документацию

Please feel free to offer a pull request updating the documentation if you feel it could be improved.

Самодостаточный пример для ошибки

Please provide a [self-contained example code](https://stackoverflow.com/help/mcve), including imports and data (if possible), so that other contributors can just run it and reproduce your issue.
Ideally your example code should be minimal.

Версии программного обеспечения

To help diagnose your issue, please paste the output of:
```
python -c 'import numpy; print(numpy.version.version)'
```
Thanks.

Блоки кода

Readability can be greatly improved if you [format](https://help.github.com/articles/creating-and-highlighting-code-blocks/) your code snippets and complete error messages appropriately.
You can edit your issue descriptions and comments at any time to improve readability.
This helps maintainers a lot. Thanks!

Ссылка на код

For clarity's sake, you can link to code like [this](https://help.github.com/articles/creating-a-permanent-link-to-a-code-snippet/).

Лучшее описание и заголовок

Please make the title of the PR more descriptive.
The title will become the commit message when this is merged.
You should state what issue (or PR) it fixes/resolves in the description using the syntax described [here](https://docs.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword).

Необходимы тесты регрессии

Please add a [non-regression test](https://en.wikipedia.org/wiki/Non-regression_testing) that would fail at main but pass in this PR.

Не изменяйте не связанные элементы

Please do not change unrelated lines. It makes your contribution harder to review and may introduce merge conflicts to other pull requests.