DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
Contents
APISIX
JSON Schema to Form UI for APISIX Dashboard
APISIX plugins ship JSON Schema definitions for their configuration. If APISIX Dashboard can render plugin configuration forms directly from JSON Schema, developer experience improves significantly and reduces manual UI maintenance.
Goals (Deliverables)
Must-have:
- A reusable SchemaForm (or equivalent) that renders basic types: string/number/integer/boolean/object/array.
- enum support (Select/Radio etc), defaults, required fields, basic constraints (min/max, pattern, etc) where feasible.
- Support at least the key complex patterns used by APISIX plugin schemas:
- oneOf (select one option and render corresponding fields)
- dependencies / conditional fields
- (Stretch) anyOf if present in target schemas
- Validation pipeline: validate form values against schema (AJV) and show errors in UI consistently.
- Documentation + developer guide: how to add/extend schema-to-widget mapping.
- Tests (unit + minimal integration) to prevent regressions for schema parsing and conditional rendering.
Difficulty: Major
Project size: ~350 hour (large)
Potential mentors:
Yuan Bao, mail: baoyuan (at) apache.org
Project Devs, mail: dev (at) apisix.apache.org
...
BI connector and demonstration
Note: GSOC applicants - this is a "draft concept". Do not work on your proposal until we kick off the process at Fineract for evaluating. We may significantly edit this concept or create new ones to replace it.
No one should work on this specific ticket unless assigned - the GSOC candidate we choose will be assigned this ticket.
For more information, you should be reviewing emails on this subject and following the Wiki pages.
https://lists.apache.org/list.html?dev@fineract.apache.org
https://cwiki.apache.org/confluence/display/FINERACT/GSOC+Program+at+Fineract
The idea is to create a connector and a demonstration of analytics that would consume and organize data from Fineract.
For example, create a way to pull data out of Fineract and make it easy to use in common analytics such as Power BI or Tableau or, better yet, an open source variant. The data should probably go to a Data Warehouse.
Start by proposing and exploring different options and write up the pros and cons.
Create a demonstration project that takes into account security, levels of access, and security of PII data if it exists.
Difficulty: Minor
Project size: ~350 hour (large)
Potential mentors:
James Dailey, mail: jdailey (at) apache.org
Project Devs, mail: dev (at) fineract.apache.org
Add DPG Badge to Fineract website and README
As requested by James Dailey on the mailing list, add the Digital Public Goods (DPG) badge to the project website and the main repository README following the DPG Alliance usage guidelines.
Difficulty: Major
Project size: ~350 hour (large)
Potential mentors:
Ambika, mail: ambikasony (at) apache.org
Project Devs, mail: dev (at) fineract.apache.org
fineract-client-feign usage for integration tests
Note: GSOC applicants - this is a "draft concept". Do not work on your proposal until we kick off the process at Fineract for
fineract-client-feign usage for integration tests
Note: GSOC applicants - this is a "draft concept". Do not work on your proposal until we kick off the process at Fineract for evaluating. We may significantly edit this concept or create new ones to replace it.
No one should work on this specific ticket unless assigned - the GSOC candidate we choose will be assigned this ticket.
For more information, you should be reviewing emails on this subject and following the Wiki pages.
https://lists.apache.org/list.html?dev@fineract.apache.org
https://cwiki.apache.org/confluence/display/FINERACT/GSOC+Program+at+Fineract
"Moving away from RestAssured (low-level) API calls in integration tests and rather use fineract-client-feign would be a great improvement"
Summary (with some assist from chatgpt for clarity)
Apache Fineract has a large set of REST APIs and many integration tests currently call those APIs using RestAssured(low-level HTTP requests). This ticket is to help modernize the tests by switching them to use fineract-client-feign, which is Fineract’s higher-level API client.
Goal
Create a simple migration approach and then migrate a small set of integration tests from RestAssured to fineract-client-feign.
Why we’re doing this
- Makes tests easier to read and maintain (less raw HTTP code).
- Encourages consistent API usage across tests.
- Reduces duplicated request-building logic (headers, base URLs, auth, etc.).
Scope of Work
1) Create a short migration plan
Write a short note (in the Jira ticket comments or a small doc) that answers:
- Where are the current RestAssured-based integration tests located?
- What’s the recommended pattern for using fineract-client-feign in tests?
- What should be migrated first (start small)?
2) Pick a small “starter set” of tests
Identify 2–5 integration tests that:
- Are simple (e.g., create/read/update a resource)
- Don’t involve complicated multi-step workflows
- Run reliably in CI
3) Implement the migration for the starter set
For each selected test:
- Replace RestAssured calls with fineract-client-feign client calls
- Keep the same assertions (same expected behavior)
- Ensure the tests still pass locally and in CI
4) Document the new pattern
Add a short README note or comments in the test code showing:
- How to initialize/configure the Feign client for tests
- How auth/session is handled
- A small “before vs after” explanation (1 paragraph is enough)
Acceptance Criteria
- A brief migration plan is written and linked in the ticket.
- At least 2 integration tests have been converted to use fineract-client-feign.
- All tests pass (locally and/or in CI).
- A short note exists explaining how to write future integration tests using fineract-client-feign.
Notes / Hints for a beginner
- Start by converting just one very small test to learn the pattern.
- Keep changes small and easy to review (one test per commit is ideal).
- If something is unclear (e.g., how auth is set up), add a comment in the ticket describing what you found.
Out of Scope (for this ticket)
- Migrating all integration tests across the repo
- Refactoring production API code
- Changing API behavior—this is only a test client swap
Difficulty: Minor
Project size: ~350 hour (large)
Potential mentors:
James Dailey, mail: jdailey (at) apache.org
Project Devs, mail: dev (at) fineract.apache.org
Add DPG Badge to Fineract website and README
As requested by James Dailey on the mailing list, add the Digital Public Goods (DPG) badge to the project website and the main repository README following the DPG Alliance usage guidelines.
Difficulty: Major
Project size: ~350 hour (large)
Potential mentors:
Ambika, mail: ambikasony (at) apache.org
Project Devs, mail: dev (at) fineract.apache.org
Apache NuttX
Apache NuttX
Create a NuttX Distribution Create a NuttX Distribution with Dynamic Binary (ELF) Loading
NuttX is very Unix/Linux-like RTOS for microcontrollers and it supports dynamic loading of binaries and libraries. It makes perfect sense to have the possibilities to create a NuttX Distros similar to what exists for Linux.
In fact there is already a proposal here: https://github.com/apache/nuttx/issues/17351
Goals:
1) Test ELF Loading in the current NuttX mainline
2) Create an application that will be downloaded and updated the existing version on the board
3) Add Library support on NuttX/NuttX-Apps (use Android Makefile Library building as reference)
Difficulty: Major
Project size: ~350 hour (large)
Potential mentors:
Alan Carvalho de Assis, mail: acassis (at) apache.org
Project Devs, mail: dev (at) nuttx.apache.org
...
Apache SkyWalking Natural Language to BydbQL
Background
BanyanDB is the native storage engine for Apache SkyWalking, designed specifically for observability data (Traces, Metrics, and Logs). It utilizes its own query language, BydbQL, which is SQL-like but optimized for time-series and observability schemas. While BydbQL is powerful, non-expert users or SREs in high-pressure situations may find it difficult to construct complex queries for specific traces or aggregated metrics.
The goal of this project is to build an Intelligent Query Agent that leverages Large Language Models (LLMs) to translate Natural Language (NL) into valid BydbQL.
Tasks
- Schema-Aware Prompting: Develop a mechanism to extract BanyanDB metadata (Groups, Streams, Measures, Tag Families) and feed it into the LLM context (RAG - Retrieval-Augmented Generation).
- N2SQL Implementation: Adapt state-of-the-art "Natural Language to SQL" (NL2SQL) techniques to the specific syntax and constraints of BydbQL.
- Verification Loop: Integrate the agent with the existing BydbQL parser to validate generated queries before execution.
- CLI/UI Integration: Implement a "chat" interface or an --ask flag in bydbctl (the BanyanDB CLI tool) to allow users to query data via plain English (e.g., "Show me the top 5 slowest services in the last hour").
Requirements
- Proficiency in Go (BanyanDB's primary language).
- Experience with LLM APIs (OpenAI, Gemini, or local models via Ollama) and orchestration frameworks (LangChain, LangGraph).
- Understanding of Compiler Front-ends (Lexing, Parsing, AST).
Difficulty: Major
Project size: ~350 hour (large)
Potential mentors:
Hongtao Gao, mail: hanahmily (at) apache.org
Project Devs, mail: dev (at) skywalking.apache.org
Mahout
Add ZZFeatureMap Encoding for QDP
Backgroud
ZZFeatureMap is the most widely-used data encoding in quantum machine learning. It's the default in Qiskit and PennyLane for quantum kernel methods and variational classifiers.
QDP currently supports amplitude, angle, basis, and IQP encodings. Adding ZZFeatureMap completes our QML encoding suite.
What is ZZFeatureMap?
Maps classical features to quantum states using:
1. Hadamard gates (superposition)
2. RZ gates (single-qubit rotations)
3. ZZ interactions (two-qubit entanglement)
4. Repetition layers for expressivity
Tracked github issue
Difficulty: Major
Project size: ~350 hour (large)
Potential mentors:
Ryan Huang, mail: hcr (at) apache.org
Project Devs, mail: dev (at) mahout.apache.org
Spark
SPIP Client-Side Metadata Caching for Spark Connect
This SPIP proposes adding a client-side schema cache for Spark Connect DataFrames.
Currently, every call to df.columns or df.schema triggers a synchronous gRPC analysis request to the server. While these are local and near-instant in Spark Classic, in Connect they average 277 ms on standard cloud setups (like AWS t3.medium). This makes iterative work extremely slow; we've measured a 13-second lag for 50 metadata calls in a typical ETL pipeline.
This delay is forcing developers to use a "Shadow Schema" pattern, where they manually track column names in local lists to avoid the RPC overhead. Since Spark DataFrames are immutable, we can fix this by caching the resolved schema on the client after the first request. Our POC shows this reduces the 13-second lag to about 250 ms (a 51× speedup) without breaking the core Spark Connect model.
I have followed the official SPIP template for the detailed breakdown below.
SIP
https://docs.google.com/document/d/1xTvL5YWnHu1jfXvjlKk2KeSv8JJC08dsD7mdbjjo9YE/edit?tab=t.0
Benchmark - https://docs.google.com/document/d/1ebX8CtTHN3Yf3AWxg7uttzaylxBLhEv-T94svhZg_uE/edit?tab=t.0
Difficulty: Major
Project size: ~350 hour (large)
Potential mentors:
vaquar khan, mail: vaquar.khan@gmail.com (at) apache.org
Project Devs, mail: