This page covers the regular cases may occur developing JIRA tickets. This is not a full-scale development guide, just describes usual states and actions through which JIRA ticket should pass.

		User story (development work)	Tech design (design work)	Spike (research work)
Before starting the development		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.
Development		On this stage main development is considered to be done and we will prepare the changes for code review
Development		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.	design documentation is ready and available for review (in the cloud or Confluence); PoC is ready and available for review; (pushed into the 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.
Code review	On this stage changes are prepared for review, but not shared and not reviewed
	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 documentation and ask your teammates to make code review; fix comments;	present your results to the team and ask your teammates to make code review; add changes according to comments;
	external	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).	ask your PO to schedule a call to present and discuss documentation with FOLIO community; apply changes requested in comments; leave a comment in Jira with the link to your results.	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.
Review		On this stage changes are shown to the PO assign your Jira ticket on your PO and move to the “In review state”;
Final round		Demo your story to the FOLIO community on the general demo event, that usually happens once a month.
Pre-Merge Checklist:		- 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 - NEWS.md is up-to-date - Changes are tested on local machine - 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.

Browser not supported