Requesting for review
Using the github review request system can help other developers understand when a pull request is already getting review attention, and avoid doubling-up of work. In order to ensure everyone knows what it means when a review is requested, we follow some rules:
When requesting a review from others:
- If you have made a change which requires expedited review but it doesn't matter who is reviewing it, request review from
ppy/team-client.
- If you believe a specific person they will be able to handle the review more efficiently than others, ie. if they are the "code owner" or majority contributor of a specific area of the codebase.
When requesting a review of yourself:
- Do so when you actively start reviewing a pull request. Remove the assignment if you abort the review.
- Even if not immediately reviewing, it is fine to do so when you strongly request that you are able to review before merge.
When receiving a review request from others:
- If a review was requested of you but you don't think it was correct, remove yourself
- Optionally request review from
ppy/team-client if it needs someone's attention
- Optionally comment explaining why you aren't going provide a review
Preparing pull requests for changelog
At the end of a release cycle, peppy goes through all changes since last release to re-categorise and rewrite things to be parseable by an end user.
Any developers can help with this process via the following means:
Add a user-facing description of the change
In the opening post of a pull request, add a section to the top of the description separated by a --- line separator which should be shown to the user (example here).
- This section can include images or video.
- Leave all original content below the line separator, unless it was copied above.
- If the existing description already reads well for an end user, it's fine to just leave it in place. If there's no
--- separator the whole post will be copied verbatim.
Mark notable changes
In the changelog, major changes are highlighted to the user with larger text and a yellow header. These can be marked by anyone with triage permissions by adding the notable feature tag.