fineract-doc/modules/contributor/pages/submitting-a-pull-request.adoc - fineract - Git at Google

 == Submitting a Pull Request

 We encourage all community members to contribute actively to the upstream Fineract codebase. All contributions come in the form of a pull request referencing a JIRA ticket outlining the intent of the contribution.

 We request that your commit message include a FINERACT JIRA issue, recommended to be put in parentheses at the end of the first line. Start with an upper case imperative verb (not past form), and a short but concise clear description. (E.g. Add enforced HideUtilityClassConstructor checkstyle (FINERACT-821) or Fix inability to reschedule when interest accrued larger than EMI (FINERACT-1109) etc.).

 If your PR is failing to pass our CI build due to a test failure, then:

 ** Understand if the failure is due to your PR or an unrelated unstable test.

 ** If you suspect it is because of a "flaky" test, and not due to a change in your PR, then please do not simply wait for an active maintainer to come and help you, but instead be a proactive contributor to the project - see next steps. Do understand that we may not review PRs that are not green - it is the contributor's (that's you!) responsability to get a proposed PR to pass the build, not primarily the maintainers.

 ** Search for the name of the failed test on https://issues.apache.org/jira/, e.g. for AccountingScenarioIntegrationTest you would find FINERACT-899.

 ** If you happen to read in such bugs that tests were just recently fixed, or ignored, then rebase your PR to pick up that change.

 ** If you find previous comments "proving" that the same test has arbitrarily failed in at least 3 past PRs, then please do yourself raise a small separate new PR proposing to add an @Disabled // TODO FINERACT-123 to the respective unstable test (e.g. #774) with the commit message mentioning said JIRA, as always. (Please do NOT just @Disabled any existing tests mixed in as part of your larger PR.)

 ** If there is no existing JIRA for the test, then first please evaluate whether the failure couldn't be a (perhaps strange) impact of the change you are proposing after all. If it's not, then please raise a new JIRA to document the suspected Flaky Test, and link it to FINERACT-850. This will allow the next person coming along hitting the same test failure to easily find it, and eventually propose to ignore the unstable test.

 ** Then (only) Close and Reopen your PR, which will cause a new build, to see if it passes.
 Of course, we very much appreciate you then jumping onto any such bugs and helping us figure out how to fix all ignored tests!

 ** Pull Request Size Limit documents that we cannot accept huge "code dump" Pull Requests, with some related suggestions.

 Guideline for new Feature commits involving Refactoring:

 [attributes]
 ....
 If you are submitting PR for a new Feature, and it involves refactoring, try to differentiate "new Feature code" with "Refactored" by placing them in different commits. This helps review to review your code faster.
 ....


 We have an automated Bot which marks pull requests as "stale" after a while, and ultimately automatically closes them.


 The steps below are part of our Github pull request template as a checklist while submitting. Don't treat this as mere boxes to tick off but rather ensure you're following each step so your PR doesn't get rejected and it can merged in a timely manner:

 ### Description

 Describe the changes made and why they were made.

 Ignore if these details are present on the associated [Apache Fineract JIRA ticket](https://github.com/apache/fineract/pull/1284).


 ### Checklist

 Please make sure these boxes are checked before submitting your pull request - thanks!

 - [ ] Write the commit message as described above
 - [ ] Acknowledge that we will not review PRs that are not passing the build _("green")_ - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.

 - [ ] Create/update unit or integration tests for verifying the changes made.

 - [ ] Follow coding conventions as described xref:coding-conventions.adoc[here]

 - [ ] Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes

 - [ ] Submission is not a "code dump".  (Large changes can be made "in repository" via a branch.  Ask on the developer mailing list for guidance, if required.)
	== Submitting a Pull Request

	We encourage all community members to contribute actively to the upstream Fineract codebase. All contributions come in the form of a pull request referencing a JIRA ticket outlining the intent of the contribution.

	We request that your commit message include a FINERACT JIRA issue, recommended to be put in parentheses at the end of the first line. Start with an upper case imperative verb (not past form), and a short but concise clear description. (E.g. Add enforced HideUtilityClassConstructor checkstyle (FINERACT-821) or Fix inability to reschedule when interest accrued larger than EMI (FINERACT-1109) etc.).

	If your PR is failing to pass our CI build due to a test failure, then:

	** Understand if the failure is due to your PR or an unrelated unstable test.

	** If you suspect it is because of a "flaky" test, and not due to a change in your PR, then please do not simply wait for an active maintainer to come and help you, but instead be a proactive contributor to the project - see next steps. Do understand that we may not review PRs that are not green - it is the contributor's (that's you!) responsability to get a proposed PR to pass the build, not primarily the maintainers.

	** Search for the name of the failed test on https://issues.apache.org/jira/, e.g. for AccountingScenarioIntegrationTest you would find FINERACT-899.

	** If you happen to read in such bugs that tests were just recently fixed, or ignored, then rebase your PR to pick up that change.

	** If you find previous comments "proving" that the same test has arbitrarily failed in at least 3 past PRs, then please do yourself raise a small separate new PR proposing to add an @Disabled // TODO FINERACT-123 to the respective unstable test (e.g. #774) with the commit message mentioning said JIRA, as always. (Please do NOT just @Disabled any existing tests mixed in as part of your larger PR.)

	** If there is no existing JIRA for the test, then first please evaluate whether the failure couldn't be a (perhaps strange) impact of the change you are proposing after all. If it's not, then please raise a new JIRA to document the suspected Flaky Test, and link it to FINERACT-850. This will allow the next person coming along hitting the same test failure to easily find it, and eventually propose to ignore the unstable test.

	** Then (only) Close and Reopen your PR, which will cause a new build, to see if it passes.
	Of course, we very much appreciate you then jumping onto any such bugs and helping us figure out how to fix all ignored tests!

	** Pull Request Size Limit documents that we cannot accept huge "code dump" Pull Requests, with some related suggestions.

	Guideline for new Feature commits involving Refactoring:

	[attributes]
	....
	If you are submitting PR for a new Feature, and it involves refactoring, try to differentiate "new Feature code" with "Refactored" by placing them in different commits. This helps review to review your code faster.
	....


	We have an automated Bot which marks pull requests as "stale" after a while, and ultimately automatically closes them.


	The steps below are part of our Github pull request template as a checklist while submitting. Don't treat this as mere boxes to tick off but rather ensure you're following each step so your PR doesn't get rejected and it can merged in a timely manner:

	### Description

	Describe the changes made and why they were made.

	Ignore if these details are present on the associated [Apache Fineract JIRA ticket](https://github.com/apache/fineract/pull/1284).


	### Checklist

	Please make sure these boxes are checked before submitting your pull request - thanks!

	- [ ] Write the commit message as described above
	- [ ] Acknowledge that we will not review PRs that are not passing the build _("green")_ - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.

	- [ ] Create/update unit or integration tests for verifying the changes made.

	- [ ] Follow coding conventions as described xref:coding-conventions.adoc[here]

	- [ ] Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes

	- [ ] Submission is not a "code dump". (Large changes can be made "in repository" via a branch. Ask on the developer mailing list for guidance, if required.)