Merge remote-tracking branch 'origin/sphinx-attr-getter-ext' into sphinx-attr-getter-ext

Author: clayote

.github/PULL_REQUEST_TEMPLATE.md

@@ -14,26 +14,23 @@ If an item doesn't apply to your pull request, **check it anyway** to make it ap
 If your pull request is a documentation fix or a trivial typo, feel free to delete the whole thing.
 -->
 
-- [ ] Do **not** open pull requests from your `main` branch – [**use a separate branch**](https://hynek.me/articles/pull-requests-branch/)!
-  - There's a ton of footguns waiting if you don't heed this warning. You can still go back to your project, create a branch from your main branch, push it, and open the pull request from the new branch.
-  - This is not a pre-requisite for your pull request to be accepted, but **you have been warned**.
-- [ ] Added **tests** for changed code.
-  Our CI fails if coverage is not 100%.
+- [ ] I acknowledge this project's [**AI policy**](https://github.com/python-attrs/attrs/blob/main/.github/AI_POLICY.md).
+- [ ] This pull requests is [**not** from my `main` branch](https://hynek.me/articles/pull-requests-branch/).
+  - Consider granting [push permissions to the PR branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork), so maintainers can fix minor issues themselves without pestering you.
+- [ ] There's **tests** for all new and changed code.
 - [ ] Changes or additions to public APIs are reflected in our type stubs (files ending in ``.pyi``).
     - [ ] ...and used in the stub test file `typing-examples/baseline.py` or, if necessary, `typing-examples/mypy.py`.
     - [ ] If they've been added to `attr/__init__.pyi`, they've *also* been re-imported in `attrs/__init__.pyi`.
-- [ ] Updated **documentation** for changed code.
+- [ ] The **documentation** has been updated.
     - [ ] New functions/classes have to be added to `docs/api.rst` by hand.
     - [ ] Changes to the signatures of `@attr.s()` and `@attrs.define()` have to be added by hand too.
     - [ ] Changed/added classes/methods/functions have appropriate `versionadded`, `versionchanged`, or `deprecated` [directives](http://www.sphinx-doc.org/en/stable/markup/para.html#directive-versionadded).
           The next version is the second number in the current release + 1.
           The first number represents the current year.
-          So if the current version on PyPI is 22.2.0, the next version is gonna be 22.3.0.
-          If the next version is the first in the new year, it'll be 23.1.0.
-      - [ ] If something changed that affects both `attrs.define()` and `attr.s()`, you have to add version directives to both.
-- [ ] Documentation in `.rst` and `.md` files is written using [semantic newlines](https://rhodesmill.org/brandon/2012/one-sentence-per-line/).
-- [ ] Changes (and possible deprecations) have news fragments in [`changelog.d`](https://github.com/python-attrs/attrs/blob/main/changelog.d).
-- [ ] Consider granting [push permissions to the PR branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork), so maintainers can fix minor issues themselves without pestering you.
+          So if the current version on PyPI is 26.2.0, the next version is gonna be 26.3.0.
+          If the next version is the first in the new year, it'll be 27.1.0.
+    - [ ] Documentation in `.rst` and `.md` files is written using [semantic newlines](https://rhodesmill.org/brandon/2012/one-sentence-per-line/).
+- [ ] Changes have news fragments in [`changelog.d`](https://github.com/python-attrs/attrs/blob/main/changelog.d).
 
 <!--
 If you have *any* questions to *any* of the points above, just **submit and ask**!