+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 >
