You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Aman Mittal <am...@gmail.com> on 2026/07/13 10:48:36 UTC
[DISCUSS][PROPOSAL] Managing Non-Mainline Apache Fineract Projects
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
Re: [DISCUSS][PROPOSAL] Managing Non-Mainline Apache Fineract Projects
Posted by Bharath Gowda <bg...@mifos.org>.
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 <ja...@gmail.com> 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 <ai...@gmail.com> 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, <ed...@gmail.com> 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 <su...@gmail.com> 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, <cd...@apache.org> 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
>>> edward.kang12@gmail.com
>>> 972-768-6940
Re: [DISCUSS][PROPOSAL] Managing Non-Mainline Apache Fineract Projects
Posted by James Dailey <ja...@gmail.com>.
+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 <ai...@gmail.com> 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, <ed...@gmail.com> 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 <su...@gmail.com>
>> 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, <cd...@apache.org> 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
>> edward.kang12@gmail.com
>> 972-768-6940
>>
>
Re: [DISCUSS][PROPOSAL] Managing Non-Mainline Apache Fineract Projects
Posted by Aira Jena <ai...@gmail.com>.
+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, <ed...@gmail.com> 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 <su...@gmail.com>
> 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, <cd...@apache.org> 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
> edward.kang12@gmail.com
> 972-768-6940
>
Re: [DISCUSS][PROPOSAL] Managing Non-Mainline Apache Fineract Projects
Posted by Edward Kang <ed...@gmail.com>.
+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 <su...@gmail.com>
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, <cd...@apache.org> 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
edward.kang12@gmail.com
972-768-6940
Re: [DISCUSS][PROPOSAL] Managing Non-Mainline Apache Fineract Projects
Posted by sujan kumar <su...@gmail.com>.
+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, <cd...@apache.org> 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
> >
>
Re: [DISCUSS][PROPOSAL] Managing Non-Mainline Apache Fineract Projects
Posted by Christofer Dutz <cd...@apache.org>.
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
>