You being “too n00b” doesn’t much matter here.
The most important abilities for a maintainer to have are the ability to assert that the package still works after some change and being responsive.
The less important ability is to update the package yourself. That should be fairly easy in most cases as it’s usually an incremental thing; requiring just an update on version and hash. Sometimes it’s more complex but if you’re willing to figure stuff out in order to get it updated, your current experience level is pretty unimportant here. If it took you a day to figure out how to update, you’d still be faster than 90% of us. Don’t stress it.
If you really can’t do that, that’s not too bad either, you’d still be more valuable than 70% of maintainers I come accross (or rather not come across) simply by being responsive. If someone else updates your package and I as a committer come across the PR and see your approval stating that you tested it to be working, I’m merging it (assuming there were no code crimes committed in the diff).
The “easier” way would be to copy the dropped code into a file in your local dev env and pkgs.callPackageing it; vendoring the derivation.
I just finished setting up version 9.3.0 for myself over the weekend. I’m a noob, so I’m sure others might look at it and scratch their heads at some choices I made, but it is functional, as I’m using it to index emails from Dovecot. I’ll see if I can post it somewhere if you want to look at the nix files.