Mojaloop aims at creating payment platforms that are interoperable, connecting digital financial service providers and customers by providing specifications, standards and open-source software.
- Official Mojaloop Documentation
- Mojaloop Specification
- Developer Onboarding Guide
- Deploy Mojaloop On Kubernetes
- Mojaloop Business Documentation
Slack is the best way to keep in touch with the Mojaloop Community. Sign up for your Mojaloop Slack account here.
Channels:
#announcements- Announcements for new Releases and QA Status#design-authority- Questions + Discussion around Mojaloop Design#general- General discussion about Mojaloop#help-mojaloop- Ask for help with installing or running Mojaloop#ml-oss-bug-triage- Discussion and triage for new bugs and issues
Refer to the Contributors guide to get started making contributions.
You may also want to read:
- Mojaloop Github Project
note: You must install the ZenHub extension in order to see the Project Kanban Board
- Developer Onboarding Guide
If you have any trouble getting started, or want to know where to start, reach out to us on the #help-mojaloop channel in Slack!
Refer to the Mojaloop Repository Overview for a detailed breakdown of each Mojaloop Repository in development.
As a quick reference, some of the most important repositories for contributors are:
- central-ledger - Core Service in charge of managing transfers between DFSPs
- ml-api-adapter - Translation layer to convert to/from Mojaloop API to an internal format that is used in Central Services Stack.
- account-lookup-service - A service for managing party accounts across a Mojaloop environment
- helm - The Helm chart development for deploying Mojaloop on Kubernetes
- Testing Toolkit - The swiss army knife of testing Mojaloop and DFSP APIs
- project - The Mojaloop Project issue tracker and Kanban board
We use the mojaloop/project repository as an issue tracker for all repositories across the Mojaloop Project.
When creating a new issue, select from the issue templates provided here
Special thanks to all the organizations and individuals who have supported this Open-Source effort.
This list (in alphabetical order) is by no means exhaustive and complete. Please raise a Pull Request if you believe your Organization should be included in this list.
We use a unified scrum or kanban board for tracking issues across all Mojaloop Projects.
This repo relies on the Zenhub Browser Extension in order to see Github issues in a scrum board.
You should be able to see the "ZenHub" tab in the top bar. If not, go through the following steps to see the kanban board:
Note: In order to add mojaloop to your Zenhub workspaces, you need your Github account be added to the Mojaloop project. If you believe you should be added, contact us on the Mojaloop Slack.
- Go to the Zenhub Login Page and log in to Zenhub with your Github account
- Connect your new Zenhub account with the Mojaloop Organisation, Search for the 'project' workspace
- Install the Zenhub Browser extension for Chrome or Firefox, and reload this page. You should now see the following:
- Please use the available templates for bugs or feature requests (epics, stories). There are templates for bugs and stories.
- Please use appropriate labels as applicable (epic or story) along with the work-stream that it belongs to (example: 'oss-core' for core related issues, 'oss-ver' for versioning work-stream, 'oss-perf' for performance work-stream and so on.)
- The pipelines are intended to give a view of the movement of stories and epics.
3.1. Product Backlog Epics - All Epics that span more than one Program Increment (PI) are included under this pipeline as long as they're active.
3.2. Product Backlog - All stories, bugs are included in this by default if they cannot be assigned to the current or a particular PI.
3.3. PI Backlog Epics - All Epics that span a single (PI) and are prioritized for the current PI are included under this pipeline until they're closed.
3.4. PI Backlog - All stories, bugs are included for the current PI are included in this until they're prioritized for a particular Sprint.
3.5. Sprint Backlog - Once stories, epics are prioritized for a Sprint by a work-stream, they can be moved to the Sprint backlog.
3.6. Blocked - Stories, bugs relevant to the current PI and are blocked because of an immediate work-item/issue are present in this pipeline.
3.7. In Progress - All issues that are currently being worked on are present in this pipeline. Ideally by now all stories, bugs should have an assigned milestone, an estimate, an Epic, proper labeling and acceptance criteria.
3.8. Review - Stories, bugs once completed and ready for review are moved to this pipleline to be reviewed by Product Owner, etc. before moving to the closed pipleine.
3.9. Closed - All Epics, Stories, bugs once completed are moved to the Closed pipeline (issues closed by default are also moved to this).