Fetching the latest programs, projects, and workspace data.
Find open source projects actively accepting contributors. Search repositories, filter by program milestones, difficulty tags, or tech stack.
Use our Orbit AI Matcher to find out! Get instant matching scores based on your developer skills, preferred frameworks, and contribution experience.
Convert your selected open-source project into a winning GSoC, LFX, or Outreachy application using Proposal Studio.
In Zulip, each message has a sender (linked to UserProfile) and a recipient (referencing the Recipient model). The Recipient model supports three types: 1. Personal -- linked to a single UserProfile 2. Stream -- linked to a Stream 3. Direct Message Group -- linked to a DirectMessageGroup Currently, 1:1 direct messages use the Personal type that directly links recipients to individual users. This project aims to migrate them to use the Direct Message Group type instead. The migration should be seamless with minimal downtime. It involves: 1. Updating the codebase to support 1:1 DMs using DirectMessageGroup. 2. Running a backfill migration to create a DirectMessageGroup for each user pair with existing 1:1 messages. 3. Cleaning up legacy code and adding additional fields that are needed. This migration enables per-conversation settings for direct messages, and features like pinning or hiding DM conversations can be implemented more easily.
This project focuses on implementing a cluster of high-priority features in Zulip across the message feed, compose box, and channel settings. In the compose box, it introduces reply-without-quoting, collapsed recipient pills for DM conversations, and auto-pillify on blur. In the message feed, it adds always-visible read receipts for DM conversations, multi-message deletion, a "New Messages" divider, move-by-recency for topics, and completes the zulip-icon-at-sign rollout to mention pills. In channel settings, it adds group-level unsubscribe for channels and shows inherited permissions as uneditable pills. The work builds on existing patterns in the Zulip codebase and focuses on shipping well-integrated, user-facing improvements across these areas.
This project aims to deliver a Rocket.Chat App that uses generative AI to summarize any conversations across threads, channels, and DMs. For example, a user can say, "summarize my unread messages yesterday in the #engineering channel". The users can ask AI any questions regarding the messages, and subscribe to personal digests that summarize selected channels on a recurring schedule. The AI summarizer will boost the productivity of Rocket.Chat users with faster information digest, and improve community engagement by keeping everyone on the same page.
As stated in the Mifos Forge, Users of Mifos have long had a need to have greater control and flexibility over creating loan and customer onboarding workflows that incorporate internal processes/steps as well as processes involving external systems. This project would center around creating an external integration with a workflow engine such as Flowable or jBPM using the Mifos X REST API as the glue. The auto-generated client library from the back-end enforces the contract between the workflow engine and the core banking system. The core banking and its REST API act as the glue. The result would be a UI-driven workflow engine to allow non-technical users to define these new custom workflows, where they could drag and drop the different steps of the process.
<p>My proposed Project consists of developing a GUI with Unreal Engine for Eye Tracking and any adjacent work involving the aforementioned tehnology.</p>
Specialization is a compiler transformation that optimizes generic program code such that code using primitive types can execute without significant overhead. The @specialized annotation in the Scala 2 programming language allowed programmers to direct the compiler to create optimized generic data structures for each primitive type. @specialized is used significantly in the implementation of high-performance Scala 2 libraries, allowing for performance without the productivity of generics. This optimization trades performance at the cost of extra space, as generic code must be specialized for each of the primitive types, scaling exponentially on the number of type parameters. Since the Scala 3 programming language has evolved significantly from Scala 2, the @specialized annotation is no longer available. This proposal will prototype a new scheme of specialization for the Scala 3 compiler based on inline traits that avoids the performance pitfalls of the Scala 2 implementation, enabling the evolution of many high-performance Scala 2 libraries into Scala 3.
Solang is an open-source Solidity compiler written in Rust. It generates an intermediate representation in a Control Flow Graph (CFG) for each function in a Solidity contract during compilation. The CFG contains high level expressions and instructions, which help in some aspects of code analysis and optimization, but are not suitable for more advanced optimization passes, such as liveness analysis and partial redundancy elimination. In this project, mentees will have hands-on experience implementing a modern Single Static Assignment intermediate representation for the Solang compiler. This addition will bring many advantages for the compiler, such as the possibility to break down complex constructs into lower level instructions and the facilitation of code analysis. We propose for the mentorship the introduction of a new intermediate representation to live between the existing one (the CFG representation - read more about it at the Additional Information section below) and the LLVM-IR. It should feature three-address code in a Single Static Assignment (SSA) minimal form. The construction of such a form happens in two steps: Phi function insertion Variable renaming The objective is to decouple the types and expressions we have used for the AST from the existing CFG intermediate representation. In addition, the new low level intermediate code must contain assertions that ensure the instructions are created with valid operands and expressions.
Most scientific and engineering applications heavily depend on floating point arithmetic. Floating point numbers only approximate the real numbers, which can lead to accumulation of errors and ultimately to unusable results. Current state of the art of floating point arithmetic optimization is done in Rust (egg) or Racket (Herbie). This is not very accessible for the actual target group of scientists & engineers who are used to program in high-level languages such as Python, MATLAB and Julia. Additionally, it requires manual labour (rewriting symbolic expressions, then optimizing them, and finally translating the resulting code back to the original language) due to the necessity of interfaces to interoperate between different systems written in different languages. We propose to take advantage of Julia's homoiconicity and powerful existing symbolic-numeric ecosystem to implement an automatic floating point expression optimizer in Julia, acting on any expression that supports TermInterface.jl, such as Symbolics.jl expressions as well as native Julia code. The project will include a package that implements the floating point expression optimization apporach (OptiFloat.jl). To achieve this Metatheory.jl will be fully integrated with Symbolics.jl, enabling e-graph based optimization of any symbolic expression (not just numerical). Additionally we will finalize the release of Metatheory.jl v3.0, identify existing Julia packages that may suffer from numerical error propagation, and perform a thorough comparison of automatically optimized expressions vs. original vs. external system including the time required to obtain them.
This proposal aims to solve the issue of using high-order functions with asynchronous functions when there is no platform support of continuations and without implementation of two variants of HOFs (synchronous and asynchronous). The plan is to add basic functionality of auto generation of CPS transformed HOFs in the dotty-cps-async compiler plugin.
<p>LANPR is a fast and accurate 3D NPR feature line rendering engine developed for Blender 2.8 NPR branch. This project is aimed to complete the rendering workflow and make it more production ready. If time permits, more functions might also be implemented, such as to integrate LANPR with existing Freestyle line modifier compatibility.</p>
I intend to propose an approach to transfer the messaging protocol of the application from the naive push protocol. The push protocol has many disadvantages and so we need to migrate to either pull protocol or hybrid protocol. The hybrid model that we will try to use in this project is the First-Push-Then-Pull protocol. We can either choose the pull protocol or go with the hybrid protocol.
<p>Artists love to work with MyPaint brushes and it would be nice to integrate the same in Krita. The goal of the project is to integrate the MyPaint Brush Engine in Krita using the libmypaint library, so that Krita is able to load, save and work with MyPaint brushes. The secondary objective is to expose the MyPaint brush properties in Krita's brush editor to enable the creation and modification of MyPaint brushes.</p>
<p>CBT is a build tool in its infancy with a lot of room for optimisation and enhancement. As such, development is still very fast moving. The goal of the project would primarily be to threefold: decreasing build time by having CBT work completely in memory with a virtual file system; adding support for download center upload and deployment; and implementing a cloud compilation feature to exploit the benefits of cluster computing.</p>
The Thanos engine is capable of executing queries in a distributed manner, by pushing down aggregations to other querier nodes. This querying mode is not yet integrated well in the UI and is not exposed to users. The goal of this project is to add the needed integrations to the Thanos UI and officially release the feature to end users. - Expected Outcome: The expected outcome of the project is to have a fully integrated distributed querying capability through the Thanos UI.
<p>Current versions of Jenkins Remoting are based on the TCP protocol. If it fails, the agent connection and the build fails as well. There are also issues with traffic prioritization and multi-agent communications, which impact Jenkins stability and scalability. This project aims an update of Remoting and Jenkins in order to add support of a popular message queue/bus technology (RabbitMQ or Kafka) as a fault-tolerant communication layer in Jenkins.</p>
Open Rocket.Chat communities face a growing problem where new accounts join, flood multiple public channels with spam, and disappear before any moderator can respond. Current moderation is entirely reactive and manual, which is simply too slow for coordinated spam campaigns. This project builds a proactive, human-validated anti-spam system that monitors new users during their first 6 to 10 weeks and responds through a graduated restriction system called Moderation Levels, where every action is proportional, reversible, and requires admin approval before anything permanent happens. The system is built as a Rocket.Chat App on the Apps Engine with a seven gate detection pipeline running entirely in memory for speed. Gates catch exact duplicates via hash matching, polymorphic spam via cosine similarity, cross channel floods, rate flooding, rapid room spread, and phishing link campaigns. A four tier Moderation Level system escalates naturally with repeat behavior, from a friendly DM warning through posting cool downs to a permanent block that only lifts when an admin vouches for the user. The admin control layer includes a live dashboard, a full slash command suite, and AI powered on demand summaries so admins have everything they need to make confident moderation decisions without opening a single log file. Deliverables include a fully functional installable Rocket.Chat App covering the complete detection pipeline, a configurable Moderation Level system, a behavioral scoring engine, enriched admin notifications with message history, AI powered user analysis commands, a paginated admin dashboard built for scale, daily scheduled reporting, and complete documentation covering architecture, configuration, and known limitations.
<p>The RobCoG project is presenting a new perspective on how robots are supposed to learn everyday tasks. Learning from humans essentially playing a game not only enables robots to learn via crowdsourcing, but is also a great way to interest laymen in the subject. This is already a working feature in openEASE, however I would like to bring similar visualisation functionalities to RobCoG. This would unlock the state of the art rendering techniques of the Unreal Engine to the KnowRob/Ros world.</p>
This project implements the idea “Semantic highlighting in VS Code” * in the Scala Center. Summary of process is as follows. 1. Building the VS Code semantic highlight framework into Metal. 2. Implementing "vscode.SemanticTokensBuilder'' for Scala (perhaps using the presentation compiler of Scala). 3. Taking care of other factors (test plan, settings, and Non-functional requirements) *https://github.com/scalacenter/GoogleSummerOfCode2022#semantic-highlighting-in-vs-code
The proposed solution introduces comprehensive tracing capabilities to the LLM4S toolkit by integrating OpenTelemetry (otel4s) for capturing detailed spans and metrics during LLM operations such as prompt construction, model invocation, and response parsing. These telemetry signals are exported in Prometheus and Jaeger-compatible formats and processed through the OpenTelemetry Collector. The data is then visualized on a unified Grafana dashboard, allowing developers to monitor performance, debug errors, and analyze execution flows across different LLM providers in real-time.
This proposal aims to integrate Scala 3 support into the Scala Webapp Template, providing a more accessible, reliable, and powerful solution for developers interested in building web applications using Scala and Scala.js. The integration will involve updating the backend and frontend code to utilize new syntax and features of Scala 3, ensuring compatibility with existing Scala 2.13 code through cross-compilation, and updating libraries and dependencies as necessary. The proposed approach also includes testing, documentation, and optimization of the updated components.
<p>ENSIME is an IDE feature provider, available for most popular text editors. Currently, it uses regular relational database with a Lucene full-text search engine on top of it, to store and index whole project structure with its dependencies, but given the natural structure of the relations between things we would want to store (i.e. dependency files, classes, fields and methods) it is apparent, that a graph database can be used to achieve great success in both supporting old and introducing new exciting features, such as show implementing classes or project classes hierarchy.</p>
<p>The project proposes flexible pipeline handling mechanism for RoboSherlock framework. The current state of RoboSherlock implementation does not allow to process multiple Analysis Engine pipelines concurrently, as well as the abilities to branch pipeline into multiple subprocesses or merge the results from multiple pipelines into one Common Analysis Structure (CAS). Therefore, this extension project will develop paralleled pipelines handler API and enhance the processing effectiveness of RoboSherlock. The proposal describes the goal, high-level architecture plans of the module and finally milestones of the project.</p>
<p>Semantic information is essential for rich IDE features such as <code>go-to-implementation</code> and <code>rename</code>. Metals utilizes semantic information extracted from the compiler in a SemanticDB data model form to realize several features. However, SemanticDB generated from Scala3 lacks some kinds of information: Signature and Synthetic. Therefore some IDE features are not available in Scala3 projects.</p> <p>The objective of this project is to improve the SemanticDB extractor for Scala3, and pave the way to better Scala3 support in Metals, scalafix, and other dev tools relying on SemanticDB.</p>
LLM4S is building a Scala-native AI toolkit that leverages functional programming principles and strict compile-time checks to ensure the reliability and maintainability of LLM-powered applications. This project aims to extend the initial agentic loop and implement essential tools, empowering Scala developers to build robust, reliable, and explainable AI solutions. Key objectives include implementing a robust agentic loop, integrating MCP for dynamic tool interaction, developing core tools for file systems, ensuring context management, testing frameworks, and comprehensive documentation to support reliable LLM-powered applications.