An easy mechanism for forking packages/the distro (maybe involving bikesheds)

The problem

Assume you're a Debian user (or Debian-using organisation). At some point you hit a bug that you can resolve by modifying a package. We have the source available, all the build infrastructure is in the archive, this should be trivial, but it really isn't. Especially if you want to share the result of your tweak with others.

Actual situation

Right now, you need to:

1. Learn roughly how Debian packaging works.
2. Find the git repo for the package, if it exists. Create one with gbp + debsnap / dgit if it doesn't.
3. Discover how patches are applied in this repo (if it exists).
4. Learn how to patch the package, update the changelog etc.
5. Export a source package.
6. Learn how to build Debian packages.
7. Set up a Debian build environment (sbuild/pbuilder/*).
8. Build your package.
9. Learn how to create a Debian package repo.
10. Create a keyring for the repo, etc.
11. Ingest your package into the repo.

Expected situation

There should be way less friction.

I think, ideally, somebody should be able to:

1. Fork a git repo
2. Apply a patch to it
3. Push to the repo and have it build the package. Salsa CI goes a long way here, at the moment, there'd probably be a lot of trial-and-error commits.
4. Test the package on some machines (from the build output DEB manually, or from a staging repo).
5. Publish the result in an archive.

Long-term maintenance is also a question here, ideally one would be able to maintain a fork of a package through time, constantly rebasing the change on the latest Debian package, and re-publishing after verification.

Additional information

The ideal workflow for a non-Debian person probably involves automated changelog (and suitable version) generation from git commits.

PPAs in Ubuntu cover a lot of this ground (at least from the build-environment onwards).

Copyright status of arbitrary things published in repos is obviously a potential issue, but may be somewhat mitigated if the service was restricted to deriving existing packages only (that is a big limitation).

Bikesheds (#6) could cover some of the ground, but are expected to be Debian members-only, which is not what this issue is about.