Thanks for the comment, *James*. I already tried to do that in the following PRs #3766, #3777, and #3788.
However, regarding getting involved, I couldn't figure out the full application flow and responsibilities for each package. > e.g. *ClientMapper.java* exists in the *provider* module and it maps > between *Client.java* entity and *ClientData.java*, but those files are > placed in the *core* module. If there's any reference to understand the responsibilities of each module, category, and package I would appreciate it. Thanks! On Tue, Mar 12, 2024 at 5:00 PM James Dailey <jamespdai...@gmail.com> wrote: > I’d also suggest that one gets involved in reviewing other people’s PRs… > that makes it collaborative. > > > On Tue, Mar 12, 2024 at 7:52 AM Zeyad Nasef <zeyad.nasef....@gmail.com> > wrote: > >> Great, thanks a lot Ádám >> >> On Tue, Mar 12, 2024 at 11:24 AM Ádám Sághy <adamsa...@gmail.com> wrote: >> >>> Hi >>> >>> Usually I do 2 things: >>> - Just before the PR I am executing: ./gradlew spotlessApply >>> spotbugsMain spotbugsTest checkstyleMain checkstyleTest -> its doing the >>> formatting and do some static code analysis >>> - Just before the PR I pull the latest from the develop with git rebase >>> and check was there any conflict and ensure i am on the latest version. >>> >>> If both of them done and “green", I am raising the PR. >>> >>> Regards, >>> Adam >>> >>> On 11 Mar 2024, at 21:44, Zeyad Nasef <zeyad.nasef....@gmail.com> wrote: >>> >>> Hey everyone! When tweaking Fineract, I typically ensure style >>> consistency, run the project, and then submit a PR for review, with GitHub >>> actions running necessary tests. Wondering if there's a smoother way to >>> prevent conflicts. If anyone has experience, please share your workflow >>> from making changes to merging into the main develop branch. >>> >>> Thanks! >>> >>> >>>
