Explore Projects

I propose to work on the following for enhancement of Friendly Error System : 1. Decoupling the Friendly Error System to a standalone package 2. Resolving Issues/Fixing Bugs on Friendly Errors Issues 3. Adding a new language translation(#3390) for FES error messages.

<p>To provide a rich experience to Octave users, the command line suggestion feature, aims to be a fast and accurate method to suggest corrections to the users whenever they make a typographic error while working on the Octave command window. It should also be able to provide the users, an easy method to select and execute the corrections suggested and enable/disable the feature. This could get tricky as Octave comes in both a GUI and a CLI. Therefore, for a successful integration of this feature with Octave, understanding how its parser, error handling, and internal functions work would be essential. The next part of the problem would be to generate the words to suggest. A trivial solution of this problem is easy but computationally expensive and hence not feasible. The challenging part therefore, is to minimize the speed-accuracy trade-off of the feature. A starting point for that would be a smart (probability based for example) implementation of the Edit-distance algorithm, using dynamic programming. Later, a Neural Network based idea would also be tested. The goal of-course, is to use the algorithm that best minimizes the speed-accuracy trade-off and provides the best UX.</p>

Casbin Core Engine is the first implementation for Casbin DSL. Though stable now, it lacks some important features like the WatcherEx support. Also, Casbin has many users with active feedback, which suggests useful features and explicit bugs. The goal of this project is to add missing features and make Casbin Core Engine more stable.

<p>OSM’s main search engine Nominatim does not support search suggestions. A separate database, which should be derived from the Nominatim database, should be set up for search suggestions. This DB should support regular updates from Nominatim DB. This must handle various languages. It must be small enough to run alongside Nominatim.</p> <p>This project aims at setting up such a search suggester by comparing various alternative implementations like Elasticsearch, Solr. These suggesters set up indexing to facilitate quick suggestions to the users. The finalized stack will be integrated with the Nominatim search API. Complete installation and setup documentation along with a test suite will be created as a part of this project.</p>

<p>Project Details: YooHoo, is a interactive chat engine, which supports text, audio, video chats and file sharing. It is to facilitate one-to-one chats, group chats, create events and manage them online(assign tasks and schedule deadlines etc). It has also got a integrated set of bots, for mainly connecting with wiki.debian.org, packages.debian.org etc to provide instant help for queries, suggest apps etc. It also include provision for creating new bots using custom codes. The main aim of YooHoo is to create a collaborative environment for those who are working on Linux systems. With its in-build bots it can provide live assistance to users, suggest the best apps available for his needs, get latest releases and news, which can improve user experience a lot.</p> <p>Benefits to Debian: Will help to provide automated help to its users (by the bot) as well as ask new queries, report bugs etc, thus bridging the gap between a normal user and Debian system.</p> <p>Why Debian?: Well, Once you start exploring her, your curiosity never ends. Of all the other distros I have used, I learned more on Linux by using Debian. She is simple, minimalist and is highly educative in a learn by doing approach.</p>

As developers, we always favor tools that enhance and streamline the programming process, including plugins that provide error reporting and insights to improve the code quality. Kotlin developers using Gradle rely on tools like Detekt and Ktlint to enforce code quality. While Detekt and Ktlint offer reporting in various formats like (HTML, SARIF), their current integration with IDEs can be fragmented, requiring developers to switch contexts and manually review findings, which disrupts the coding workflow and slows down their development process. This project aims to implement a unified and actionable code quality reporting system through the integration of the recently introduced Gradle new Problems API. This API provides structured and rich information about the problems happening during a build. The information provided can be used by different interfaces such as Gradle’s console output, build scans, or IDEs to communicate any issues. With this API integration and structured format of the generated report, developers can experience faster issue identification, streamline debugging, and have improved code maintainability. This project will provide value to the Kotlin development community by upgrading the quality of their error reporting.

<p>A peer to peer messaging app where one could send messages even when there is no internet using ad hoc networks over large area.</p>

The Genetic Optimization Module for MBDyn seeks to integrate a genetic algorithm (GA) into MBDyn, a multibody dynamics simulation software, to enable optimization within simulation runs. As a super-element, the module will leverage MBDyn’s drive system—taking inputs from drives that expose simulation data and outputting optimized variables to other drives. Inspired by the mbdyn module’s structure, the project emphasizes a self-contained GA implementation in C++ to ensure minimal dependencies. The development is split into two phases: a 175-hour baseline solver with core functionality and a 350-hour fully-featured solver with advanced features and optional external library integration. This proposal targets the 350-hour project, aligning with the Google Summer of Code’s 12-week timeline (approximately 480 hours at 40 hours/week), delivering a robust optimization tool for MBDyn users.

<p>The convergence is assessed by calculating norm of the residual vector and currently the residual vector has many terms with different physical dimensions. Comparing different physical dimensions with each other does not seem to be a good idea.</p> <p>So the main idea of the project is to categorize various equations and variables on the basis of their physical dimensions and calculate the residual norms for each of the physical dimensions separately.</p> <p>Finally the convergence test will be modified.</p>

The MBDyn Python Preprocessor aims to streamline the creation of input files for MBDyn simulations by bridging Python scripting with MBDyn's input format. Currently lacking support for all MBDyn entities, the preprocessor needs extension to cover all available entities. Additionally, integrating the preprocessor with Blendyn, a Blender add-on for post-processing MBDyn output, will provide a GUI based preprocessor for generating MBDyn input files. The project entails incremental development, starting with familiarization and planning, extending the entity library, managing model behavior, creating a model container, integrating with Blendyn, and finally, incorporating methods for aeroelastic models. These milestones culminate in deliverables that enable users to build entire MBDyn models using Python, including support for rotary-wing aircraft models, while ensuring completeness through thorough review and documentation.

<p>This project deal with implementing an unsteady potential-flow method namely the 3D unsteady vortex-lattice method for the aeroelastic analysis of the high-altitude subsonic aircrafts. Flexible multi-body simulation is carried out for the flight dynamics and the resultant loads from the aeroelastic analysis of the aerodynamic surface is used in the aforementioned dynamic analysis. Owing to differences in the mesh structures of the aerodynamic and the structural meshes of the MBDyn beams and interpolation method (namely Radial Basis function Interpolation) is used for coupling the two modules together and this coupled system is then solved using nonlinear time-marching schemes or are linearized and solved with highly efficient monolithic state-space schemes.</p>

<p>Development of a MBDyn interface from-and-to Flight Gear, that easily lets to get current values of any arbitrary field from the Flight Gear Property Tree, or impose them in order to control Flight Gear using MBDyn as flight-dynamics model. The interface must allow MBDyn-users to communicate with Flight Gear without the need to manage:</p> <ul> <li>sockets</li> <li>data cast when getting or sending values (and related byte-order troubles)</li> <li>data padding dependent on the architecture and on the structure of Flight Gear classes (FGNetFDM, FGCtrlsFDM)</li> </ul>

The MBDyn Python Preprocessor simplifies the creation of input files for MBDyn simulations by bridging Python programming with MBDyn's input format. This project enhances the simulation workflow through two key improvements. The first transforms the YAML-based Rotorcraft Parametric Modeling tool into Python classes within the preprocessor, creating an object-oriented framework for rotorcraft modeling. The second integrates the preprocessor with Blendyn (a Blender add-on), enabling users to create, edit, simulate and visualize MBDyn models entirely within Blender. These enhancements make MBDyn modeling more intuitive and accessible while providing a seamless workflow for both pre- and post-processing tasks.

<p>This project deals with improving and updating the capabilities of Blendyn, a post-processor for MBDyn. Some of the major deliverable for this project are:</p> <ul> <li>Complete the automatic visualization of elements.</li> <li>Visualization of internal forces and stress/strain fields of deformable components during animation</li> <li>Sync MBDyn execution and the Blender animation in order to see the Blender scene evolve during the actual MBDyn simulation</li> </ul>

There is a big problem for every DJ. Which is very specific. After playing hours of music, it shows up. “What to play next?”. What if we had a track suggestion feature in our DJ app? Track Suggestion Feature for Mixxx. So with this feature, Mixxx will have a helper next to us.

Integrate a new architectural component into Meshery: a workflow engine. This project involves shifting Meshery off of bitcask and off of sqlite over to postgres using gorm (golang). Interns will familiarize with concepts of orchestration engines, including chaining workflows, and content lifecycle management.

Integrate a new architectural component into Meshery: a workflow engine. This project involves shifting Meshery off of bitcask and off of sqlite over to postgres using gorm (golang). Interns will familiarize with concepts of orchestration engines, including chaining workflows, and content lifecycle management.

<p>Open source projects face an urgent governance gap as AI coding tools (Claude Code, GitHub Copilot, Cursor, Qwen Code) act on codebases with no shared coordination layer, no policy enforcement, and no auditable trail. The result is PR floods, duplicate issue work, and maintainer burnout.</p><p><br></p><p>GitMesh is an LFDT-native multi-agent orchestration runtime that closes this gap. This mentorship will implement&nbsp;Phase 1 (GitHub/GitLab Forge Integration)&nbsp;and&nbsp;Phase 2 (Policy-as-Code Engine)&nbsp;— building the&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">forge-sync</code>&nbsp;bidirectional webhook service, the&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">policy-engine</code>&nbsp;OPA integration with YAML-to-Rego auto-compilation, an append-only audit log with policy enforcement metadata, and a three-view maintainer dashboard. Real infrastructure, deployed to a live LFDT lab.</p><h3><br></h3><h3>Learning Objectives</h3><ul><li>Build a bidirectional webhook-based forge integration (GitHub/GitLab) with event-triggered agent wakeups.</li><li>Design a policy-as-code engine using OPA with YAML-to-Rego auto-compilation and real-time evaluation middleware.</li><li>Implement an append-only audit log capturing policy version and enforcement outcome for every agent action.</li><li>Build a maintainer approval dashboard (Active Agents, Pending Approvals, Audit Log) with mobile-first UX.</li><li>Learn AI agent coordination patterns — atomic checkout, budget enforcement, heartbeat scheduling.</li><li>Gain exposure to LFDT identity extension points (Hyperledger Identus, AnonCreds, Sigstore) planned for the future trust layer.</li></ul><h3><br></h3><h3>Expected Outcome and Deliverables</h3><ol><li>Forge Integration Service&nbsp;— Bidirectional GitHub/GitLab webhook receiver and outbound action service (post comment, add label, request review, close issue). Includes raw webhook storage and event-triggered agent wakeup support.</li><li>Policy Engine&nbsp;— OPA integration with YAML-to-Rego auto-compilation. Policy evaluation middleware injected into all agent heartbeats and API routes.</li><li>Audit Log Enhancement&nbsp;—&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">policyVersion</code>&nbsp;and&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">policyOutcome</code>&nbsp;columns on the activity log. Append-only, exportable as JSON/CSV, filterable by agent/action/time/outcome.</li><li>Three-View Maintainer Dashboard&nbsp;— Active Agents (status, budget), Pending Approvals (mobile-first), Audit Log (policy filtering).</li><li>Default Policy Template Library&nbsp;— Five ready-to-use YAML rulesets (no-merge-without-approval, no-CI-modification, security-advisory-gate, budget-hard-stop, triage-scope-limits).</li><li>Documentation&nbsp;— Architecture diagram, developer onboarding guide, YAML policy authoring reference, end-to-end test scenarios.</li></ol><p><br></p><p>Learn More at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/81" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/81</a>.</p>

The 2010s decade marked a beginning for widespread compiler testing with the release of programs like Csmith, a C program generator that since its release has found and reported over 400 compiler bugs. However, as highlighted by a recent study, the research on compiler testing has critically neglected the front-end component of compilers, leaving unfound bugs in the type checking procedure of compilers. More specifically, this could lead to the compilers of statically-typed languages, which utilize features such as type inference, both accepting erroneous programs and rejecting correct ones. Hephaestus is a tool designed to test the compilers of three languages, namely Java, Kotlin, and Groovy. It has already successfully detected over 150 bugs in the compilers of these languages. I propose a way to extend Hephaestus for it to be able to successfully test and detect bugs in the compiler of TypeScript. This can be a great contribution to the user-base and community of TypeScript, a language that has risen in popularity and usage in the past years. Hephaestus detects bugs by: 1. generating semantically-valid programs that (a) utilize parametric polymorphism and (b) are abstract 2. generating these programs in an intermediate representation (IR), an OOP language that supports parametric polymorphism and type inference 3. using translators to convert the abstract IR program to the desired language.

<p>The Friendly Error System in p5.js helps beginners with common errors, transforming error messages into a simpler form and checking for common mistakes. This project aims to extend the functionality of the FES, by adding new features and fixing existing issues.</p>

<p>Linux provides two message queue implementations, System V message queues, and POSIX message queues, none of which are currently implemented in gVisor. This project aims to extend gVisor by implementing a minimal version of System V message queues</p>

<p>This project aims to extend the Dotty documentation compiler (alias "Dottydoc") to make code examples found in comments type safe, with the purpose of ensuring that documentation does not become out of date. This will be done by compiling and running each example as the documentation is being generated, alerting the user if errors are found. Each line of the code examples on the generated documentation page will then be annotated with the output of its expression, in the same style as the scala REPL.</p>

<p>This project aims to endow <em>LearnBlock</em> with the ability to determine the different syntax-errors of a program and to display those errors in both, the visual program and the Block-Text code. Those parts of the code containing a syntax-error will be highlighted. In addition, information about the kind of error and some guidelines on how to correct will be displayed as long as the user asks for it (for instance, clicking on a highlighted statement or block).</p>