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

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

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

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

Рекомендации по общению

• Любой PR, хороший или плохой, является проявлением щедрости. Начните с позитивного комментария, чтобы автор почувствовал вознаграждение, и ваши последующие замечания будут восприняты более ясно. Вы также почувствуете удовлетворение.
• Если возможно, начните с крупных проблем, чтобы автор понял, что его труд учтён. Избегайте соблазна сразу переходить к поиске ошибок по строкам кода или начинать с мелких повсеместных проблем.
• Вы являетесь лицом проекта, и NumPy некоторое время назад определил тип проекта: открытый, эмпатический, приветливый, дружелюбный и терпеливый. Будьте доброжелательны к участникам.
• Не позволяйте совершенству быть врагом хорошего, особенно в документации. Если вы обнаруживаете, что делаете много мелких замечаний или слишком придирчивы к стилю или грамматике, рассмотрите возможность слияния текущего PR, когда все важные вопросы будут решены. Затем либо сделайте непосредственный коммит (если вы участник команды), либо откройте самостоятельный PR.
• Если вам нужна помощь в написании ответов в обзорах, ознакомьтесь с некоторыми стандартными ответами для рецензирования.

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

• Ясен ли предполагаемый результат при всех условиях? Некоторые моменты для наблюдения:

  • Что происходит со неожиданными входными данными, такими как пустые массивы или значения nan/inf?
  • Проверяются ли аргументы осей или форм, чтобы быть int или tuples?
  • Проверяются ли необычные dtypes, если функция поддерживает их?

• Нужно ли улучшить имена переменных для большей ясности или согласованности?
• Нужно ли добавить комментарии или, наоборот, удалить бесполезные или лишние?
• Документация соответствует ли Рекомендациям NumPy? Правильно ли отформатированы строковые документации?
• Код соответствует ли Рекомендациям по стилю NumPy?
• Если вы участник команды, и это не очевидно из описания PR, добавьте краткое объяснение того, что сделала ветка, в сообщение о слиянии, а также, если закрываете проблему, добавьте «Closes gh-123», где 123 — номер проблемы.
• Для изменений кода как минимум один участник команды (т. е. человек с правами коммита) должен просмотреть и одобрить запрос на включение. Если вы первый, кто просматривает PR и одобряете изменения, используйте инструмент GitHub одобрения обзора, чтобы отметить это. Если PR очевиден, например, это явное исправление ошибки, его можно сразу объединить. Если он более сложный или изменяет публичный API, оставьте его открытым как минимум на пару дней, чтобы другие участники команды могли его просмотреть.
• Если вы последующий рецензент уже одобренного PR, пожалуйста, используйте тот же метод рецензирования, что и для нового PR (сосредоточьтесь на более крупных проблемах, избегайте соблазна добавлять только несколько замечаний). Если вы имеете права коммита и считаете, что большего рецензирования не требуется, объедините PR.

#if NPY_FEATURE_VERSION >= NPY_1_20_API_VERSION
    char *buffer_fmt;
#endif

'PyDataMem_SetHandler':                 (304, MinVersion("1.22")),

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

Полезно сохранить некоторые из них в сохранённых ответах 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.