Explore Projects

<p>Memory errors at the kernel of operation system are a kind of bugs that lead to grave consequences but are hard to detect. Debug and disclose of kernel memory corruptions often requires specially compiled kernel.</p> <p>I want to perform static verification of the Linux kernel latest release on memory errors by LDV project environment. I'll analyse results of static verification, provide patches to kernel for true errors and offer improvement to LDV staff to reduce false alarms.</p>

When DNS queries fail due to policy-based restrictions (e.g., BLOCKED, CENSORED, FILTERED), DNS resolvers can attach Extended DNS Error (EDE) codes along with structured JSON metadata in the response. This proposal aims to extend Chromium's DNS stack to parse and log Structured DNS Error (SDE) and Public DNS Error (PDE) content embedded in these EDE responses. The project involves extracting JSON metadata from the extra_text field for specific EDE and exposing them through the NetLog system. These improvements will provide more transparent diagnostics and support future UX enhancements. Deliverables: Full support for parsing SDE extra text and PDE, integration with Chromium's DNS resolution pipeline, NetLog exposure of parsed fields, and unit tests to ensure robust and secure behavior.

The Folksonomy Engine does not support intuitive property suggestions and reusable web components. In order to enhance usability and scalability, the system requires improved property suggestion mechanisms, more effective handling of nested values, and an easier-to-use interface for data contribution and analysis.\n \n To address the challenges in data contribution, consistency, and exploration, the project will develop new API features and create a reusable web interface. The proposed solution includes developing new API features and a reusable web interface. The main goal is to get as many contributors as possible to use this, making it easy and accessible for everyone to contribute.\n \n New API Features:\n - Suggestions based on popularity and categories\n - Adding User roles\n - Improved handling of nested property values\n - Adding moderation for bulk property, value management\n - Tools for exploring and merging values\n \n Improved Reusable JavaScript-based Web Interface:\n - For display and editing of data\n - Integrating folksonomy-editor to main project\n - Potential formalization of property definitions

This project bridges the gap between complex frameworks and basic, non-standard code. I will develop a modular, message-based flight software for the Open-Source CubeSat FlatSat Testbed using FreeRTOS. The goal is to create a 'sweet spot' firmware: accessible for students to learn, yet compliant with professional aerospace standards. By implementing a publish-subscribe 'Software Bus,' the system ensures that hardware drivers and mission logic are decoupled and interchangeable. This results in a scalable, flexible architecture that can evolve alongside the CubeSat hardware. Deliverables: Message Dispatcher: A thread-safe Software Bus for modular communication. Hardware HAL: Thread-safe STM32 drivers for the FlatSat sensor suite. Standards Core: PUS-compliant Telemetry, Telecommand, and Error Handling (FDIR). Testing: Unit testing and documentation of end result

This proposal targets the HSF 2026 idea Clad as a first class gradient engine in libtorch, a 350-hour project intended to make compiler-generated gradients available from LibTorch and, eventually, easier to reuse from the ROOT ecosystem. My goal is to build a practical and well-scoped integration path that allows a LibTorch C++ training loop to call Clad-generated derivative code for a small but meaningful subset of workloads. The primary implementation path is to wrap Clad-generated backward logic inside torch::autograd::Function, because the PyTorch C++ frontend explicitly supports custom autograd functions and presents them as the standard way to integrate optimized forward and backward code in extensions. If time permits and the API proves cleaner, I will also evaluate a custom-operator path based on the PyTorch C++ extension mechanisms. This proposal is intentionally scoped as a proof of concept, not as a general replacement for LibTorch autograd. A realistic first milestone is to differentiate selected training kernels or small model components written in C++, expose them to LibTorch, and measure where compiler-generated derivatives are correct, maintainable, and competitive. This produces a concrete result for mentors and also establishes a clear baseline for future work on broader operator coverage, deeper ROOT integration, or GPU support.

This project aims to modernize MetaCall's rs_loader by migrating it to the latest rustc compiler internals. The current implementation relies on outdated APIs, making it incompatible with newer Rust versions. The project will focus on updating compiler integration, replacing AST-based traversal with HIR-based extraction, and adapting to changes in rustc_driver and related components. The approach includes analyzing breaking changes, incrementally migrating core modules (lib.rs, middle.rs, ast.rs), and ensuring compatibility with modern Rust toolchains. Deliverables include a fully working rs_loader compatible with the latest rustc version, improved type and function extraction using HIR, and updated documentation for maintainability.

<p>The project aims to introduce Developer Options to oppia-android. There are many instances when a developer needs to make some database related changes. Doing this manually will take up lot of time and effort. Having such an option as this one will prove handy to perform these tasks without much effort and time. It allows the developers to have access to other debug related features such as viewing analytic event logs and forcing the network state of the app which will also prove useful. In short, this project aims to make the lives of developers in the Oppia team a bit easier.</p>

<p>A lot of parents tend to buy their kids tablet devices to help them learn new things through educational apps. Oppia is one of them, but it doesn't support tablet designs yet. And this project meets this problem.<br> Supporting tablet interfaces for the Oppia android application will give the users a better experience.</p>

<p>The aim of this project is to create necessary infrastructure so that machine learning algorithms can be efficiently trained and prediction can be done effectively. The project also requires implementing code classifier which will allow creators to train a classifier for code interaction input. This will allow Oppia to give feedback more efficiently whenever an input fails to classify in any of the hard rules specified by creator, rather than giving default outcome feedback.</p> <p>Basically there are 3 things to do in this project:</p> <ul> <li>Create necessary infrastructure for training of machine learning algorithms.</li> <li>Implement the code classifier algorithm.</li> <li>Enable the machine learning facility in Oppia so that creator can use it.</li> </ul> <p>The infrastructure to be used by Oppia for training of algorithm is called Oppia-ml. It provides Machine learning - as - a - service infrastructure for Oppia. Moreover prediction should be done in the frontend, in users computer so that there is no need of internet connection for giving feedback to the user. The outcome of this project is complete integration of machine learning framework and make it available to end user in production environment.</p>

'Helping learners when they get stuck' aims to implement numerous improvements to make the core learner experience more adaptive, effective and engaging. This project ensures that no learner ever feels stuck and can progress even when external assistance might not be available.

This project entails introducing support for measuring code coverage for all Kotlin files in the Android codebase with Bazel, with any support gaps documented.

Presently, reviewing translations is a tedious task for translation reviewers, mainly due to the current workflow of the contributor dashboard. This proposal aims to improve the workflow of the contributor dashboard overall by implementing various features that will enhance the user journey.

This project aims to improve Oppia’s acceptance test infrastructure by migrating existing tests from Puppeteer to Playwright to enhance stability, maintainability, and developer experience. The migration will be performed incrementally with dual-framework support to ensure CI stability. In addition, the project will address test flakiness by identifying and fixing persistent flaky tests, improving debugging workflows, and enhancing snapshot handling. The project also includes adding safeguards such as lint checks to prevent conflicts in shared utilities during migration. The expected outcome is a robust, maintainable, and reliable acceptance testing system with reduced flakiness and improved developer productivity

<p>Improving the existing question types by implementing the most demanded improvements is the sole focus of the project. The project does not focus on adding new question types. Some of the major goals of the work to be done are -</p> <ul> <li>Rubric question -<ul> <li>Allow columns to be moved which is a powerful feature.</li> <li>Better results.</li> </ul> </li> <li>MCQ question -<ul> <li>Implement Min/Max number of choices for an MCQ question, so that nomination questions can be asked, eg. “Nominate 3 students for prizes”.</li> </ul> </li> <li>Rank recipients/options question -<ul> <li>Implement Min/Max number of choices for rank type question.</li> </ul> </li> </ul>

<p>The primary goal of this project is to engage the learners in a long term learning relationship with Oppia by providing them with their personal learning space - the 'Learner Dashboard'. The dashboard will keep track of the explorations and collections completed by learners, the explorations and collections that are currently in progress, the creators to whom the learner has subscribed to and the list of feedback threads which he/she needs to read or respond to. In addition, learners can also create their own curated list of explorations and collections which they may want to play later.</p> <p>The learner dashboard will help provide an enriching learning experience and will bridge the gap between learners and creators. It'll be at the heart of the learning process and help the learner learn faster. In addition, this project will create the foundation for implementing a rich set of features like recommending the right next courses for individual learners and many other such exciting possibilities. This project, I believe, would mark a major milestone in accomplishing Oppia's mission - 'to help anyone learn anything they want in an effective and enjoyable way'.</p>

This project focuses on redesigning the Oppia Topic Page to make it more intuitive and easier for learners to navigate. Currently, lessons are presented in a story-centric layout, while practice and revision content are separated into different tabs, which can cause learners to miss important activities and struggle to decide what to do next. The redesign introduces a unified interface where lessons, practice, and revision content are combined into a single continuous flow. Learners will see a structured, scrollable sequence of lesson and practice cards with clear progress indicators and actions such as start, resume, and review. It also improves how language options are displayed and selected directly on the Topic Page.

Currently, Oppia has a pre-push hook which runs frontend unit tests on all files and lacks any backend unit tests in the pre-push hook which can lead to a lack of response for developers until it reaches the Github CI. Furthermore backend unit tests take quite long and similarly End-to-End, lighthouse and acceptance tests on the Github CI are all ran regardless of the PR's changes; all of these problems lead to developer distress. This proposal seeks to solve these problems by running frontend unit tests only on changed files and adding backend unit tests in the pre-push hook, to run similarly on only changed files. It also seeks to reduce Github CI and pre-push hook runtimes by optimizing backend unit tests. Alongside this, this proposal will reduce Github CI usage by running End-to-End, lighthouse and acceptance tests on only PRs which need them.

<p>This project aims to improve the testing and coverage of TEAMMATES</p> <p>Overview of Project:</p> <ul> <li>Reduce Technical Debt (Upgrade to Selenium 3.x)</li> <li>Explore new JS Unit Testing framework</li> <li>Update test cases to optimize CI Build process</li> <li>Add more test cases for missing features</li> </ul>

<p>Proposal for "Creator Dashboard" project</p>

<p>This project aims at implementing two new interactions- <em>Number with Units</em> and <em>Drag and Drop Sorting</em> interactions. It will create a new learner experience at Oppia in the form of interactions inside the explorations and will aim at improving the learner's skills.</p>

<h5>End-to-End Testing Support</h5> <p>Oppia Android's current testing corpus includes unit tests using the Robolectric testing framework &amp; integration tests using the Espresso testing framework (to ensure that the app operates as expected in a real Android environment). The current tests have a few limitations: they do not correctly facilitate cross-activity navigation flows which actual users will be triggering, and they do not verify that the app can interact with Oppia's backend correctly.</p> <p>To prepare for the global launch of the app, we need end-to-end tests that:</p> <ul> <li>Verify that the app works as a user would expect by playing through select critical user journeys</li> <li>Verify that the app operates as expected when interacting with a local developer instance of the Oppia backend server</li> </ul> <p>We expect that the tests will be written using UiAutomator &amp; are set up for interacting with a local development server (see <a href="https://developer.android.com/studio/run/emulator-networking.html" target="_blank">relevant documentation</a>).</p> <p>Note that this project requires running Linux with virtualization support (in order to run an Android emulator). You will need to make sure your computer supports <a href="https://help.ubuntu.com/community/KVM/Installation" target="_blank">KVM</a> and is running Linux.</p>

<p>The project enhances the current implementation of the comment feature.</p> <p>Features to consider:</p> <ol> <li>Ability for respondents to add comments for their own responses e.g. to add an explanatory comment when answering an MCQ question.</li> <li>Ability for instructors to add comments from more places. </li> <li>Possible extension: Ability to know if the comment/response was read by the student.</li> </ol>

The current onboarding workflow that the Oppia Android app offers is not intuitive enough. Users get confused or spend more time than necessary figuring out the features and how to navigate in the app due to lack of a better onboarding workflow. Sometimes users do not use a feature available to them that can ease their learning journeys due to lack of information. To ensure first time users have the best experience possible and to create an onboarding experience that is: Engaging but not time-consuming Educational but not text-heavy Interactive but not complicated Does not take too much time or clicks, especially if it is not interactive Does not add unnecessary visual or cognitive complexity Easily dismissible at all parts of the experience The app should show the onboarding flow the first time the user experiences whichever screen contains the interactive elements that should be explained. Each of these experiences may lead to multiple parts of the UI being highlighted, and should follow a predefined linear flow. There should be an option to cancel out of the flow, and the app should not show it again if the flow is either canceled or completed. Users should be able to access the onboarding flow if they cancel accidentally or forget something and want to go over it again.