+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
