Developer experience
very important!
gradle tasks are complex
hard to figure out even just how to run Fineract, how to know it is healthy
goals for releases
( consider these value-driven goals first, then get to improvements, ideal frequency, automation )
stable, reliable, frequent, well-documented
avoid vendor lock-in, leverage open source, release from any platform
reproducible?
current
complex and manual
robust and inefficient
large codebase, gradle tasks, project & roadmap management, ASF policies
proposed and in-progress work and other notes
understand, simplify, standardize, automate
test/evaluate ATR (Apache Trusted Release) tool
policy/culture improvements to ease releasing
keep develop clean: be careful with WIP code/features
maintain your issues
improve documentation and release plugin, or shift to other automation
we don’t currently maintain releases, vendors could do this
what is ideal release frequency? depends on type of fix … we may need/want to differentiate between major, minor, patch/hotfix releases (e.g. full ceremony doesn’t make sense for a hotfix)
RAW notes from Fireflies AI :
The meeting confirmed that improving instructions, documentation, and developer experience remains the top priority to sustain and grow community involvement (06:36).
Adam Saghy emphasized that better documentation and developer experience are crucial for attracting and retaining community members, as these affect both developers and potential users (06:52).
Clear instructions help new contributors understand the project, which currently feels overwhelming due to complex architecture and dependencies, as noted by Kapil Panchal (08:59).
Kapil highlighted the need for comprehensive onboarding materials clarifying the application’s architecture and dependency usage to reduce confusion.
Felix van Hove is working on improving the README file to enhance first impressions and reduce outdated or poorly structured documentation, though he views it as a partial step toward better developer experience (10:14).
The group acknowledged that improving documentation and developer experience is foundational, with fuller efforts needed beyond readme updates.
The project’s release process is robust but complex and inefficient, with a need to improve project management and cultural practices around issue tracking to speed releases without sacrificing quality (14:30).
Adam Monsen detailed that releases must be stable, reliable, frequent, and well documented, but current manual steps and cultural issues slow the process (14:30).
Key blockers include thorough JIRA ticket management and ensuring all release criteria are met, which currently demands significant manual triage and voting steps.
Adam proposes documenting and simplifying release steps, standardizing tooling, and automating processes after understanding the workflow fully, including exploring the Apache Trusted Release tool (17:45).
The current minimum release cycle is constrained by a 72-hour voting period, setting a practical lower bound on release speed (26:34).
Adam Saghy confirmed recent improvements in JIRA ticket management reduced the typical release time, making regular releases every three to six months manageable (22:12).
He suggested further improvements could reduce the current 17-day total release timeframe.
The team discussed differentiating between full releases and urgent security patches, where security fixes can be released with a shortened voting process requiring only three PMC member votes plus one (28:24).
This allows security patches to be delivered within hours, addressing critical CVEs faster.
However, legacy releases beyond two versions back will be end-of-lifed due to limited community resources, with vendor support encouraged for older versions (31:36).
The group reinforced that all official discussions and decisions must be brought back to the mailing list to maintain transparency and project history (33:45).
James Dailey stressed that while informal discussions can happen on Slack or external forums, important decisions must be summarized and posted on the official Apache mailing list for record-keeping and community awareness.
Ed Cable supported this approach, noting it balances accessibility with minimizing noise and keeping official records clear (34:47).
Encouragement was made for community members to publicly acknowledge and reinforce positive behavior when conversations are successfully brought back to the list.
The project’s mantra “If it didn’t happen on the list, it didn’t happen” was affirmed to preserve accountability and ensure all community members can follow key decisions.
The project aims to be a modular, performant, and scalable core banking backend serving fintechs, community banks, and microfinance institutions, with flexible integration for complex loan terms (40:00).
This vision was broadly supported, with Terence Monteiro agreeing it covers about 90-95% of the project’s goals (42:03).
Discussion revealed the need to explicitly include deposit and current account functionality, as some users require scalable current accounts beyond lending products (42:44).
Adam Saghy detailed key roadmap priorities:
Modularization remains a critical but challenging goal, expected to improve deploy times, reduce security risks by narrowing deployed components, and ease maintenance (47:46).
Transitioning from UUID to a more efficient primary key generation is the second priority to reduce complexity and improve performance, though it requires a major migration effort (50:06).
Supporting fewer but better-tuned database engines by dropping MariaDB and MySQL could improve software tuning but demands careful user communication due to current user base reliance (50:40).
Additional requested features include co-lending, revolving lines of credit, and treasury management, which would expand market appeal (52:20).
Ashok Auty, drawing from industry experience, supported modularization and UUID improvements as essential for fintech users and noted co-lending is gaining traction in India, indicating strong market demand for this feature (53:07).
Scalable current accounts are particularly needed in African markets to supplement limited savings account offerings (54:44).
David Higgins recommended focusing development efforts on a core nucleus of four to five features that have broad community buy-in to avoid feature drift and improve delivery focus (57:22).
The project places high priority on security and code quality, with responsibility shared between the project and vendors for deployment security and compliance (43:25).
The project maintains security-by-design principles, including CVE fixing, dependency scanning via Dependabot, and auto scanning tools, with responsibility for operational security resting on implementers (44:57).
Logging, role-based access control, OAuth, and field encryption are key features that must be embedded at the project level to ensure compliance with regulatory requirements (44:57).
Terence Monteiro highlighted that increasing test coverage is essential to boost release velocity by giving release managers confidence in quality, especially as project complexity grows (01:00:17).
The group agreed on the need for timely security fixes, better documentation, easier developer setup, and thorough test coverage to support growth and project maturity (01:00:50).
The community is experiencing increased participation and interest, requiring careful management to maintain quality and momentum (59:00).
James Dailey proposed holding community meetings a couple of times per year, with the next planned for February, to align members and track progress without overburdening contributors (01:00:00).
Improved expectations around release robustness and quality are expected to attract and retain more contributors, supporting sustainable growth (59:30).
The community was encouraged to use the Fineract Significant Improvement Proposal (FSIP) process to focus development efforts and clarify priorities (01:00:04).
Action items
Introduce yourself in chat sidebar with name and location for community awareness (01:10)
Review and discuss mission statement wording on mailing list to confirm or propose changes (37:20)
Organize next community meeting in approximately February for continuity and community engagement (01:00:00)
Continue documenting, simplifying, standardizing, and automating the release process according to ASF policies; Evaluate Apache Trusted Release tool and report findings (14:30)
Review and provide feedback on proposed branching and merging strategy for releases on mailing list (16:30)
Implement expedited voting and release procedures for security fixes as per Apache’s adjusted guidelines (28:00)
Support only the last two releases with security patches; older releases to be archived and discontinued; vendors may choose to maintain legacy versions commercially (31:30)
Ensure all key discussions that occur in external forums (Slack, conferences) are summarized and brought back to the Apache mailing lists for official archiving (33:30)
Prioritize improvements on modular architecture and UUID key refactoring as key performance and maintainability upgrades (47:30)
Discuss database engine roadmap, especially potential MySQL and MariaDB removal, ensuring vendor/user communication plans (52:00)
Focus roadmap on a prioritized nucleus of core features to ensure focused development and avoid dilution (57:00)
Provide further detailed feedback on release cycle challenges and testing improvements on mailing list (01:00:17)