Reporting Issues ================ When opening a new issue, please take the following steps: 1. Please search `GitHub issues`_ to avoid duplicate reports. 2. If possible, try updating to master and reproducing your issue. 3. Try to include a minimal code example that demonstrates the problem. 4. Include any relevant details of your local setup (mpmath version, Python version, installed libraries). Please avoid changing your messages on the GitHub, unless you want fix a typo and so on. Just expand your comment or add a new one. Contributing Code ================= All work should be submitted via `Pull Requests (PR)`_. 1. PR can be submitted as soon as there is code worth discussing. Please make a draft PR, if one is not intended to be merged in its present shape even if all checks pass. 2. Please put your work on the branch of your fork, not in the master branch. PR should generally be made against master. 3. One logical change per commit. Make good commit messages: short (<= 78 characters) one-line summary, then newline followed by verbose description of your changes. Please `mention closed issues`_ with commit message. 4. Please conform to `PEP 8`_; run:: flake518 to check formatting. 5. PR should include tests: 1. Bugfixes should include regression tests (named as ``test_issue_123``). 2. All new functionality should be tested, every new line should be covered by tests. Please use in tests only public interfaces. Regression tests are not accounted in the coverage statistics. 3. Optionally, provide doctests to illustrate usage. But keep in mind, doctests are not tests. Think of them as examples that happen to be tested. 6. It's good idea to be sure that **all** existing tests pass and you don't break anything, so please run:: pytest 7. If your change affects documentation, please build it by:: sphinx-build -W -b html docs build/sphinx/html and check that it looks as expected. AI Generated Code and Communication Policy ========================================== The person submitting an issue or PR is responsible for its content, regardless of whether AI tools were used in its creation. Generative AI tools can produce output quickly, but discretion, good judgment, and critical thinking are the foundation of all good contributions. You must understand and explain the code you submit as well as the existing related code. It is not acceptable to submit a patch that you cannot understand and explain yourself. In explaining your contribution, do not use AI to automatically generate descriptions, as AI rarely communicates such information correctly and concisely. Disclosure ---------- If you substantially make use of AI to assist in the development of your patch, you must disclose how it was used and what code in the patch is AI generated. Pull request without such disclosure may be rejected. Code Quality ------------ Code generated by AI is very often of low quality. Contributors are expected to submit code that meets our standards (see above). We will reject pull requests that we deem being "AI slop". Do not waste developers time by submitting code that is fully or mostly generated by AI. Communication ------------- When interacting in communication among developers (email list, discussions, issues, pull requests, etc) do not use AI to speak for you, other than for translation or grammar editing. .. _GitHub issues: https://github.com/mpmath/mpmath/issues .. _Pull Requests (PR): https://github.com/mpmath/mpmath/pulls .. _PEP 8: https://www.python.org/dev/peps/pep-0008/ .. _mention closed issues: https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue