...
While we definitely want help with maintenance tasks, there are a few guidelines to keep in mind when choosing one in order to minimize the amount of frustration for all parties involved:
Some experience required. The teams creating these tasks and reviewing code contributed for them aren’t set up to mentor people with almost no relevant experience. Junior developers are welcome, as long as they have successfully made similar contributions in the past (not necessarily in Open edX). But people still learning how to create their first pull request will probably just get frustrated until they master that skill in a more beginner-oriented context.
Find a task. Here is a search query for all unassigned open maintenance tasks.
Request assignment. When you’re ready to immediately start work on the issue, assign the issue to yourself if you already have sufficient permission to do so, but in most cases you’ll need to comment on the issue to request that it be assigned to you. This may not be explicitly reflected in the “Assignee” field of the issue depending on the repo’s permissions, but at a minimum the request indicates to other interested individuals that the task is already being worked on.
Describe the changes. The PR description doesn’t need to be an essay, but it should give context about why these particular changes are being made this way. And definitely make sure to include a link to the maintenance issue that the PR was made in response to.
Request unassignment when appropriate. If something comes up and you’re unable to make progress on the task for a week or more, please state that on the original issue so it doesn’t become indefinitely blocked on you. If you have an in-progress PR and followed the advice above, there should already be a link to it in the issue history from when you mentioned it in your PR’s description.
Get checks to pass before requesting review. With rare exceptions, a failing check on a pull request is a good indication that something needs to be fixed before it can be merged. Please resolve such failures if at all possible before requesting review, so the reviewer doesn’t have to spend time pointing out the failures and deciding if it’s even worth looking at the changes any further yet.
Request review when done. Once you’ve finished the task and checks are passing, ask for review via the mechanism requested in the maintenance issue. If the issue author neglected to specify one, try @-mentioning their username in a comment on the PR to get their attention.
...