diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index 430ad2477..b1dc34b4d 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -1,9 +1,8 @@
 <!--- Describe the changes here. --->
 
-**Changelog-friendly one-liner**: <!-- One-liner description here -->
-
 ##### Contributor checklist
 
 - [ ] Provided the tests for the changes.
-- [ ] Gave a clear one-line description in the PR (that the maintainers can add to CHANGELOG.md on release).
+- [ ] Assure PR title is short, clear, and good to be included in the user-oriented changelog
+- [ ] Assure one of these labels is present: `backwards incompatible`, `feature`, `enhancement`, `deprecation`, `bug`, `dependency`, `docs` or `skip-changelog` as they determine changelog listing.
 - [ ] Assign the PR to an existing or new milestone for the target version (following [Semantic Versioning](https://blog.versioneye.com/2014/01/16/semantic-versioning/)).
diff --git a/.github/release-drafter.yml b/.github/release-drafter.yml
new file mode 100644
index 000000000..674b0b5a1
--- /dev/null
+++ b/.github/release-drafter.yml
@@ -0,0 +1,49 @@
+name-template: "$RESOLVED_VERSION"
+tag-template: "$RESOLVED_VERSION"
+
+categories:
+  - title: "Backwards Incompatible Changes"
+    labels:
+      - "backwards incompatible"
+
+  - title: "Features"
+    labels:
+      - "feature"
+      - "enhancement"
+      # usually combined with enhancement (avoid double listing)
+      - "deprecation"
+
+  - title: "Bug Fixes"
+    labels:
+      - "bug"
+      - "bug fix"
+
+  - title: "Other Changes"
+    labels:
+      - "dependency"
+      - "docs"
+
+change-template: "- $TITLE ([#$NUMBER](https://github.com/jazzband/pip-tools/pull/$NUMBER)). Thanks @$AUTHOR"
+exclude-labels:
+  - "skip-changelog"
+  - "maintenance"
+  - "trivial"
+template: |
+  $CHANGES
+
+version-resolver:
+  major:
+    labels:
+      - "backwards incompatible"
+  minor:
+    labels:
+      - "feature"
+      - "enhancement"
+      - "deprecation"
+  patch:
+    labels:
+      - "bug fix"
+      - "bug"
+      - "dependency"
+      - "docs"
+  default: minor
diff --git a/.github/workflows/release-drafter.yml b/.github/workflows/release-drafter.yml
new file mode 100644
index 000000000..d968a3c8a
--- /dev/null
+++ b/.github/workflows/release-drafter.yml
@@ -0,0 +1,22 @@
+name: release-drafter
+
+on:
+  push:
+    # branches to consider in the event; optional, defaults to all
+    branches:
+      - master
+      - "releases/**"
+      - "stable/**"
+
+jobs:
+  update_release_draft:
+    permissions:
+      contents: write
+      pull-requests: read
+    if: github.repository == 'jazzband/pip-tools'
+    runs-on: ubuntu-latest
+    steps:
+      # Drafts your next release notes as Pull Requests are merged into "master"
+      - uses: release-drafter/release-drafter@v5
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index f7ea4c149..35fa944ce 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -28,9 +28,7 @@ To help keeping track of the releases and their changes, here's the current rele
 
 - Check to see if any recently merged PRs are missing from the milestone of the version about to be released.
 - Create a branch for the release. _Ex: release-3.4.0_.
-- Update the [CHANGELOG](CHANGELOG.md) with the version, date and using the one-line descriptions
-  from the PRs included in the milestone of the version.
-  Check the previous release changelog format for an example. Don't forget the "Thanks @contributor" mentions.
+- Update the [CHANGELOG](CHANGELOG.md) with the version, date and add the text from [drafter release](https://github.com/jazzband/pip-tools/releases).
 - Push the branch to your fork and create a pull request.
 - Merge the pull request after the changes being approved.
 - Make sure that the tests/CI still pass.
@@ -38,7 +36,6 @@ To help keeping track of the releases and their changes, here's the current rele
   - _Tag version:_ The exact version number, following [Semantic Versioning](https://blog.versioneye.com/2014/01/16/semantic-versioning/). _Ex: 3.4.0_
   - _Target:_ master. As a general rule, the HEAD commit of the master branch should be the release target.
   - _Release title:_ Same as the tag. _Ex: 3.4.0_
-  - _Describe this release:_ Copy of this release's changelog segment.
 - Publish release. This will push a tag on the HEAD of master, trigger the CI pipeline and
   deploy a pip-tools release in the **Jazzband private package index** upon success.
 - The pip-tools "lead" project members will receive an email notification to review the release and