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