Hi In my opinion, JIRA offers far more flexibility than GitHub Issues, with features like custom fields, configurable workflows, dashboards, reports, and automation, making it a better choice for detailed project and issue tracking.
If we're looking for a simple, lightweight, and GitHub-integrated solution, GitHub Issues is sufficient; however, for a more feature-rich and scalable tracking system, I'd recommend JIRA. Regards, Bharath Lead Implementation Analyst | Mifos Initiative PMC Member | Apache Fineract Mobile: +91.7019635592 http://mifos.org Regards, Bharath Lead Implementation Analyst | Mifos Initiative PMC Member | Apache Fineract Mobile: +91.7019635592 http://mifos.org On Mon, Jul 13, 2026 at 11:33 PM James Dailey <[email protected]> wrote: > > +1 to GitHub issues > > Cleanest approach and keeps Fineract jira dedicated to mainline repo and > associated issues. > > > > Sent from Gmail Mobile > > On Mon, Jul 13, 2026 at 10:57 AM Aira Jena <[email protected]> wrote: >> >> +1 to Option 2, Edward and Sujan have mentioned everything well and I agree >> to them. Overall after today's discussion, option 2 looks good. >> >> On Mon, 13 Jul, 2026, 21:37 Edward Kang, <[email protected]> wrote: >>> >>> +1 to Option 2 as well. >>> >>> While I'm not too familiar with Github issues, the downsides of the other >>> options from today's meeting make sense. >>> - Option 1 suffers from being including in the greater Apache ecosystem, >>> creating confusion there. >>> - Option 3 suffers from being included in releases of Fineract. >>> >>> We should go with a solution that keeps Fineract's workflows clean overall. >>> >>> >>> >>> On Mon, Jul 13, 2026 at 10:59 AM sujan kumar <[email protected]> >>> wrote: >>>> >>>> +1 to Option 2. >>>> >>>> I think enabling GitHub Issues for the project is a good approach. Since >>>> the repositories are developed independently from the main Apache Fineract >>>> codebase, having issue tracking close to the code makes it easier for >>>> contributors to report bugs, request features, and follow ongoing work. >>>> >>>> It also keeps each repository self-contained while avoiding additional >>>> Jira projects unless they become necessary in the future. As the projects >>>> grow and attracts more contributors, GitHub Issues would provide a >>>> straightforward and familiar workflow. >>>> >>>> Regards, >>>> Sujan >>>> >>>> On Mon, 13 Jul, 2026, 18:07 Christofer Dutz, <[email protected]> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> coming in from the side-lines as I came across this discussion while >>>>> reviewing the projects activity for Wednesday's board meeting. >>>>> >>>>> If I understand it correctly, the project has added 4 new github repos in >>>>> the Apache fineract space for these sub-projects. >>>>> >>>>> If that's the case: why not enable github issues for these and track the >>>>> issues driectly inside the repos they apply to? >>>>> >>>>> Chris >>>>> >>>>> PS: If you want me to get a response, please add me in CC. >>>>> >>>>> On 2026/07/13 10:48:36 Aman Mittal wrote: >>>>> > Hi everyone, >>>>> > >>>>> > I'd like to start a discussion on how we should manage issue tracking >>>>> > for >>>>> > non-mainline Apache Fineract projects. >>>>> > Background >>>>> > >>>>> > The Apache Fineract PMC currently manages several repositories outside >>>>> > the >>>>> > main apache/fineract repository. These repositories explore new >>>>> > capabilities, prototypes, and complementary services that are unlikely >>>>> > to >>>>> > be merged into the main Fineract codebase due to differences in scope, >>>>> > technology stack, or intended users. >>>>> > >>>>> > Some examples include: >>>>> > >>>>> > - fineract-backoffice-ui >>>>> > Work-in-progress Backoffice UI for Apache Fineract (Angular 21+) >>>>> > - fineract-consumer-facing >>>>> > Consumer-facing reference application originally developed as a GSoC >>>>> > proof-of-concept (Spring Boot + Angular) >>>>> > - fineract-loan-origination >>>>> > Loan origination service originally developed as a GSoC >>>>> > proof-of-concept >>>>> > (Spring Boot) >>>>> > - fineract-business-intelligence >>>>> > Business Intelligence connector originally developed as a GSoC >>>>> > proof-of-concept (Python) >>>>> > >>>>> > Over time, I expect these repositories to become open for broader >>>>> > community >>>>> > contributions and eventually have their own release processes where >>>>> > appropriate. >>>>> > Problem >>>>> > >>>>> > These repositories are related to Apache Fineract but are not part of >>>>> > the >>>>> > main apache/fineract project. >>>>> > >>>>> > As they grow, contributors need a clear way to: >>>>> > >>>>> > - report bugs >>>>> > - request features >>>>> > - track development >>>>> > - understand whether an issue belongs to the core project or one of >>>>> > these related repositories >>>>> > >>>>> > Today, most issues are tracked in the FINERACT Jira project. While this >>>>> > works, I think it could become confusing as more repositories become >>>>> > active. >>>>> > >>>>> > The goal is not to change governance. These repositories would continue >>>>> > to >>>>> > be managed by the Apache Fineract PMC. The goal is simply to make it >>>>> > clearer for contributors where development is happening. >>>>> > Previous discussion >>>>> > >>>>> > I previously raised this topic on Matrix: >>>>> > >>>>> > https://matrix.to/#/!izTOsJxSUbKhKUROGM:matrix.org/$6VnqpdYhkZDBwy9Y7gxslPvX6dI-f9wiSV6sJm9xySY?via=matrix.org >>>>> > >>>>> > I also asked ASF Infrastructure whether creating another Jira project >>>>> > would >>>>> > be possible. Their response indicated that this is technically feasible. >>>>> > >>>>> > https://the-asf.slack.com/archives/CBX4TSBQ8/p1782838747421099 >>>>> > Possible approaches >>>>> > >>>>> > Option 1: Create a separate Jira project >>>>> > >>>>> > Create one (or more) Jira projects dedicated to these repositories. >>>>> > >>>>> > There is already precedent for multiple Fineract-related Jira projects. >>>>> > Besides FINERACT, there is also the historical FINCN project. >>>>> > >>>>> > https://issues.apache.org/jira/secure/BrowseProjects.jspa?selectedCategory=all&selectedProjectType=all&contains=fineract&sortColumn=name&sortOrder=ascending&s=view_projects >>>>> > >>>>> > Option 2: Use GitHub Issues >>>>> > >>>>> > Enable GitHub Issues for each repository using ASF's self-service >>>>> > .asf.yml >>>>> > configuration. >>>>> > >>>>> > https://infra.apache.org/request-bug-tracker.html >>>>> > >>>>> > >>>>> > Option 3: Continue using FINERACT Jira >>>>> > >>>>> > Continue using the existing FINERACT Jira project, but include the >>>>> > repository name in every issue title. >>>>> > >>>>> > For example: >>>>> > >>>>> > [backoffice-ui] Add dashboard widgets >>>>> > >>>>> > [consumer-facing] Registration flow >>>>> > >>>>> > [loan-origination] Support document uploads >>>>> > >>>>> > [business-intelligence] Add PostgreSQL connector >>>>> > Recommendation >>>>> > >>>>> > Personally, I prefer Option 2. >>>>> > >>>>> > Since these repositories are separate development efforts, >>>>> > repository-level >>>>> > GitHub Issues feel like the most natural solution. ASF already supports >>>>> > this through self-service configuration, and it avoids creating >>>>> > additional >>>>> > Jira projects while keeping issue tracking close to the code. >>>>> > >>>>> > If one of these projects eventually grows to the point where a dedicated >>>>> > Jira project makes sense, we could always revisit that decision later. >>>>> > >>>>> > I'd be interested in hearing what the PMC and the wider community think >>>>> > before moving forward. >>>>> > >>>>> > >>>>> > Regards, >>>>> > Aman >>>>> > >>> >>> >>> >>> -- >>> Edward E. Kang >>> [email protected] >>> 972-768-6940
