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.
Last year oppia introduced python typing using MyPy (static type checker) in the backend codebase, but currently more than half of the backend codebase is still pending with type annotations. So, the proposal shares the idea of mainly introducing type annotations into the whole codebase. The proposal also documents the idea of removing docstring type annotations because, after the codebase is fully typed these docstring typeinfos are just duplicate information. Also to follow this new docstring style throughout the codebase, implementation of the updated python docstring lint checker is documented.
<p>The project aims to provide a hassle-free solution to the process of enrolling the student in a course by the instructor and provide end-users with a spreadsheet-like experience. Improving the overall UI by implementing a spreadsheet like an interface for adding students in a particular course. The features that will be covered are -</p> <ul> <li>Add a new entry of data in the existing record.</li> <li>Modify any existing entry of students present in the data file.</li> <li>Delete an entry from the data input.</li> <li>Search for any existing entry present in the record.</li> </ul>
<p>This proposal aims to add a new Skills construct at a global level that would replace the existing refresher explorations method that is employed for specific answer groups in questions. Along with this, pretests can also be added to explorations testing particular skills. For this, a skill editor is created for skill creation. The questions for the skills will be from the common Questions construct in the back end. In the future, collections are to be removed and replaced by topics and stories, and hence this project lays the foundation for that also by creating a topic and story editor (and the backend constructs for the same) as well as integrating skills with those.</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.
<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>As part of this project, I want to add support for more variety of formats both for downloading data and for importing data into Teammates. Also, I will work on features, which give more granular control for reports customising.</p>
Currently, for trivial changes to lessons in Oppia, lesson creators cannot update translations in a convenient manner, it is a very tedious and repetitive process. This project adds the ability to update translations for existing languages in a convenient manner, when changes are made to a lesson. Also currently, Oppia faces issues with feedback for learners being missing in lessons, even in cases where it's known that something is likely to result in a misconception and the learner will be needing specific feedback. This project extends current functionality in order to display a list of misconceptions to the lesson creator and providing the ability to tag answer-feedback groups with said misconceptions, so that the lesson creators can accurately provide feedback to learners.
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.
Oppia's current Volunteer, Parent-Teacher and About pages currently lack the engagement and clarity needed to effectively convert visitors into users. This proposal aims to revamp the Volunteer, Parent-Teacher and About pages, focusing on creating informative and engaging content and design that aligns with the needs of our target audience as identified through initial user research
<p>Proposal for "Creator Dashboard" project</p>
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.
<p>This proposal outlines the steps that I plan to take in order to enhance the customization of the Sessions feature. It explores a possible approach in implementing a feature that would allow the Feedback Session Creator to specify which Feedback Giver should give feedback to which Feedback Recipient on a per-question basis.</p>
<p>My project involves fixing UI issues across the entire TEAMMATES platform, including overhauling the instructor help page, allowing respondents to submit each question on a feedback session individually, providing more contextual help and other improvements. The goal is to make the TEAMMATES platform even more user-friendly and accessible.</p>
Currently, Oppia’s feedback system is disjointed. Users can only submit lesson-specific feedback through the lesson player, which does not allow for screenshots or session logs. This makes it hard for users to report issues on the platform and for developers to fix problems based on that feedback. This project aims to create a feedback system that everyone can access. Users will be able to submit both platform-level and lesson-specific feedback from any page. The system will allow for optional screenshots and capture light session logs. All feedback will be stored in one place and can be reviewed easily through an admin interface. The existing creator feedback tab and the feedback-updates page will also be redesigned to work with the new system.
Scala Native is an ahead-of-time and prevalent compiler for Scala. The traditional compilation is to compile Scala into Java Virtual Machine(JVM) bytecodes, which are executed by JVM. Scala Native compiles Scala into LLVM intermediate representation(LLVM IR) rather than JVM bytecodes. This property decreases the overhead of JVM and improves compilation performance. However, one of the most criticized aspects of Scala Native is its slow compilation efficiency and long build time, especially for large projects. Therefore, the optimization of Scala Native is urgently needed. The aim of this project is to build benchmarks to evaluate the performance of the Scala Native linker, and explore feasible solutions to accelerate the building task of Scala Native. Three aspects are going to be exploited: speeding up the optimizer, introducing incremental compilation, and changing the compilation and linking procedure. As a result, we expect to create benchmarks for evaluating the performance of Native Scala, and to reduce the build time by at least 20%.
<p>Scala Native is the a new Scala compiler under development. This compiler will permit Scala users to compile directly Scala code to binary and use many functionalities of the C language such as memory allocation and most of the standard libraries. Since this compiler's target isn't Java Bytecode, the java libraries can't be used as is like for standard Scala, thus part of the work of Scala Native team is to write a Scala implementation for the Java libraries. This project aims to implement java.util.concurrent.* library for the Scala Native compiler.</p>
<p>The current way of interacting with the Popper engine is through the Popper CLI tool. This tool implements all the features of the engine including execution, scaffolding, CI integration, etc. A project that wishes to use the Popper engine has to use the CLI tool. I propose separating Popper into two parts in order to make it easier to use the workflow execution engine in other projects: First a library with all the execution engine itself. Second, a CLI frontend that implements the aforementioned library. With these changes users will be able to extend Popper by creating new ActionRunner and Workflow subclasses. In addition I wish to implement a REANA workflow engine for Popper, this will allow Popper workflows to use all the features REANNA has like kubernetes, workflow specifications, shared storage systems, container technologies, etc. This will also expand the REANA ecosystem and give existing users of the platform another way of defining workflows.</p>
<p>The project aims to design and develop a Peer-to-Peer Messaging app that does not rely on a central server to send messages across the peers. The app is intended to provide privacy, high communication-efficiency, censorship resistance and extra resilience to the users.The app should be reliable and usable dependent/independent of network connectivity.</p>
<p>In this proposal, I mainly focus on two dimensions provided by Quark-Engine, including resilience and performance. According to the mentor, there are some critical issues needed to solve below.</p> <h5>Resilience</h5> <p>For maintainability, it is necessary to deprecate Androguard, which is not a maintained library anymore, for Quark-Engine. Radare2 is an alternative tool recommended by the mentor and can replace all the functions of Androguard. The proposal aims at continuously improving the new core library until it is reliable enough to be used in Quark-Engine.</p> <h6>Performance</h6> <p>Quark-Engine consumes many resources when analyzing a big file due to the core library and the sequential computation. We found that replacing Androguard can solve the former issue. And introducing parallel computing solves the latter, too. As a result, I plan to make Quark-Engine parallel with the following improvement strategy.</p> <ul> <li>Optimize the analysis algorithm.</li> <li>Introduce the concept of parallel computing into Quark-Engine.</li> </ul>
<p>Building a cross platform (Android/iOS) chat application which utilises Bluetooth and WiFi-Direct for communication, thus eliminating the need of a central server. The messages will be transferred using an optimal path which can be determined by underlying network protocols and/or GPS positioning. In particular the gossip protocol is used to relay messages through intermediate devices until it reaches its required destination.</p>
<p>The idea is to improve the current Susper Search Engine by helping to update the theme to the latest search engine site using Angular Material, add more search options such as language search, safe search, private results, country wise results and autocomplete feature. Implementation of internationalization features as well using Angular Translate API, which will bring i18n support to our angular project.</p>
<p>The idea is to build a sample diagnostics tool for ChromeOS using web technologies. This tool will be a combination of a Progressive Web App and a chrome extension that help users monitor and diagnose their devices. The aim of this app is to provide OEMs an example of how to develop diagnostic apps for ChromeOS. As a result, a new API surface will be usable for other 3rd party apps to use and integrate on ChromeOS. In the later stages, the project aims to use WebAssembly for processing and storing system data captured from the underlying platform.</p>
GnuCOBOL currently has no support for the Object-Oriented Programming (OOP) features defined by the ISO standards ISO/IEC 1989:2002 through ISO/IEC 1989:2023. Object-Oriented (OO) code currently leads to syntax errors due to lack of parsing support. The project aims to build support for parsing all OO syntax, and for a subset, also implement AST and codegen support to get a minimal working prototype of calling class methods through objects. Support for complex OOP features like method overriding and single inheritance will also be implemented. Multiple inheritance, method prototypes and parameterised classes are excluded for now. As a result, future releases of GnuCOBOL 3 will be able to parse OO code and report a simple error message about the pending feature. GnuCOBOL 4 will introduce the new paradigm to users. It will be able to generate working binaries for OO code and handle complex features like method overriding and single inheritance. The project will help bring GnuCOBOL closer to being compliant with ISO standards for OO COBOL and establish it as a significant choice among institutions looking for a free COBOL compiler with OOP support.