AsterixDB currently lacks native support for Top-K-Nearest queries, which return the K tuples whose attribute values are closest to a given reference value or point. Examples include: the five employees whose salaries are closest to the CEO's salary or the five buildings closest to the White House. This project involves designing and implementing efficient Top-K-Nearest query processing within AsterixDB's execution engine (Hyracks), including optimizer support to avoid full scans and to leverage existing indexes where possible. The implementation should integrate cleanly with SQL++.

Background

Apache Wayang is a cross-platform data processing framework that lets users write data analytics tasks once and execute them efficiently across diverse execution engines such as Apache Spark, Apache Flink, relational databases, and others. It abstracts heterogeneous backends and can enable efficient hybrid execution across different execution engines.

Currently, Wayang supports dataflow-style APIs in Java, Scala, and Python and an SQL API. However, there is no high-level DataFrame API — a programmatic abstraction widely used in modern data processing ecosystems (e.g., Spark DataFrames, Pandas, R DataFrames) — that lets users express relational transformations over structured datasets in a fluent, tabular style.

A DataFrame API for Wayang would dramatically improve usability for data engineers and scientists, making Wayang accessible to users familiar with DataFrame programming paradigms while preserving its powerful cross-platform optimization capabilities.

Project Goal

Implement a DataFrame API for Apache Wayang that:

• Represents structured data in a tabular abstraction (rows & columns),

• Supports common relational and analytical operations (select, filter, join, groupBy, aggregate, etc.),

• Can compile DataFrame operations into Wayang plans executed across backends transparently,

• Includes comprehensive documentation and examples.

Outcomes & Impact

By the end of GSoC, Wayang will have its first robust DataFrame API — a major usability milestone that bridges structured analytics with cross-platform execution. This will enhance adoption, unlock new classes of applications, and position Wayang as a friendly high-level programming environment in addition to its optimizer backend strengths.

Difficulty: Medium
Project size: ~350 hours (Large)
Potential mentors:

• Zoi Kaoudi — zkaoudi (at) apache.org

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

https://github.com/apache/mahout/issues/1008

Background

Apache Beam is a unified programming model for user developing data processing pipelines capable running in distributed systems. Apache Beam SDK officially supports Java, Python, and Go. While Java SDK was historically dominant, Python SDK is increasingly popular thanks to Beam ML. Python APIs are crucial for developers. We plan to port highly anticipated basic streaming transforms made convenient for Beam Python developers.

Tasks

1. Python UnboundedSource (https://github.com/apache/beam/issues/19137)

While Splittable DoFn has been introduced as a Beam primitive transform handling IO sources, UnboundedSource arguably remains an easier API for users to author their own IOs. In the Java SDK, UnboundedSource/UnboundedReader has been (re)implemented as a wrapper of Splittable DoFn, we can follow the Java implementation and add it to Python.

Stretch goal: implement a native Python streaming IO based on UnboundedSource.

2. Python Watch Transform (https://github.com/apache/beam/issues/21521)

Currently we have a Watch transform in the Java SDK that is very useful when periodically polling for new input to a pipeline. We would like a parallel transform in Python.

Stretch goal: Update Python FileIO.readContinuously to use watch transform

Deliverables

• Implementation of Python UnboundedSource: A functional wrapper API for UnboundedSource and UnboundedReader built on Splittable DoFn (a merged pull request to the Apache Beam repo).
• Implementation of Python Watch Transform: A parallel transform to the Java Watch API for periodic polling (a merged pull request to the Apache Beam repo).
• Unit and Integration Tests: tests for both features, specifically covering watermarks, checkpointing, and polling termination conditions.
• User Documentation: Updated SDK guides and Docstrings explaining how to author custom IOs using UnboundedSource and how to use the Watch transform in pipelines.
• Refactored FileIO.readContinuously (Stretch Goal): A pull request updating FileIO.read_continuously to utilize the new Watch transform logic.

Recommended Skills

• Proficiency in Python, experience with pytest
• Java-to-Python Porting: Ability to read and interpret Java source code
• Version control: Git, development with GitHub
• nice to have: exposure to streaming data processing tools (e.g. Apache Beam/Flink/Spark, etc)

Apache DolphinScheduler

Apache DolphinScheduler is a distributed and extensible workflow scheduler platform with powerful DAG visual interfaces, dedicated to solving complex job dependencies in the data pipeline and providing various types of jobs available out of box.

Website: https://dolphinscheduler.apache.org/en-us/index.html

GitHub: https://github.com/apache/dolphinscheduler

Linked GitHub Issue: https://github.com/apache/dolphinscheduler/issues/8975

Background

Currently, DolphinScheduler requires a separate alert-server to handle workflow and task alerts. Although the alert-server is lightweight, maintaining and deploying it separately adds operational complexity.

We aim to remove the standalone alert-server and embed its alerting functionality directly into the API server.

Task

Integrate the alert-server functionality into the API server so that it can handle workflow and task alerts natively.

Deliverables

• Remove the standalone alert-server.

• Enable the API server to handle all alerting tasks.
• Add Integration test case.

Recommended Skills

• Proficiency in Java.
• Familiarity with microservice, e.g. spring-boot.

• Familiarity with DolphinScheduler’s architecture and alerting mechanisms is a plus.

Mentors

• Wenjun Ruan(Apache DolphinScheduler PMC member), wenjun@apache.org
• Zihao Xiang(Apache DolphinScheduler PMC member),   zihaoxiang@apache.org

Background

Apache IoTDB is a high-performance, IoT-native time-series database designed to manage massive volumes of time-series data generated by industrial IoT devices. It addresses challenges including high ingestion rates, complex out-of-order data handling, and real-time analytical requirements. IoTDB-AINode represents an endogenous node type in the IoTDB ecosystem, extending the database with native machine learning capabilities. IoTDB-AINode enables seamless integration of time series machine learning algorithms directly within the database engine, allowing users to register, manage, and execute inference tasks using simple SQL statements (e.g., CREATE MODEL ..., SELECT * FROM FORECAST (...)). This architecture eliminates costly data migration to external ML platforms, accelerates processing pipelines, and enhances data security by keeping computations close to the data. Currently, AINode includes built-in time series foundation models such as the Timer and Chronos for time series forecasting task.
Tensor Processing Units (TPUs) are Google-developed AI accelerators specifically designed for neural network computations. Offering high-throughput matrix operations and energy efficiency, TPUs provide a compelling alternative to GPUs for deploying large foundation models. PyTorch/XLA enables PyTorch models to leverage TPU hardware through the XLA (Accelerated Linear Algebra) compiler, supporting both single-device and distributed training scenarios.
Time Series Foundation Models have emerged as powerful tools for temporal analysis. These models demonstrate superior performance across diverse domains—from industrial sensor data to financial forecasting—making them ideal candidates for integration into IoTDB's analytical pipeline.

Goal

This project aims to enhance IoTDB-AINode with TPU hardware acceleration capabilities and integrate cutting-edge time series foundation models into the database's model inference pipeline. Specifically, the project will: 

• Enable IoTDB-AINode to recognize and leverage Google TPU devices for model deployment and inference.
• Adapt the AINode packaging and compilation workflow (Maven/Java and Poetry/Python) to support TPU-specific releases.
• Survey and integrate 1-2 SOTA time series foundation models (e.g., TimesFM) into AINode's SQL-accessible model registry.
• Establish comprehensive CI pipelines for TPU environments to ensure long-term maintainability.

The ultimate outcome will empower IoTDB users to execute high-performance time series analysis on TPU hardware using state-of-the-art foundation models through simple SQL interfaces, significantly enhancing the database's analytical capabilities for industrial AI applications.

Core Tasks（Mandatory）

1. TPU Adaptation. Implement TPU device recognition and tensor management within the AINode Python runtime. This involves:
   1. Integrating PyTorch/XLA (torch_xla) to detect available TPU devices during AINode initialization.
   2. Implementing device abstraction layers to handle model loading and tensor operations on TPU hardware.
   3. Ensuring automatic fallback mechanisms to CPU/GPU when TPU is unavailable.
2. Packaging for TPU Version. Extend the existing build infrastructure to support TPU-enabled distributions:
   1. Update Poetry configuration to manage PyTorch/XLA and TPU-specific Python dependencies.
   2. Create automated packaging scripts that bundle XLA compilers and TPU runtime libraries.
   3. Ensure the TPU version can be deployed directly in Google Cloud TPU environments and on-premise TPU pods without manual dependency resolution.
3. Model Survey. Conduct a comprehensive technical survey of SOTA time series foundation models available at project commencement. The deliverable will be a technical document analyzing each model's architecture, input requirements, computational complexity, zero-shot capabilities, and suitability for IoTDB's SQL-based inference pipeline. The survey will conclude with a justified selection of 1–2 models for integration based on deployability, inference latency, licensing, and compatibility with IoTDB’s SQL-based workflow.
4. Model Integration. Integrate 1-2 selected foundation models into IoTDB-AINode's model inference framework:
   1. Implement model wrappers conforming to AINode's model registration interface.
   2. Adapt models to process IoTDB's time series data format.
   3. Ensure compatibility with AINode's inference pipeline, supporting SQL syntax such as SELECT * FROM FORECAST (...).
   4. Support both built-in model usage and custom model registration for integrated architectures.
5. Integration Testing & CI. Establish robust testing infrastructure for TPU functionality:
   1. Design and implement integration tests covering device detection, model loading, tensor operations, and end-to-end inference workflows.
   2. Build TPU-specific CI environments using Google Cloud TPUs or TPU simulators.

Advanced Tasks (Optional)

• Distributed Large Model Deployment. As an optional stretch goal, this task explores distributed deployment of large time series foundation models across multiple TPU devices. This involves:
  • Enabling distributed inference where large models are partitioned across TPU pods.
  • Developing SQL extensions to specify distributed compute resources (e.g., LOAD MODEL ... TO DEVICES ...).
  • Optimizing communication patterns between DataNodes and AINode for high-throughput industrial scenarios involving thousands of time series streams.

Deliverables

1. Fully Functional Source Code.
   1. Pull requests to Apache IoTDB repository containing TPU adaptation modules.
   2. Integration code for SOTA time series foundation models.
   3. Extended build configurations (Maven/Poetry/PyInstaller) supporting TPU distributions.
2. Comprehensive Integration Tests.
   1. Automated test suites for TPU device detection and model execution.
   2. CI pipeline configurations for TPU environments.
3. User Documentation.
   1. Deployment guide for TPU-enabled AINode (e.g. Google Cloud TPU).
   2. SQL reference extensions for new model types and TPU-specific configuration options.
   3. Tutorial documentation demonstrating time series analysis workflows using the integrated foundation models.

Recommended Skills

• Python >= 3.11. Including asynchronous programming and ML pipeline development.

• Poetry & PyInstaller. Experience with Python dependency management and executable packaging.

• PyTorch. Known about the PyTorch/XLA integration for TPU support.

• Java & Maven. Knowledge of multi-module Java projects, build profiles, and dependency management.

Learning Material

• Apache IoTDB. https://iotdb.apache.org/

• IoTDB AINode. https://iotdb.apache.org/UserGuide/latest-Table/AI-capability/AINode_apache.html

• Time series forecasting models in HuggingFace. https://huggingface.co/models?pipeline_tag=time-series-forecasting&sort=trending

• PyTorch TPU support. https://docs.pytorch.org/xla/master/accelerators/tpu.html

 
Difficulty: medium
Mentor: Yongzao Dan (Apache IoTDB PMC Member) (yongzao@apache.org)

Project Overview

Title

Enhance Seata-Go Multi-Registry Support and seata-ctl Diagnostic Tool Capability

Abstract

Apache Seata (incubating) is a popular distributed transaction solution for ensuring data consistency in microservice architectures. Seata-Go, as its Go language SDK, is responsible for implementing core TM/RM functionalities in the Go ecosystem.

Currently, Seata-Go lags behind the Java version in terms of registry support richness at the infrastructure layer, and its production-level transaction troubleshooting and operational toolchain (seata-ctl) is still in its early stages. This results in limited options for users in non-Etcd/Raft scenarios and high troubleshooting costs when transaction anomalies occur.

This project aims to align with Seata's infrastructure ecosystem by introducing support for four mainstream registries: Nacos, ZooKeeper, Consul, and Redis to Seata-Go. Additionally, it will significantly enhance seata-ctl's diagnostic capabilities through full-chain environment checks, transaction state insights, and an interactive terminal interface, reducing the operational threshold for distributed transactions.

Detailed Description / Objectives

• Infrastructure Alignment: Ensure Seata-Go can seamlessly integrate into existing enterprise-level microservice governance systems by implementing adapters for various mainstream registries.
• Operational Efficiency Improvement: Build a complete diagnostic command set enabling developers to quickly locate network, database, and transaction state anomalies, and simplify operation workflows through an interactive interface.
• Community Ecosystem Contribution: Produce high-quality design documents and technical blogs to help community users understand Seata-Go's underlying governance logic and operational best practices.

Deliverables

1. Multi-Registry Cluster Support (Priority P0)

• Mainstream Registry Adapter Implementation:

• • Implement Nacos and ZooKeeper registry adapters with support for service instance subscription, real-time listening, and multi-tenant isolation configuration.
  • Implement Consul and Redis adapters with support for service registration/discovery and heartbeat monitoring mechanisms.
  • Bug fixes for Seata NamingServer Golang SDK.
  • Ensure service registration path formats for all registries are fully compatible with Java version Seata.
• Configuration and Initialization System Integration:

• • Extend configuration structure to standardize registry-specific configuration parameters.
  • Optimize factory initialization logic to support smooth registry type switching via configuration files.

2. seata-ctl Diagnostic Tool Enhancement (Priority P1)

• Full-Chain Self-Check Functionality:

• • Implement automated environment checks covering network connectivity verification with the server.
  • Implement database-level health checks including connection availability and validation of transaction core system table structures.
  • Implement configuration file format and required field legality validation.
• Transaction State Insight Capability:

• • Implement real-time query functionality for active transaction lists.
  • Implement query functionality for resource lock records corresponding to specific transaction identifiers (XID).
  • Support structured output formats (e.g., table, JSON, YAML).
• Interactive Terminal Interface (TUI):

• • Introduce a visual interactive mode for the tool, simplifying complex command input through interface guidance to enhance operational experience.

3. Testing, Samples, and Community Output (Priority P2)

• Testing and Validation:

• • Write unit tests and integration tests for each registry adapter to verify node change awareness capabilities.
  • Validate diagnostic tool accuracy across different database dialects.
• Samples and Documentation:

• • Add complete multi-registry integration examples in seata-go-samples.
  • Write technical articles: "Seata-Go Registry Extension Design and Practice Guide" and "Distributed Transaction Troubleshooting in Practice: Quickly Locating Anomalies with Diagnostic Tools".

Implementation Plan

• Phase 1: Research and Architecture Design

• • Research existing Seata-Go registry implementations and study Seata NamingServer implementation logic.
  • Design diagnostic tool's interaction logic and command set architecture, ensuring tool extensibility.
• Phase 2: Registry Adapter Development (P0)

• • Prioritize completion of core functionality implementation and compatibility testing for Nacos and ZooKeeper.
  • Perform bug fixes for Seata NamingServer to optimize its stability in the Go SDK.
  • Integrate Consul and Redis support and unify configuration initialization entry points.
• Phase 3: Diagnostic Tool and Interactive Interface Development (P1)

• • Develop core logic for environment checks and transaction state queries.
  • Build interactive terminal interface (TUI), encapsulating underlying commands into intuitive visual operations.
• Phase 4: Testing Validation and Community Promotion (P2)

• • Improve test cases to ensure stability across different registry environments.
  • Complete community technical article output and submit related sample code.

Required Skills

• Have Go language development experience, familiar with concurrent programming and network communication.
• Understand service discovery principles, familiar with mainstream registries (e.g., Nacos, ZooKeeper).
• Understand basic distributed transaction principles, familiar with Seata's interaction architecture (TM/RM/TC).
• Familiar with command-line tool development, possess good code standards awareness and documentation writing skills.

Benefits to Apache Seata

• Expand Infrastructure Boundaries: Enable Seata-Go to adapt to more diverse enterprise production environments, eliminating selection barriers.
• Improve Operational Convenience: Fill the gap in operational diagnostic tools for the Go version, significantly reducing user learning and maintenance costs.
• Enhance Ecosystem Interoperability: Ensure consistency in governance between Go and Java versions, supporting Seata's unified multi-language ecosystem.

Conclusion

This project addresses Seata-Go's shortcomings in infrastructure adaptation and operational troubleshooting by enhancing multi-registry support and diagnostic tool capabilities. This not only improves Seata-Go's production readiness but also strengthens the Apache Seata community ecosystem through user-friendly interactive tools and comprehensive technical documentation.

Useful Link

• https://seata.apache.org/
• https://github.com/apache/incubator-seata-go
• https://github.com/apache/incubator-seata-go-samples
• https://github.com/apache/incubator-seata-ctl

Contact Information

• Mentor Name: TunGuo [tew@apache.org], Apache Seata(incubating) Committer

Summary

Currently a lot of API parameters do not get auto-completed as cloudmonkey isn't able to deduce the probable values for those parameters based on the list APIs heuristics. A lot of these parameters are enums on CloudStack end and by finding a way to expose these and consume them on cloudmonkey side, we could improve the usability of the CLI greatly.

Benefits to CloudStack

• Improved end user experience when using CLI
• Reduce incorrect inputs

Deliverables

• Expose enums and all other relevant information that can be used to enhance auto-completion of parameters on CloudStack end -
  • May require framework level changes and changes to APIs
• Consume these exposed details on Cloudmonkey end

Dependent projects

https://github.com/apache/cloudstack-cloudmonkey/

Ref CloudStack Issue: https://github.com/apache/cloudstack/issues/10442

Author and Publish New Practical Guides for Apache Grails on https://guides.grails.org (will be moved to grails.apache.org soon)

Background

The Grails Guides provide step-by-step, hands-on tutorials with accompanying GitHub repositories containing initial and complete project states. They cover core topics GORM, testing, security, frontend integrations (Vue.js, React, Angular), Micronaut features, deployment (AWS, Google Cloud, GitHub Actions), and more.

Existing guides are strong in foundational and some advanced areas but have gaps in:

• Modern frontend setups
• Broader cloud deployment
• Current DevOps practices
• Popular plugins/ecosystem updates

Creating 5-10 high-quality, up-to-date guides would directly enhance this key learning resource, making Grails more approachable and demonstrating current best practices without requiring core framework changes.

Project Goals

1. Research & Plan Topics: Select 5-10 high-impact guide topics based on community needs (user list discussions, Slack feedback, gaps identified).
2. Develop Guides: For each:
   • Build a complete, runnable Grails application example.
   • Create initial and complete GitHub repos following the standard template.
   • Write a clear, step-by-step Markdown guide with code snippets, explanations, and best-practice rationale.
3. Test & Polish: Ensure guides work with the latest stable Grails (e.g., 7.x or 8.x series), include tests where relevant, and follow accessibility/Asciidoc formatting standards.
4. Submit & Integrate: Open PRs to publish guides update any related docs or grails.org links.
5. Optional Stretch Goals: Add video walkthroughs (if comfortable), create a "What's New in Recent Guides" summary blog post, or contribute minor improvements to existing guides.

Suggested Guide Topics (prioritize with mentor input):

• Building Modern Full-Stack Apps with Grails + React/Vite (or Vue/Vite) – Update/extend older profiles with current tooling.
• Securing Grails APIs with JWT + OAuth2 (modern patterns, perhaps using Micronaut Security).
• Deploying Grails Apps to the cloud
• Advanced CI/CD
• Performance Tuning
• Using HTMX + Grails for Interactive UIs without Heavy Frontend Frameworks.

Deliverables

• 5-10 new published guides on https://guides.grails.org (each with its own GitHub repo under grails-guides).
• Corresponding initial and complete source code repositories.
• Well-structured Markdown/Asciidoc content with clear sections, screenshots/code blocks, and "Try it Yourself" instructions.
• PRs reviewed and merged by mentors/community.
• A short summary report or blog draft for the Grails blog announcing the new guides.
• Documentation updates if needed (e.g., category additions on the guides index page).

Quantifiable Results for the Apache Community:

• Fresh, relevant content that attracts and retains new developers.
• Reduced support burden on mailing lists/Slack by pointing users to modern tutorials.
• Evergreen educational assets maintained by the community.

Proposed Timeline (12-week program)

• Community Bonding (May 2026): Join Grails Slack/mailing list, review existing guides, discuss topic priorities with mentors, fork/clone template repo, set up local build.
• Weeks 1–2: Finalize 3–5 topics, create initial repos, outline guide structures.
• Weeks 3–6: Implement and document first 2–3 guides (focus on core features, testing).
• Weeks 7–9: Complete remaining guides, add polish (screenshots, edge-case notes), self-review for clarity.
• Weeks 10–11: Submit PRs for review, incorporate feedback, test on latest Grails version.
• Week 12: Final merges, any last tweaks, prepare announcement draft, evaluations.

Required Skills

• Solid understanding of Grails (create-app, domains, controllers, services, GSP/JSON views).
• Experience with Groovy/Java and web basics (REST, security concepts).
• Good technical writing (clear, concise explanations).
• Git/GitHub proficiency (branching, PRs).
• Nice-to-have: Familiarity with Asciidoc/Markdown, frontend tools (Vite, npm), or deployment platforms.

Why This Project?

This is a high-reward contribution that directly improves one of Grails' most visible learning resources. It's flexible, scope can adjust based on progress, and allows the student to master Grails while helping others. Similar documentation-focused GSoC projects have succeeded in many Apache projects.

If Grails is accepted for GSoC 2026, this would be an excellent intermediate project. Interested students should contact the Grails dev mailing list or Slack early to discuss topics and secure a mentor. The community welcomes fresh guides to keep the framework vibrant!

 
Difficulty: Medium
Project size: ~350 hour (large)
Potential mentors:
James Fredley

Description:
Apache Fory currently has no Ruby runtime, so Ruby services cannot participate in Fory xlang object exchange. This project implements Ruby xlang serialization with full wire compatibility to existing language runtimes, following the xlang specifications and issue #3379.

Primary references:
1. docs/specification/xlang_serialization_spec.md
2. docs/specification/xlang_implementation_guide.md
3. https://github.com/apache/fory/issues/3379

Scope:
1. Implement xlang binary format in Ruby runtime.
2. Support schema-consistent mode and compatible mode with meta share and TypeDef.
3. Implement registration model for numeric and named user types.
4. Implement deterministic struct serialization rules required by spec.
5. Implement reference tracking and reference flags behavior exactly per protocol.
6. Implement meta string encoding and dedup semantics needed by named types and TypeDef.
7. Provide cross-language interoperability with Java in both encode and decode directions.

Expected outcomes:
1. Ruby runtime package under ruby/ with serializer and deserializer for xlang protocol.
2. Public API centered on Fory entry point with configuration and registration APIs.
3. Core runtime modules for buffer, type resolver, ref resolver, meta string, TypeDef context, and field skipper.
4. Serializer coverage for primitives, temporal types, list, set, map, arrays, structs, and unions.
5. Struct DSL and schema metadata model for deterministic field ordering and stable schema behavior.
6. Compatibility handling for unknown fields and unknown union alternatives via safe skip logic.
7. Documentation for Ruby API usage, registration, schema evolution behavior, and constraints.

Protocol requirements:
1. Little-endian encoding for all multi-byte values.
2. Correct xlang header bitmap handling for null, xlang, and oob flags.
3. Exact reference flags and sequential reference ID assignment.
4. Correct type ID encoding and user type ID handling.
5. Correct namespace and type name metadata behavior for named types.
6. Deterministic struct field ordering exactly aligned with spec.
7. Meta string encoding and per-stream dedup behavior aligned with spec.

Implementation phases:
1. Phase 0: Ruby project skeleton, CI bootstrap, minimal smoke serialization path.
2. Phase 1: Buffer, varint and zigzag utilities, header handling, reference resolver core.
3. Phase 2: Primitive and temporal type support.
4. Phase 3: Collections and arrays support.
5. Phase 4: Type registry and schema-consistent struct serialization.
6. Phase 5: Meta string encoding and dedup.
7. Phase 6: Compatible mode and shared TypeDef.
8. Phase 7: Union and extension type support.
9. Phase 8: Performance hardening and allocation reduction.

Testing and CI requirements:
1. Add Ruby unit tests for protocol primitives, headers, references, and error handling.
2. Add golden vector tests for primitives, string encodings, list/set/map headers, TypeDef, and unions.
3. Add bidirectional interoperability tests:
   - Ruby write to Java read.
   - Java write to Ruby read.
4. Add compatibility tests for schema evolution in compatible mode, including add/remove/reorder and unknown field skipping.
5. Add tests for shared references, circular references, and ref tracking disabled behavior.
6. Add negative tests for invalid varint, unknown type ID, truncated payload, and malformed TypeDef.
7. Integrate Ruby lint and all Ruby xlang tests into CI so regressions fail CI automatically.

Non-goals for initial delivery:
1. Ruby-native non-xlang serialization format.
2. Decimal support.
3. Advanced runtime code generation in first iteration.

Performance expectations:
1. Keep hot serialization and deserialization paths allocation-conscious.
2. Add fast paths for homogeneous collections where safe.
3. Preserve protocol correctness while improving throughput and reducing allocations.

Skills:
Ruby, binary protocol implementation, serialization internals, cross-language compatibility testing, CI integration, performance optimization.

Difficulty:
Hard.

Project size:
Preferred 350 hours.

Potential mentors:
Chaokun Yang, Weipeng Wang.

Source links:
https://github.com/apache/fory/issues/3379
https://github.com/apache/fory/blob/main/docs/specification/xlang_serialization_spec.md
https://github.com/apache/fory/blob/main/docs/specification/xlang_implementation_guide.md
https://github.com/apache/fory/tree/main/rust
https://github.com/apache/fory/tree/main/java