That's great! Find an open issue, familiarise yourself with the Code of Conduct and Contributor Guidelines and we look forward to your pull request. This document is more for the core team to share how we schedule tasks for a release, how we keep up to date with who's working on what, that sort of thing.
Issues that are planned to be in a particular release should be attached to that milestone. We never hold up releasing a fix because it's waiting for the next milestone: if it's in main, it'll go live soon. The milestones are there to help us understand what's urgent, and what can wait.
Priorities tell us what's important, and there are three levels: P0 is on fire, P1 is smouldering a little, P2 would be nice to have. These are labels that can be attached to issues.
If you're working on an issue, please assign yourself to it. If nobody is working on issue (for example it's newly-added), there should be no assignees. The corollary is that if there are assignees, we might assume somebody else is working on it and not pick it up ourselves, with the result that it never gets done.
We did try using a Github project board to track this stuff but found that it wasn't sufficiently up-to-date to be useful, so we're abandoning it. Our colleagues at HTD are very good at keeping their project board up to date, so we'll assume that anything on that board is being worked on by them.