Explore Projects

<p>This project aims to implement a library that integrates with the existing coala code and allows writing native bears for coala that can leverage the power of ANTLR and enable them to advanced linting routines based on the parse-tree of a language with a given grammar.</p>

<p>coala is a linting and code fixing tool with support for many languages. Having a configuration file is essential to make full use of coala. Having a standardised configuration format like TOML helps. coala currently has an INI style configuration. Also, INI style configuration has certain limitations when it comes to custom sub-level parsing. The LineParser and ConfParser becomes complex and error-prone. This project will allow developers to quickly implement new features and will allow users to write configuration files in a format that they are already familiar with.</p> <p>This project would focus on :</p> <ol> <li>Allowing the user to create configuration files in TOML</li> <li>Providing coala with the functionality to create TOML configuration files from sections</li> <li>Creating a tool to convert .coafile to TOML configuration file</li> <li>Allowing coala-quickstart to generate configuration files in TOML as well.</li> <li>Creation of TOMLLintBear and a repository of good configuration files to allow users to easily bootstrap their projects.</li> </ol>

<p>This project is part of adding the 'aspect' functionality to coala-bears.</p> <p>Through this functionality coala users will no longer have to worry about searching for the bear or remembering the name of the bear appropriate for their work. They will be able to fix their code with the help of an ‘aspect’, which is nothing but a keyword that relates to the action they want the bear to perform on their code.</p> <p>This project aims at adding the aspect support to at least five more bears. Plus having properly defined and documented aspects for the same bears. After this project, these bears will get executed by using their respective aspects.</p>

<p>This proposes a new action system which will allow bears to define their own actions, hence make bears more useful. Implementation of such a system makes providing support for bears which can suggest multiple patches, which is a part of Improve Diff Handling project, easy.</p>

<p>Hyperledger Cello is an enterprise-grade Blockchain-as-a-Service (BaaS) platform that provides a comprehensive REST API for managing the full lifecycle of Hyperledger Fabric networks (Network, Node, Channel, Chaincode). However, all current operations require users to interact manually through the Dashboard, which presents a steep learning curve for newcomers.</p><p><br></p><p>This project aims to implement an AI-powered operation agent with chatbot interface for Hyperledger Cello. It consists of two components:</p><p><br></p><ol><li>AI Agent Backend: A Python service that wraps Cello's existing REST APIs into LLM. It accepts natural language requests, invokes Cello operations, and returns structured responses. It also provides AI-assisted fault log summarization for common Fabric failures.</li><li>Chatbot UI&nbsp;— A chatbot interface integrated into Cello's existing Dashboard (React), allowing users to interact with the AI agent.</li></ol><p><br></p><p>The combined system enables a natural language-driven operational workflow:</p><p><br></p><p>User (chat message) → Chatbot UI → AI Agent → Cello REST API → Fabric Infrastructure</p><h3><br></h3><h3>Learning Objectives</h3><ul><li>Open Source Collaboration: Familiarity with Hyperledger Cello workflow, code review standards, and CI pipeline.</li><li>Full-Stack Engineering: Experience building a production-integrated feature spanning a Python backend and a React frontend.</li><li>Applied AI Engineering: Proficiency in LLM Tool Calling integration, streaming response handling, and prompt engineering.</li><li>Blockchain Infrastructure: Hands-on understanding of Hyperledger Fabric network topology, node types, and Chaincode lifecycle.</li></ul><h3><br></h3><h3>Expected Outcome and Deliverables</h3><ul><li>Deliverable: AI Agent Backend</li><li>Acceptance Criteria: Python service exposing a chat API endpoint; supports natural language execution of core Cello operations (list/create networks, manage nodes, query channels and chaincodes)</li></ul><p><br></p><ul><li>Deliverable: Chatbot UI (Dashboard)</li><li>Acceptance Criteria: Chat panel integrated into Cello's existing React Dashboard; supports streaming responses; maintains multi-turn conversation context</li></ul><p><br></p><ul><li>Deliverable: Documentation</li><li>Acceptance Criteria: Setup guide for the AI agent</li></ul>

The Shmdata library provides a layer to share streams of framed data between processes via shared memory. It supports any kind of data stream: it has been used with multichannel audio, video frames, 3D models, OSC messages, and various others types of data. Shmdata is server-less, but requires applications to link data streams using socket path (e.g. "/tmp/my-shmdata-stream"). Shmdata is very fast and allows processes to access data streams without the need for extra copies. However, permissions are not supported, and any stream shared on the system with Shmdata is accessible system-wide. The project will enable the possibility for a Shmdata user to configure streams permission using shared memory right setting at the API level. When sharing data between processes via shared memory, not all components of the data need to be visible to everyone. Different groups might need to access different data, furthermore, some data might only be needed to be visible to the owner of the files. In such cases, the permissions that would have to be implemented are combinations of 'read', 'write' and 'execute' permissions that would be given to the owner, group or common user(i.e. everyone else). Permissions would be 'none', 'execute only', 'write only', 'write and execute', 'read only', 'read and execute', 'read and write', 'read, write and execute' with corresponding values of 0-7 respectively. DELIVERABLES * Providing an option for users to restrict or openly share data streams via these file/ directory access modes: read, write and execute/traverse. * Changing data access permissions. * Documentation for the improvements made. * Incorporation of ACL to assist with Unix file permissions. (optional/if time allows).

In the existing Karmada architecture, each component should have its own unique certificates to ensure clear identity and security. Best practices dictate that each component's name be used as the Common Name (CN) in its certificate to facilitate identity differentiation. However, currently, all Karmada components share same identical certificate content, leading to confusion and potential security risks. The objective of this project is to enhance the compliance of the Karmada certificate system by ensuring that each component possesses distinct certificates that reflect its identity. This will improve system security, reduce management complexity, and align with industry standards. This project aims to achieve the following standards: 1. Utilize a single CA certificate for the entire Karmada system. 2. Issue individual server certificates for each server component, using the component name as the CN. 3. Issue individual client certificates for each client component, using the component name as the CN, same client can use consistent certificate for different servers. Expected Outcome: 1. Complete the issuance of different certificates for 8 server components and import the certificate content into the corresponding certificate Secrets. 2. Complete the issuance of different certificates for 11 client components and import the certificate content into the corresponding certificate Secrets or Config Secrets.

<p>This project automates the task of sensing the health of the many Red Hen Lab remote capture stations, which are Raspberry Pi devices, and provides a responsive web dashboard that the management entity can use to easily perform her monitoring tasks. This has been achieved by implementing a set of scripts, whose execution in the capture stations is controlled over SSH and a comprehensive monitoring system using a centralized server (called Coop) built on the MERN stack - MongoDB, Express, React, Node.JS.</p> <p>The server consists of a Telemetry component which can communicate with the capture stations through SSH, a Control component which performs tasks like addition and updation of station metadata in the mongo database as well as report generation and backup upon user command and a frontend that allows visualization through a centralized dashboard that can be accessed through a desktop or mobile device with appropriate security credentials.</p>

<p>jQuery Mobile currently has a large number of open issues (~300). To maintain JQM’s vitality, this backlog should be necessarily cleared. This summer project aims to bring down this number to 50 (fifty) and categorize them in a proper and manageable manner and on the same time handle the communication and response to community both during and after the summer.</p>

<p>Testings of JavaScript application sometimes include modification of their own environment, such as global/native objects extensions and DOM manipulations. To avoid undesirable side effects, they have to be executed in a clean environment as much as possible.</p> <p>Since Intern JavaScript testing framework doesn't have this as the core feature yet, users have to manually reset or sandbox everything they care. The aim of this proposal is to solve this issue by implementing “sandbox interface” to Intern core API and make users get rid of the difficulties.</p> <p>The timeline of this proposal includes the following:</p> <ul> <li>Make friends with Intern's codebase</li> <li>Investigate and discuss with my mentors how this feature will be implemented</li> <li>Write actual codes</li> <li>Fix bugs</li> <li>Test and document everything I implemented</li> </ul>

<p>Projects like jQuery and Angular JS are written primarily with javascript and make extensive use of git as their version control system. Using git means that developers write commit messages. Nice and clean commit messages that adhere to an agreed-upon style are very common. So, implementing a way to validate these messages, like the commitplease project, makes a lot of sense. Currently, the commitplease project supports the jQuery style commit messages. Extending its support to the Angular-style ones (and possibly others) is a logical goal.</p>

<p>The goal of this project is to develop a framework for the development and presentation of interactive tutorials in order to provide a full learning experience.</p>

<p>The advantages of organizing a program into several files or modules are similar to authors organizing a book into several chapters and sections. The structure helps people who aren’t yet familiar with the code find what they are looking for and makes it easier for the programmer to keep things that are related close together. This project aims at developing a module system for the wonderful Hammer.js library that is flexible, predictable and extensible in the new ES6 version of javaScript.</p>

<p>My project aims to improve the development of testing tools through a common interface for reporters. It is hard because there are already so many tools and each one has its own interface and they will no renounce so easily, but we will try.</p> <p>To achieve this we will implement the specification in a quite popular testing framework, Qunit, and then we will try to engage also other people, mainly maintainers of other open source testing solutions.</p> <p>This way any one that will build in the future a new testing tool will be encouraged to use this interface, because it is time saving and less code to write, it is in the spirit of code reuse.</p>

The OpenPrinting website is an essential platform for Linux printing resources. The current system lacks modern UI enhancements and optimized SEO. Additionally, the existing Foomatic lookup page relies on SQL and dynamic web technologies, which I will be migrating to a fully static implementation. This transition will eliminate dependencies on an SQL server and a web server, with everything being managed exclusively on GitHub. This project aims to modernize the OpenPrinting website by migrating it to Next.js, a powerful React framework that ensures scalability, performance optimization, and maintainability. The transition will include: - Rebuilding the site with a modular, component-based Next.js architecture. - Migrating the Foomatic lookup page to a static page for improved efficiency. - Implementing Server-Side Rendering (SSR) and Static Site Generation (SSG) to optimize performance. - Deploying the new website with a CI/CD pipeline for automated updates and maintenance.

CampWiz NXT is the jury management platform used during Wiki Loves contests to evaluate media submissions, images, audio, and video, uploaded to Wikimedia Commons. It provides a structured environment for jurors and organisers to assess, score, and process contest entries at scale. The current implementation uses a dual-server architecture: a Next.js frontend and a Golang backend. While functional, this setup introduces real costs. There is server component complexity, a persistent Node.js process required for deployment, and an interface that places more cognitive burden on jurors than the work itself demands. These are solvable problems, and solving them is what this project is about. The goal is to migrate the frontend from Next.js to a pure React application built as a static output with Vite. This is not a surface-level reskin. The migration removes the Node.js server dependency entirely, allowing the frontend to be served over standard HTTP, making deployment simpler, cheaper, and more maintainable. The Golang backend remains unchanged; only the frontend layer is being replaced. Alongside the technical migration, the interface will be redesigned with a deliberate focus on clarity and minimalism. Jurors should be able to open the tool and immediately focus on reviewing submissions, not on navigating a cluttered interface. Non-essential actions will be removed from the juror viewport, decision controls will be streamlined, and keyboard accessibility will be enforced throughout. The organiser dashboard will receive the same treatment: clean workflows for contest setup, juror assignment, and results management, without requiring backend access for routine configuration. The result will be a frontend that is easier to deploy, easier to maintain, and noticeably better to use.

Description: Thanos is a distributed system that has a user interface written in React. Let's create a community instance with continuous integration for easy testing of how Thanos works. Also, it could serve as a testing ground for new React components. A server is provided by CNCF (https://github.com/cncf/cluster/issues/190).

<p>Implement several features potentially useful for users willing to broadcast live with Mixxx :</p> <ul> <li>Saving server credentials and connection info in one or several broadcasting "profiles" or "presets"</li> <li>Add the ability to do live streaming to several servers/platforms simultaneously</li> </ul>

This project aims to transform how analysts interact with threat intelligence data in IntelOwl by introducing a conversational AI interface. Currently, analysts must manually navigate dashboards, query APIs, and correlate results across different jobs and investigations. To solve this, I will integrate a privacy-preserving, self-hosted LLM chatbot using Ollama and a LangChain ReAct agent. The agent will be equipped with custom tools to query IntelOwl's internal REST API using natural language. Key deliverables include: 1) A new Django chatbot app handling WebSocket connections via Django Channels for real-time token streaming. 2) Ollama Docker integration with CPU/GPU auto-detection. 3) A native React chat component embedded in the existing frontend. 4) Custom LLM tools for triggering analyses and searching data models. 5) Comprehensive test coverage and detailed documentation for users and future maintainers.

<p>Meshery Models are declarative representations of infrastructure, applications, and their relationships - the canonical artifacts through which Meshery understands and manages cloud native systems. Today, Meshery lacks a standardized, portable distribution mechanism for these models. OCI registries (Docker Hub, AWS ECR, GitHub GHCR, and others) have emerged as the universal artifact store for the cloud native ecosystem, and [ORAS](https://oras.land) (OCI Registry As Storage) provides the Go-native tooling to push and pull arbitrary artifacts to any OCI-compliant registry. This internship implements end-to-end OCI registry support for Meshery Models - from new Connection and Credential types for major registries, to ORAS-powered push/pull logic in the Meshery server, to a redesigned Registry page in the Meshery UI that gives users full visibility and control over their model artifacts across registries.</p><p><br></p><p>Recommended Skills: Golang, REST API development, React. Familiarity with OCI image specifications, container registries, or ORAS is a plus. Experience with Meshery or other CNCF projects is welcomed but not required.</p><p><br></p><p>Responsibilities:</p><p>&nbsp;- Design and implement Connection and Credential types for Docker Hub, AWS ECR, GitHub GHCR, and additional OCI-compliant registries within Meshery's existing connection framework.</p><p>&nbsp;- Implement Golang server-side logic using the ORAS SDK to push and pull Meshery Models (and their component schemas, relationships, and policies) to and from any OCI-compliant registry.</p><p>&nbsp;- Define the OCI artifact media types, manifest structure, and layer conventions used to package Meshery Models for registry storage.</p><p>&nbsp;- Enhance or rewrite the Registry page in Meshery UI to surface connected registries, browsable model artifacts, push/pull controls, and credential management.</p><p>&nbsp;- Write integration tests covering push, pull, and round-trip fidelity of Meshery Models across at least two registry backends.</p><p>&nbsp;- Document the new registry integration, artifact format, and UI workflows in Meshery's official documentation.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;- Meshery users can connect to Docker Hub, AWS ECR, GHCR, and other OCI registries using managed credentials and push or pull Meshery Models directly from the Meshery UI and `mesheryctl`.</p><p>&nbsp;- A well-defined OCI artifact convention for Meshery Models, documented and suitable for adoption by the broader Meshery ecosystem.</p><p>&nbsp;- A redesigned Registry UI page providing a unified, registry-agnostic interface for model artifact management.</p><p><br></p>

<p>The Open Event project has SIX components:</p> <ul> <li>The Open Event Format Definition</li> <li>The Open Event Server</li> <li>The Open Event Generic Android App and It's Generator</li> <li>The Open Event Web App Generator</li> <li>The Open Event Organiser App</li> <li>The Open Event Frontend</li> </ul> <p>All the components support organizers in all stages from event planning to publishing, marketing and ticket sales for all kinds of events including concerts, conferences, summits and regular meetups.. Automated web and mobile apps help organizers in creating event web pages and apps without any investment or knowledge of development. This also helps attendees to get information easily.</p> <p>This proposal focuses on the <strong>Open Event Server, the Organizer App, and the Frontend</strong> for the summer.</p> <p>For the Open Event Server, remaining important features will be added in order to make it feature complete. These features would then be implemented in the Frontend and the Organizer App.</p> <p>The Organizer App's architecture will be revamped from MVP to MVVM. And new features from the server will be implemented while using reactive programming, dependency injection, and other modern standard libraries.</p>

This project addresses the issue of fragmented tools within the Kubeflow ecosystem, specifically Elyra, Kale, and Jupyter Scheduler, which complicates workflows for data scientists. The proposal aims to solve this by developing a unified JupyterLab plugin for Kubeflow. This plugin will consolidate and modernize the functionalities of the existing tools, providing a cohesive environment for developing, testing, and deploying machine learning workflows directly from JupyterLab. The plugin will achieve this by implementing seamless integration with Kubeflow Pipelines. Users will be able to convert notebook cells to pipeline steps, define and visualize pipeline workflows, submit pipeline runs, and monitor their execution status, all within JupyterLab. The plugin will be built with a modular architecture, including Python backend components for interacting with Kubeflow Pipelines and parsing notebooks, and TypeScript/React frontend components for the user interface. The key deliverables of this project are: • A unified JupyterLab plugin architecture consolidating Elyra, Kale, and Jupyter Scheduler functionalities. • Seamless integration with Kubeflow Pipelines, enabling notebook-to-pipeline conversion, workflow definition and visualization, pipeline submission, and monitoring within JupyterLab. • A user-friendly UI for pipeline development and management using modern React components. • Initial integration with Kubeflow Notebooks for easier notebook provisioning. • Comprehensive documentation and usage examples. • A robust testing framework to ensure plugin reliability, including unit tests, integration tests, user acceptance testing, continuous integration, and compatibility testing. This unified plugin is expected to significantly improve workflow efficiency for data scientists and ML engineers by bridging the gap between interactive development and production-grade ML infrastructure.

<p>The goal of this project is to write a replacement for the now removed ffserver component. It should meet the criteria proposed for the work on ffserver while there was still discussion about it. The result should be a multi-protocol streaming server that only uses the public API.</p>