* PR Description Template *.md

Pull Request Description Template

Overview

• This gist contains a PR description template.

• Copy its content to your PRs and replace all TODOs with useful information (Scroll to the bottom to see its preview).

• Depending on the complexity of the PR some sections may be completely skipped. Make a decision based on your experience.

• ❗Cards, How it was tested? and Self-review Checklist sections are always mandatory❗.

Examples

• Support Ruby 2.7 and higher.

• CS-41: Support alias when importing from containers.

• CS-44: Use tally method to count in contain_exactly.

*This PR description template is a live document, which is why the old examples may have slightly different structure.

template.md

Cards

• Required TODO: Links to Jira, Trello, Redmine tickets, etc. Please, each link in a separate row.

❗❗❗ Attention ❗❗❗

• Optional TODO: DB schema changes, new seeds, new feature toggles, new ENV variables, translation checks, load testing requests, configs updates, CI changes, valuable release notes, and so on...

Related PRs

• Optional TODO: PRs for the same task from other repositories, relevant previous PRs for better context sharing, integration branch PR, and similar stuff.

What was done as a part of this PR?

• Optional TODO: May be skipped if PR's title already describes the intention, but this section is especially useful for changes with more than 10 modified files.

Why it was done?

• Optional TODO: Convincing arguments why this PR is important. Who and how will receive a benefit from it?

How it was done?

• Optional TODO: Sometimes the same problem may be solved using different approaches. Here is the best place to document the selected solution in comparison with the pros and cons of the alternative techniques.

How it was tested?

• Required TODO: Commands to run specs, coverage results, code chucks to execute from a console, toggles to be activated/deactivated, ENV variables, screenshots, videos of the UI, guides on how to access the page where the change is performed.

Notes

• Optional TODO: Anything you think will be helpful for your future self. Literally anything. Please, do NOT limit your imagination.

Self-review Checklist

• The Tell Don't Ask principle is applied whenever it makes sence.

• The Feature Trigger/Handler separation is followed.

• Services are single-responsible, well-named, and have all their operations 100% tested including delegations, logging, and edge cases.

• type ifs are eliminamted whenever it is possible.

• Methods are order-independent.

• Entries are place-independent.

• Reasonable fallbacks are provided for any NOT successful scenarios, in other words, even if the page has bugs, it still allows the client to complete the flow.

• General Code Review Principles are revisited for updates.

*This PR description is based on this gist.