I've moved this from peer review (it's best used when "others" want to request review / approval from you, the component leader) to submit for integration (when you, the leader, decide something is ready to land, both own fixed bugs and reviewed from others).
So then we, the integrators, review the code once again and it goes trough the complete process, ending with the fix included upstream.
That way, the dev that did the fix is always correct in the tracker, and each person has its correct role.
So, basically, you, as maintainer of the lti component will:
- receive automatic inform of any ims-lti issue created (being set as default assignee).
- fix issues and send them to integration
- receive peer-requests from other devs and decide if the work requires more work or it's ok, so you'll send it to integration.
Note that the "send to integration" step requires you to fill a bunch of info (repo, branch, diff) and testing instructions. If any of them is missing, surely you'll see your issues rejected immediately (not now, lol, don't worry, but after some weeks).
I've updated the required fields for this issue myself (and will do for the rest of lti-ones existing until now, no problem). Just try to get used into the "send to integration" workflow step. As said, it's the one that you, as maintainer, will be using more.
And let use the peer-review one for asking the you (others will ask you about ims-lti ones and or you will look periodically for ims-lti issues in "peer review requested" status). Of course, if, for example you fix one glossary issue (you are not maintainer of), you will use that workflow step to ask for peer-review to the glossary maintainer (me). But within your component, you're God (and good). You validate fixes from the rest (peer-review) and you send them and your own straight to integration review.
Hope this clarifies a bit how each role is involved in the process... ciao