Contribution process too complex

[hoijui]

I am an Open Source dev since 22 years, and I only do OS, and this is the most complex contribution process i have come along in all those years. While I can imagine projects, where this could make sense in some way, it definitely does not for this tool. It is technically quite simple, and an essential part are the many tiny contributions by people adding new formats. In my eyes, this has to be super simple, and it is far from it. I remember it being on the upper limit of acceptable complexity about 1.5 years ago, but it has taken a turn for the worse, and now clearly crossed it.

My user-story:
I wanted to add comment support for a new file-name. I had done that in the past, so I knew it will be just adding a single line in the code, and so it was. I checked if I need to sign-off the commit, as I remembered that some projects require it, and that this project had stricter rules for commits/PRs then most others I know. I saw in the history that commits are signed-off, so I did that. In my mind, I was now ready to make the commit and PR; good so far.
I tried to commit, and got an error about pre-commit not being found. I tried to fix that, which in the end meant I had to delete the venv I had there. There was more python ordeal involved in that, but I will leave that out for now, as it is not under REUSEs control or responsibility.
I also looked for instructions in the README for how to commit/PR, and found the commit-hook section, but after reading it, figured it is not for what I need, but rather for using the tool on my project. I continued looking for other files in the repo, and decided to read CONTRIBUTING.md. There I found what I needed to do. I saw it is more involved now, with me having to create a new file describing my change-log for the change-log (I decided on changelog.d/added/style_yapf.md). I did so, according to how I understood the instructions.
At some point I found the instructions for poetry (install & install pre-commit), and after that, pre-commit was found.
The checks failed, with a note about prettier having failed. It did not say why or how it failed, but that it rolled back the changes. I checked, and indeed, there were no changes to the sources. So I had to figure out a way to find out what this tool did not like. I figured that I must be able to run it through pre-commit, so I ran pre-commit --help. There it shows a run sub-command. I was looking for exactly this word, but somehow overlooked it in the whole output (my bad). I did a web-search and found out about run in this way. I ran pre-commit run prettier --help. The output was too large, so I just tried running it with pre-commit run prettier. It failed as before, without helpful output, and the sources did not change either, so I looked at its --help again, and figured that --show-diff-on-failure could be useful, so I ran pre-commit run prettier --show-diff-on-failure, and ... yuhu! It showed me the problem! apparently, the change-log line in my changelog.d/added/style_yapf.md file was too long, so it needed to be wrapped or shortened. I did that, and .. the commit succeeded!!
I went along to push to my fork of the repo on github, and then to create the PR. In the PR template I saw, that I am missing yet two other steps:

• Added self to copyright blurb of touched files.
• Added self to AUTHORS.rst.

And that was it for me. I could not take it anymore, and gave up the whole idea of making this contribution.

Please... make it more simple!
Lots of this stuff can be automated, making life much simpler for contributors.
Change-logs can be generated form commit messages, authors can be aggregated from commit meta-data and the files the commits touched, and the author info of files can be edited by scanning the git meta-data, and feeding it to your very own reuse-tool (I am actually doing that in a small tool I wrote: reuseify). This stuff can be run before a release, for example. I took the time to write this all down, because I really like this tool, and think it is important to have. I also see, that it could serve as a blueprint for many other projects, and as such I think it is important it is done well. In some way it is, but this complexity ... If seasoned OS devs give up, I am sure many others do too, and it is also waste of precious life-time of people doing good stuff.
Thank you for your efforts, and all the best!