Hi Aleks, I completely agree with the spirit of learning through challenging problems, if a committer steps up with the bandwidth to mentor, having it on the ideas list is fine by me. (This is based on our previous gsoc experience)
Regarding parking this, candidates enquire early every year regardless of ASF timelines. Leaving things undefined often leads to folks trying to "block" or reserve tickets prematurely under the guise of future GSoC projects, which we definitely don't want. Regular backlog tickets should remain open for anyone to pick up anytime. To help manage these early expectations publicly, I drafted proposed guidelines here: (I also communicated earlier on the dev list) https://cwiki.apache.org/confluence/spaces/FINERACT/pages/451979814/PROPOSED+Google+Summer+of+Code+GSoC+2027+Guidelines+%E2%80%94+Apache+Fineract They are built directly as an extension of ASF ComDev practices and can be adapted as needed (regardless of whether ASF participates or not). Giving candidates a clear public reference early prevents the usual direct pings and makes it clear that normal ticket progress isn't tied to or blocked by GSoC. // (I think i should be more direct about the possibility of outright cancellation) will update soon PS.: I am open to suggestions on this. Maybe we can try coordinating on this. (I would like to try avoiding mistakes that we made in GSoC 2026). I would not like to burden both the Mentor and the Contributor. Regards, Aman On Fri, Nov 6, 2026 at 1:24 PM Aleksandar Vidakovic < [email protected]> wrote: > ... sure there might be some difficult parts... but still don't see the > point... I assumed the whole idea of GSoC is to learn something? Not sure > how you learn by tip-toeing around the difficult parts... I thought some > resistance is needed to learn. And even if they fail... still don't see a > problem there... still a great opportunity to learn. And finally: all PRs - > GSoC or not - are reviewed... and we have tests all over the place. I say > let them try... but again, I think it's early... Do we know if we get > accepted? If not - can happen - then all this effort for nothing... until > then I think there is enough work to do... so let's pick tickets. > > On Fri, Nov 6, 2026 at 4:49 AM Aman Mittal <[email protected]> > wrote: > >> 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 >>>>> >>>>> >>>>>
