Season of Docs - 2024
Unfortunately this year's proposal was not successful in being chosen. However we remain committed to improving our documentation and will look at ways to get community engagement on this year and will be thinking of new proposals for next year.
Technical Writers stay tuned……
Mifos is submitting an application for the Google Season of Documentation in 2024 and we will know on the 10th April if we have been accepted.
We have been gaining valuable feedback on our current documentation from stakeholders across the community and systems implementers and adopters to focus in on what we plan this year.
This years proposal, focus’s on setting new standards for documentation, uplifting 2 of our key projects to these standards (PHEE and MifosX) and creating a sustainable legacy from the project in terms of release documentation standards.
We see this project as key as we grow both in terms of a community and the scope and depth of our projects. It will enable new contributors to onboard quicker, adopters to more easily understand and implement our open-source projects as well as enable some exciting plans we have around AI assisted documentation retrieval, and community support.
Our Proposal
Update Mifos Architectural and Adoption documents.
Update documentation to reflect significant developments in the Mifos open-source projects and move to templates to increase contribution, adoption and sustainability.
About the Mifos Initiative
The Mifos Initiative is a global 501(c)3 fintech non-profit leveraging the cloud, mobile & open-source community to democratize financial services worldwide and digitally transform the world’s 3 billion poor and underbanked. We aim to create a world of 3 Billion Maries where everyone has access to the financial resources needed to create a better life for themselves and their family. Our unprecedented approach unites financial institutions, local technology partners, and volunteer developers to collectively advance open-source banking infrastructure to sustainably build impactful innovations in digital financial services.
We guide the global Mifos ecosystem of partners and volunteers contributing back to the open source Mifos and Fineract platforms. Mifos donated the codebase to the Apache Software Foundation for what ultimately became the top-level project, Apache Fineract. Both Mifos and Fineract have been nominated and selected by the Digital Public Goods Alliance as foundational digital public goods for the Financial Inclusion Community of Practice.
More than 35 million clients supported by 500+ fintechs and financial institutions use our open APIs to power their solution across 65+ countries. They are supported by a global community of 100 deployment partners & hundreds of volunteers.
Mifos is the innovation that powers the innovators by providing a set of open source building blocks that can be composed into financial services of any form. Across the world from grassroots microfinance institutions in rural Africa serving dozens of clients with microloans to government-led banks in Latin America reaching millions to banks in Germany delivering mortgage loans, from digital credit startups reaching hundreds of thousands in West Africa to mobile wallet providers supporting millions in India, to cloud-based core banking systems reaching millions across multiple continents to banking as a service providers enabling neobanks, our open banking stack is transforming the delivery of digital financial service
For the past 15 years, we’ve been at the forefront of transformative technology, building an end-to-end open-source stack for DFS. Our technology stack provides complete banking infrastructure that is cloud-native, mobile-enabled, and scalable to billions that are underbanked. Our stack is a set of Open-Source Lego Blocks for DFS including flexible account management (Mifos X) leveraging Open APIs from Apache Fineract and Fineract CN, integrating with digital payment rails like Mojaloop, delivered via web and mobile apps through Open Banking APIs.
At the heart of our stack is Fineract 1.x, our composable open-source core banking platform that is highly scalable in the cloud and deployable via our reference apps and open APIs. Coupled with our Mifos web app UI on top of these platforms, we provide a flexible account and wallet management system to enable the delivery of any digital financial service. Next in our stack is our Payment Hub EE which provides a gateway and orchestration engine to connect to real-time payment services and interoperable payment rails like Mojaloop and Mobile Money APIs. Think of Mifos as the DNA of financial services that can be put together into many expressions and Mojaloop as the connective tissue enabling low-cost payments across any system. On top of these open-source rails and accounts are reference customer-facing mobile banking and mobile wallet apps which consume our Open Banking APIs and third party PISP APIs. We provide these open-source building blocks of financial inclusion, train and certify a network of partners to build solutions with these building blocks, and support and sustain the collaborative infrastructure and ecosystem for these solutions to be scaled and distributed worldwide.
Documentation audiences across our community include the end users of our software, the staff of financial institutions and fintechs that use Mifos to create customers and their accounts, configure loan and savings products, process transactions and track repayments and deposits, manage their general ledger and generate financial and operational reports. The primary audience of our documentation is our partner community who host, deploy, configure, and support the software for these financial institutions, build new fintech solutions and applications using the APIs, and develop, maintain, and extend the core upstream project which powers their solutions. Joining these partners as part of our developer community are individual volunteers, interns, and corporate strategic partners who collectively guide the development, QA, and release management to ensure timely and high-quality open-source releases of our platform.
About our Project
The Problem.
This project builds off previous work undertaken in the 2021 and 2022 Season of Docs projects. We have made good progress in creating single sources of truth for technical and functional documentation respectively. Technical documentation residing in an ASCII doc auto-generated with each release and functional documentation in Gitbooks. Since that time there have been numerous updates to our projects through upstream contributions from partners and contributors and community contributions such as those of GSOC interns. This has included significant architectural changes to PH-EE (microservices front-end architecture, bulk payment processing capabilities, P2G and Voucher Management capabilities, Identity Account Mapper services). There has also been significant functional and non-functional updates to other projects in part through contributions from in-production customers and from GSOC projects in 2022 and 2023. In addition a brand new behavior-driven development testing framework on Cucumber with 700+ tests has been introduced - documentation of how to run these tests, how to develop new tests, and how these tests fit into our overall QA and development strategy needs to be drafted.
This has meant that our documentation is distributed across a lot of areas and not consolidated in the common format that is easy for new adopters or Systems integrators to pick up and understand, and not representative of our architecture. A typical example may be when explaining to a contributor or adopter a specific issue you will have to say read section 5 of this document factor in the readme of this contribution and look at the slack conversation of this and you will understand how this feature works; rather than just pointing to one place that covers it.
To address this in addition to the creation of specific updated content, we want to reorganize documentation into a standard structure, language and tone, this will enable adopters and contributors to easily be able to understand where to go for information. We also want to implement documentation standards into our future releases, so this is a sustainable fix for the future. On the technical side we need to ensure architectural, deployment, development and design documentation is in place and for functional documentation - high-level, user manual-level as well as specification-level documentation is maintained. This project is seen as a key enabler for doing this.
Specific project goals:
Update Architectural documentation to reflect significant project contributions.
Create a common tone/template/language approach to documentation.
Document significant enhancements to Mifos Projects: PH-EE and Mifos X/Apache Fineract, PISP Mobile wallets. We will concentrate on PH-EE and Mifos X with the technical author and encourage community contributions to documentation on other projects.
Re-organize existing content into these templates.
Set Documentation standards for future releases.
Document our new Cucumber testing framework - how to use, how to write new tests, how to track which new features need new test coverage.
Establish a process for maintaining documentation as new functional and non-functional enhancements get developed.
Specific expected Benefits:
Increased contribution by enabling contributors to get up to speed quickly and easily.
Increased adoption, documentation is a barrier often cited by adopters for not using open-source components. This need not be the case.
Sustainable documentation for the future by introduction of release documentation standards
Reduced community support burden by having features and how to use them properly documented.
Increased adoption through creation of missing documentation:
White Papers on implementation
Standard statements on security/privacy etc
Dependency and Architecture guides.
Installation guides
Clear explanation of Helm charts and its use with our projects
Enabler for the launch of a new Community website aimed at increasing contribution through supporting contributors.
Project Scope (35 - 40 man-days)
The project will consist of refining existing documentation written by developers and writing new documentation (80%). A small amount (4%) is set for Graphic design although depending on the skill of the technical writer hired this may be undertaken by the same technical writer. A small portion of the project (12%) will focus on documenting release standards for documentation and integrating this into the processes to ensure this project has a sustainable legacy in the community.
As part of the development process, our developers include a baseline level of technical and functional documentation. The technical writer chosen, will work alongside existing community volunteers to make the existing documentation more robust and draft new documentation where it doesn’t exist. They will also work closely with Project Managers to document new release processes.
The project will:
Deliver a list and templates of core project documentation that must be maintained in releases.
Deliver updated Architectural Documentation for the PH-EE and Mifos X projects – Reflecting the significant contributions of the past 2 years and the updated architecture.
Complete through the Technical Author first issues of this core project documentation for the current releases of PH-EE and Mifos X. We also hope to encourage the community or interns to do this for other Mifos projects during this period and will reward contributors doing so.
Refine our getting start guides for new contributors to our projects ensuring streamlined process of setting up development environment, identifying tasks to work on, and contributing upstream according to our processes and standards.
Create white papers/tutorials for implementers on PH-EE and Mifos X on how to set up development environments as well as production deployment environments. Create clear technical dependency, security, privacy guides for PH-EE and Mifos X.
Create a clear guide as to how HELM is used within our projects and can be used and adapted by systems implementers.
Create a clear guide on using and maintaining and extending our test framework.
Work with the project manager to create an updated release process which mandates documentation moving forwards to ensure sustainability in documentation.
Based on previous work by Technical Authors and expected engagement from the community we expect this to require between 35-40 Man-days of effort split between these. We have also secured commitment from our project managers and release partners to support this project.
Measuring Project Success
Through workshops and surveys, we continually hear from the community how we need to reduce the friction in the developer experience. We also have a dearth in qualified senior developers that we hope to scale up through better documentation.
We would consider the project successful if:
We see an increase in new active contributors by 10 over a 3 month period.
Number of questions on Slack/Mailing list for information regarding documented installation reduces by 20%
We see an increase in System Integrators for PH-EE of at least 1 within a 3 month period
We see a reduction in time taken to respond to adopters of 25% through being able to point to clear documentation rather than create specific documentation.
Timeline
We see the project elapsed timeline as taking 6 months in terms of undertaking the work and measuring the success. Once the Technical writer is hired, we will undertake orientation, then move on to creating the list of documentation and templates, and then complete these templates for PH-EE and Mifos X. Alongside this we will through the community engagement supplement this for other Mifos projects. Finally, we will ensure that process flows are updated and in place for sustainability of this projects contribution beyond the closure of this project.
Dates | Action Items |
10th April 2024 | Approval of Project |
10th May 2024 | Tech writer hired and in place |
May 2024 | Orientation Complete and refinement of tasks. |
June 2024 | List of core project documentation created. Templates created and Gap analysis complete. |
July 2024 | Updated Architecture Documentation in place for PH-EE and Mifos X. 1st draft of Implementation white papers for PH-EE and Mifos X. |
August 2024 | Implementation Whitepapers released for PH-EE and Mifos X along with Guide on HELM. Documentation requirements incorporated into Release Process flows. |
Sept 2024 | Completion of all core documentation for PH-EE and Mifos X. |
Sept-Oct 2024 | Community delivered documentation complete. |
Sept-Nov 2024 | Measurement of Success criteria and creation of Case Study and Project Evaluation
|
Dec 2024 | Submission of Case Study and Project Evaluation. Project Completion
|
Project Budget
Total project budget is $15,000 USD
Budget Item | Amount (USD) | Running Total (USD) | Notes/Justification |
Technical Writer | $12,000 | $12,000 | Creating templates, updating documentation into templates, creation of missing documentation. |
Graphic Design (this may be undertaken by Technical writer – depending on selected resource) | $500 | $12,500 | Creation of any specific diagrams, flowcharts needed to simplify documentation |
Project Management, Supervision, review of Deliverables and integration into release processes. | $1,750 | $14,250 | To cover partial cost of scoping out project, managing its delivery and final review of deliverables, integrating into Release Processes for sustainability |
Volunteer Stipends (2 at $300 each) | $600 | $14,850 | For volunteers that will be closely providing information and/or mentoring/reviewing deliverables |
Project SWAG – Stickers, notebooks, T-Shirts for Volunteers | $150 | $15,000 | Printing of t-shirts for documentation volunteers encouraging community contribution into the project |
TOTAL |
| $15000 |
|
Additional Information
Previous experience with technical writers
We successfully completed the 2021 and 2022 Season of Docs program which helped impart upon us many critical lessons in scoping of the project, onboarding of the technical writer, managing expectations of the project, and ensuring the technical writer had optimal access to subject matter experts for proper facilitation. We have developed a strong understanding of the ideal types of documentation to focus on for a Season of Docs project and the ideal skill set in terms of domain and technical expertise needed to successfully complete a project.
We have worked extensively with technical writers before in the creation of user-facing and developer facing documentation. We have done this through community-wide efforts and documentation sprints via the FLOSS Manuals community, dedicate sabbaticals and long-term volunteers like Laurie Wilmot and Bharathi Ram, as well as with university students as part of their technical writing curriculum and with live documentation and conversion of our APIs to Swagger format through GSOC.
We have also participated in and mentored projects in the Google Summer of Code (GSOC) for a number of years and are an accepted organization for GSOC 2024. This has given us valuable experience in how to orientate and onboard interns and ensure they contribute to the community, alongside experience in how to mentor for success.
Our major learnings from these experiences have been a clear process and goals for the documentation to be produced, extensive understanding of the use cases being supported and what the technical or functional user is expected to do, maintainability of the documentation and ease of access, as well as testing with end users to ensure the documentation created is accurate and allows the user to create their desired task. This year we also intend to have closer oversight of the project following agile methodologies and guidelines to ensure alignment around objectives and progress towards intended deliverables.
Contact dpi@mifos.org