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
> 

Reply via email to