Skip to content

Team processes

Dean Herbert edited this page Jan 16, 2025 · 3 revisions

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.