Page Comparison

Make sure your ticket:

• is already estimated and moved into the current sprint;
• is in the "Open" state;
• has a description and it is up-to-date to the comments;
• has clear acceptance criteria in the description;
• is marked by necessary labels;
• is divided into sub-tasks if need;
• All the materials attached needs to be approved by PO/Team/Folio community.

Don't forget to change the state to "In progress" and assign ticket on the corresponding person.

• run unit tests (keep proper code coverage defined in DoD), E2E test for front-end;
• run static code analysers (CheckStyle and SonarLint);
• push your changes into remote repo.

• spike research results are documented (Confluence space);

• don't forget to bind Spike JIRA ticket with Confluence page;

• PoC is ready and available for review (pushed into the repo);

• link to the remote repo mentioned in Confluence documentation.

internal

• prepare good description of implemented changes and approach, JIRA ticket should be included;
• set epam_internal_review label on PR;
• ask your teammates to make code review;
• add changes requested in comments.

• present your results to the team and ask your teammates to make code review;
• add changes according to comments;

• remove epam_internal_review from PR;
• assign corresponding external people on the PR (usually it's an author of the module your changes belong to).

Present your results and findings to the PO (5 mins max):

• if the Spike is more refers to research work and don't have a technical foundation (e.g. applying a brand new UI widget) you should present results to the PO and explain findings it will bring to the project;
• if the Spike is more refers to technical research work (it may be about applying a brand new testing library) - you should present documentation with sample examples and explain benefits, don't dive deep into technical details!;
• leave a comment in Jira with the link to your results;
• you can present PoC from your local env.

On this stage changes are shown to the PO

• assign your Jira ticket on your PO and move to the “In review state”;

- Does this PR meet or exceed the expected quality standards?

  - [ ] Code coverage on new code is 80% or greater

  - [ ] Duplications on new code is 3% or less

  - [ ] There are no major code smells or security issues

- Does this introduce breaking changes?

  - [ ] Were any API paths or methods changed, added or removed?

  - [ ] Were there any schema changes?

  - [ ] Did any of the interface versions change?

  - [ ] Were permissions changed, added, or removed?

  - [ ] Are there new interface dependencies?

  - [ ] There are no breaking changes in this PR.

If there are breaking changes, please **STOP** and consider the following:

- What other modules will these changes impact?

- Do JIRAs exist to update the impacted modules?

  - [ ] If not, please create them

  - [ ] Do they contain the appropriate level of detail?  Which endpoints/schemas changed, etc.

  - [ ] Do they have all they appropriate links to blocked/related issues?

- Are the JIRAs under active development?  

  - [ ] If not, contact the project's PO and make sure they're aware of the urgency.

- Do PRs exist for these changes?

  - [ ] If so, have they been approved?

Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment.  Communication is paramount if that is to be achieved, especially as the number of intermodule and inter-team dependencies increase.  

While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.