Simple Workflow for submitting packages
I'm not convinced that #391 is the best way for package submission to work. It might help for more regular developers who need to be able to edit repository metadata (even outside of profile changes, noting the issues mentioned in #391), however for a user who is less familiar with the system, the potential for associated problems may outweigh the benefits.
What might be better is to have users create a local repository which just contains their new packages, and a tool which tests them and submits them to the main repository. The trouble is that this is complicated and might require a custom server listening to incoming requests.
However, one way that it could be done with existing remote infrastructure might be to have a tool which automatically copies the package to submit to the user's local version of the repository, creates a branch for it, commits the changes, and pushes it to their fork, which it could create if needed (and gitlab itself will display the link for the merge request, but it should also be possible to create it through the API). Subsequent runs of the same tool could update the existing branch if the user makes changes.
All it would need from the user is their gitlab username, and for them to choose between git and https authentication (where the latter should prompt the user for their credentials automatically). Other information such as the gitlab project could be inferred from the repository's sync_uri.
It would probably be helpful for this to be a gitlab-specific tool, rather than a pure git tool, so that it could also handle creating the fork and merge request, but a pure git version would also be possible if you provide it with the location of your fork and rely on the submission message produced by pushing to the fork to generate a link the user can click to create the merge request.
If it's just a pure-git version with minimal testing, it could be integrated into inquisitor for a convenient builtin tool. But I don't like the idea of adding a dependency on CI-specific tools like black and flake8 since the repository's CI checks may change independently of portmod. Both could also be possible, with an external tool building off the builtin one to add additional features.