Aman-Mittal opened a new issue, #228: URL: https://github.com/apache/fineract-backoffice-ui/issues/228
## Proposal Adopt [Apache Magpie](https://magpie.apache.org/) ([apache/magpie](https://github.com/apache/magpie)) in this repository. Magpie became an ASF Top-Level Project on 29 June 2026. It is a curated set of agent recipes for the repetitive parts of running a project — issue and PR triage, contributor mentoring, fix drafting, security-report handling — with human review kept in the loop throughout. This is a proposal rather than a decision: adopting it changes how contributions are handled day to day, so it wants agreement before anything lands. ## Business value This repository is young, moving quickly, and has a small number of people doing the maintenance. The cost of that shows up in specific, recurring places: - **Triage backlog.** Issues arrive faster than they get labelled, scoped and routed. Newcomer-sized work in particular tends to sit unlabelled, which is exactly the work that most needs to be findable. - **Newcomer onboarding.** Getting a first-time contributor productive here means explaining an Angular 22 signal-based codebase, an adapter boundary, a generated API client that must not be hand-edited, and an e2e suite split between mocked and real-backend projects. That explanation is currently repeated by hand each time. - **Review load.** Reviewers spend attention on mechanical checks — conventions, missing tests, missing translations — before reaching the parts that actually need judgement. Magpie targets each of these directly, and it does so without adding a vendor dependency: it is explicitly vendor-neutral across models, and its stated design constraints are privacy, security and supply-chain integrity, with an affordability commitment so participation does not require a paid subscription. The thing it buys is maintainer attention. Every hour not spent labelling and re-explaining is an hour available for design and review, which is the scarce resource here. ## What adoption involves Magpie uses a snapshot-plus-override model: 1. Bootstrap from the published install recipe — downloads the framework into a gitignored `.apache-magpie/`, symlinks skills under `.agents/skills/`, updates `.gitignore`. 2. Run `/magpie-setup` — writes `.apache-magpie.lock` (committed, pins the version) and `.apache-magpie.local.lock` (gitignored), prompts for which skill families to enable, and scaffolds `.apache-magpie-overrides/` for project-specific customisation. 3. Later contributors re-run `/magpie-setup`, which reinstalls from the committed lock file. So the committed footprint is small: a lock file plus whatever overrides we write. Prerequisites are a compatible agent CLI, GitHub auth, and `uv`. ## Suggested scope for a first pass Magpie ships several skill families at different maturity levels. Rather than enabling everything, a staged adoption fits this repository better: | Family | Status upstream | Suggested | |---|---|---| | `setup` | always-on | required | | `issue` | stable | **yes** — triage, deduplication, reproduction | | `pr-management` | stable | **yes** — triage and reviewer routing | | `repo-health` | opt-in | **yes** — workflow security, dependency and licence audits, flaky-test detection | | `mentoring` | experimental | later — revisit once we have steadier newcomer traffic | | `release-management` | experimental | not yet — this project does not cut releases on that cadence | | `contributor-growth`, `pairing` | opt-in | later | `repo-health` is worth calling out: this repository already runs Apache RAT, licence compliance, dependency integrity and CodeQL in CI, so the audits should mostly agree with what we have — which makes it a low-risk way to confirm the framework behaves sensibly here before leaning on it for triage. ## Overrides we would want The generic recipes need project-specific context to be useful rather than noisy. At minimum: - `src/app/api` is generated and must not be hand-edited; spec sync is automated separately. - New components go through the adapter boundary (ADR-0003) rather than importing browser globals directly. - Any user-facing string needs a translation key. - A change to a screen wants both a unit test and an e2e test, and the e2e suite is split into a mocked project and a real-backend project with different rules. ## Open questions - Which model endpoint would we point it at, and who pays for it? The affordability commitment matters here — this should not become something only one contributor can run. - Does anything need to go past the PMC before enabling agent-authored PRs on an ASF repository? - Do we want agent-drafted fixes at all initially, or only triage and labelling to start with? ## Caveat I have not run Magpie against this repository — the above reflects its published documentation and current upstream status, not measured behaviour here. Worth a trial on `repo-health` first, where the output can be checked against CI results we already trust. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
