It is a tiresome process. I attempted to submit a particular package (and others before and after me). It was either met with a lot of red tape (IIRC document licenses for each file individually) and months of no visible progress when comments were addressed.
This was in stark contrast to e.g. contributing to nixpkgs. Do a PR on GitHub. The package gets built automatically by CI. Get feedback. Make changes to address the feedback. And it gets merged. Of course, PRs sometimes go stale (most projects are dealing with a lack of manpower), but the process is generally fast.
But the outcomes are radically different: I never attempted to contribute to Debian again, but I have become an active contributor to nixpkgs.
I think to attract developers the process needs to be modernized. Put all the package definitions in a Gitlab monorepo. Build each PR in a sandbox on CI. Describe the submission process on a single page.
The processes are a legacy of distributed development in the era of dial-up internet. No always-available services, no github, not even any requirement for version control. With every package being maintained independently. While most packages do now use version control, every package has the potential to use a different system, and internally could use a different set of tools to do the actual packaging work.
If you were to design the .deb packaging workflow today, you'd do it very differently. You would probably have a single, or much smaller, set of source repositories, and you would have a single tool to do all the core packaging work.
You only have to look at the BSD Ports, MacPorts, Homebrew, vcpkg, and other software collections to appreciate how extremely complex the Debian approach is, and how the other systems benefit from a strictly standard set of functions to do their job, making all packages uniform and easy to work on.
On the other hand, because of these considerations, Debian has vastly better support for complex versioned dependencies, and the SAT solver in apt is best in its class. The other systems manage the collection as a whole and don't need to care to the same extent.
So I would agree some modernisation wouldn't go amiss. But it's difficult to accomplish that when you have a 25 year legacy of doing it a completely different way. And you have over 20000 packages to fix.
Debian cares a lot more about licensing than Nix. Debian also has far more developers than Nix, I imagine, and processes that have probably existed for longer than GitHub itself.
Back when I was eager to join they still had this ridiculous several month or 2 year long process to get in, so after reading a few accounts of that I said screw it and never even tried again, even when they changed that. I guess I wasn't the only one, and in the end I joined other projects where contributing was fun and easy. (And yeah, I'm neither someone to start projects nor spending consistent time every week, but that doesn't mean you can't contribute lots of time).
Still a happy Debian user after all these years, but I'm past the time where I'd spend effort to even try to join.
This was in stark contrast to e.g. contributing to nixpkgs. Do a PR on GitHub. The package gets built automatically by CI. Get feedback. Make changes to address the feedback. And it gets merged. Of course, PRs sometimes go stale (most projects are dealing with a lack of manpower), but the process is generally fast.
But the outcomes are radically different: I never attempted to contribute to Debian again, but I have become an active contributor to nixpkgs.
I think to attract developers the process needs to be modernized. Put all the package definitions in a Gitlab monorepo. Build each PR in a sandbox on CI. Describe the submission process on a single page.