Hi Aleks, My main concern is that command processing requires someone who is highly familiar with the Fineract codebase. It will inevitably touch many parts of the codebase. And a dedicated mentor (who is at least a committer) who can guide candidates on how to approach the codebase and resolve their concerns. If anyone is willing to volunteer as a mentor, I have no problem with that. If you have a recommendation for someone who can guide a candidate for this that would be great.
While in general gsoc discussion is early. I think it is better this way. It will give the community enough time to review gsoc efforts and manage expectations early. This will ensure contributors keep discussions public rather than repeatedly direct messaging any PMC member or potential mentor. On Fri, 6 Nov, 2026, 8:43 am Aleksandar Vidakovic, < [email protected]> wrote: > Why not command processing? I would argue that we should really make an > effort to address even more of the technical debt (hint: new ticket in that > category "type safe queries" FINERACT-2022)... and the new command > processing is addressing a lot of it... I will circle back soon on the > idempotency feature to get the most pressing thing out of the way. In > general I'd say the whole discussion about next year's GSoC is a bit early, > isn't it? > > On Thu, Nov 5, 2026 at 2:29 PM Aman Mittal <[email protected]> > wrote: > >> Hi, Personally I recommend to not considering command framework for >> upcoming gsoc unless any committer actually wants to mentor this. And some >> ongoing PRs are still yet to merge. (It also affect the core fineract so we >> will be very careful in this one) Any core fineract idea must have PMC >> approval and dedicated committer as mentor. >> >> You can consider other fineract side projects. >> >> Regards >> Aman >> >> >> On Thu, 5 Nov, 2026, 6:22 pm Ádám Sághy, <[email protected]> wrote: >> >>> Hi >>> >>> The real reason why the new command framework is not targeting these >>> endpoints are the missing capabilities which are not addressed yet: >>> >>> - idempotency handling >>> - maker-checker >>> - etc >>> >>> >>> Regards, >>> Adam S >>> >>> On Nov 5, 2026, at 12:28 PM, Abhishek Chaudhary < >>> [email protected]> wrote: >>> >>> Hi all, >>> >>> While looking at Savings for GSoC 2027 ideas, I noticed that the 2026 >>> GSoC page excluded the loan and savings packages from the >>> command-processing project "to prevent interference with Pepper Soup >>> efforts": >>> https://cwiki.apache.org/confluence/spaces/FINERACT/pages/421958555/GSOC+Summer+2026 >>> >>> While searching on "what pepper soup is" (I thaught it was a phrase), I >>> stumbled on 2024 Mifos post ( >>> https://mifos.org/blog/pepper-soup-enhancements/) and got to know >>> Pepper Soup as sponsored upstream work focused mainly on loans, COB and >>> performance. >>> >>> I had two questions: >>> 1. Is that work still ongoing, and does its current scope include >>> Savings, for example the Savings COB work in >>> https://issues.apache.org/jira/browse/FINERACT-2332? >>> 2. Would stability work on Savings interest posting, such as tests and >>> bug fixes, be open to a GSoC 2027 project, or should GSoC stay clear of >>> that area? >>> >>> Thanks, >>> Abhishek >>> >>> >>>
