Explore Projects

<p>With its innovative threading model and robust web app, Zulip has received a lot of praise from remote teams that use it. While the desktop app is certainly complete in terms of features, it needs some polish and certain standout features to make it an obvious choice for a Zulip user to install. In this proposal, I suggest the implementation of multiple features like enterprise deployment, an updated server validation logic, migration to another database, and a resource manager to improve the overall performance and stability of the app.</p>

<p>This project would bring the mathematical prowess of Julia to the web with the near native performance of WebAssembly. The expected outcome of this project would be in compiling numerical kernels such as GCD and Matrix Multiplication, facilitating the compilation of BLAS-style libraries. In the long term this project could be used to: compile full Julia libraries, with support for running their automated tests; and the ability to bootstrap the compiler, which would enable actual Julia code to be used locally in the browser.</p>

<p>DigiKam is a famous open source photo management software. Face engine is a tool helping users recognize and label faces in photos. Following the advance of Deep Learning, digiKam development team has been working on the Deep Learning implementation of Faces engine since 2018. During the past few years, with the huge effort of digiKam developers and the great support from users, the Faces engine has been improved gradually.</p> <p>However, the Faces engine still has some issues that were not yet eliminated. For example, in the core algorithm, we still get many false positives because the faces engine tries to include all the faces to the known range of labels. In the face pipeline, a lot of implicit memory conversion between QImage, DImg and OpenCV Mat, which for some reasons, adds noise to the images.</p> <p>Therefore, for this 2021 Google Summer of Code, we are going to improve the detection/recognition performance with outlier faces suppression (i.e. new faces should not be counted as untagged faces), the ability to work on large datasets, and an ease-of-use face workflow improvement.</p>

The ros2_control framework uses a plugin-based system to support multiple hardware drivers at the same time. It takes care of resource constraints between different controllers and hardware components, asynchronous operation of controllers, etc. As of now, controller_manager publishes the diagnostics of itself, and for controllers and hardware components about their lifecycle state and operational statistics such as their periodicity and their execution time. However, A current limitation of the framework is that hardware components, e.g. the ros2_control hardware driver plugin for a given robot, doesn't have a good API for reporting the diagnostics of its own hardware, for instance, the state of the CAN Bus, some internal motor control board stats like temperature, error codes etc. This integration would make the ros2_control, provide complete diagnostics within its ecosystem. This project focuses on setting up an API that hardware manufacturers & driver maintainers can use to report things with minimal code changes to their existing setups. This project thus aims to add reporting capabilities to the hardware components with minimal changes. It will also aim to unify the three existing hardware interfaces into one as they currently contain a lot of similar code. Furthermore, to enhance the contribution, there will also be focus on adding contributions to exisiting widely used Hardware Interfaces with the new API so that the work is adopted with ease, and the community has better references to work off of.

This project focuses on Distributed Error Reporting in Kolibri Learning Platform. Kolibri mostly focuses on offline access to education where Internet connectivity is low. So with this project we will be able to trace errors when users are using the app(and store in database) and to ping the Kolibri server with all the errors whenever the connection is restored.

This proposal focuses on building a system that shows users their “impact”, modeled using points for completing tasks that ultimately provide value to learners (such as successfully submitting practice questions/translations and reviewing user-generated suggestions).

<p>Proposal is based on two project ideas:</p> <ol> <li>Notification engine for sending custom emails choosing re-usable templates with variables support</li> <li>Rich-text support</li> </ol>

<p>The Oppia development workflow uses lint checks to help detect style errors before they reach the review phase. This project aims to refactor the linter and implement the remaining lint checks in the codebase and make the linting process more robust by adding tests.</p>

The Oppia Contributor Dashboard allows users to submit suggestions for translations and practice questions, which are then reviewed and accepted/rejected. Unfortunately, the existing contributor dashboard has only been developed with a focus on desktop/laptop users. The aim of this project is therefore to implement a responsive UI for the contributor dashboard page and related user flows.

<p>Physics seems to be a challenging task in HTML5 and especially on mobile devices. Changes will not only be extensions to the current implementation but will also have an impact on the current rendering engine and existing features (bricks), e.g. Catrobat sprites are based on images, physics on vertices. Not only the implementation, also tests, requirement engineering, evaluation of existing physics engines are interesting parts of this project I would really like to work on.</p>

<p>This project aims at adding strict static type checks to Oppia codebase. In this project, static type checking will be done with the help of Mypy. Adding static type checks is useful in catching errors before runtime and helps developers in debugging the program. In this project, type annotation will also be added to a part of the codebase.</p>

This project is centered around enhancing the experience of playing through explorations -- Oppia's lessons, which are the primary means of learning on the platform -- and aims to provide learners with positive reinforcement as they progress through one. This will be achieved by placing messages at the checkpoints of an exploration, which are meant to display to the learner their progress and to cheer them on ahead, and by congratulating the learner when they successfully complete an exploration, followed by providing them with further learning recommendations.

<p>This project aims to add review tests and improve the current question framework. After this project, review tests will be shown after going through a few lessons. The tests results will be used to update skill mastery level, so that learners can review and practice according to the mastery level and suggestions. Tests results will also be sent to creators once a few months to help improve the questions and lessons.</p>

<p>This project aims to introduce support for displaying the Copyright Licenses of the third-party Maven dependencies used to build the Oppia-Android application. The implementation involves creating Kotlin scripts to compile the list of Maven Dependencies via Bazel query and Bazel Maven artifacts pinning mechanism, extracting the links to the Copyright Licenses of the Maven Dependencies from the POM files, and then generating a resource XML file that contains the dependencies' names, version, and their license texts. A new UI is also introduced to display the list of maven dependencies and their licenses.</p>

<p>PowerPointLabs is used by people around the world, and is being developed and maintained by students of National University of Singapore. These selected students take on the project as a school module or internship project. While having a regular rotation of new developers provides creativity and multiple perspectives which helps improve PowerPointLabs, it may introduce some deviations in the coding style, technology used, and preferred workflow. These may accumulate and cause the project to become hard to maintain and its public release to stagnate. This proposal offers my suggested approaches to make PowerPointLabs more maintainable for its developers, while keeping it updated for its users.</p>

<p>Currently, <a href="https://www.oppia.org" target="_blank">Oppia</a> is serverside rendered using the <a href="http://jinja.pocoo.org" target="_blank">jinja</a> templating engine. This poses some performance issues since each time a page is being loaded, the server has to generate a new copy of the page to be rendered hence, the pages can not be cached.</p> <p>This project aims at removing the jinja templates used in serving of pages to a more static method, fetch the dynamic content needed for each page via AJAX calls and update the page as needed.</p>

<p>This project enables the edits made by the creators in the exploration to sync in the background so that the two creators can easily work simultaneously on any exploration. After this project, in case the versions of exploration on the browser and server don't match, the changes made by the user will be compared with the changes made in the backend by another user and if the changes are unrelated then the changes will be easily merged and if are related then the user will get a conflict error along with conflicting changes. This project will also enable the autosaving of the changes made by the user even if they are offline or the connection is flaky and then save their progress automatically when they have reliable network access.</p>

<p>The project, improving the development workflow, emphasizes on the following aspects:</p> <ol> <li>Reducing the reviewer time by automating lint checks and tests for Oppia developers and code reviewers.</li> <li>Catching errors with the help of non-flaky and thorough end-to-end tests before they end up in production as well as incorporating multiple browsers and mobile viewports in the tests.</li> <li>Automating routine processes like CLA checking, closing stale pull requests and helping resolve merge conflicts and build failures by notifying the maintainer-on-duty and the pull request authors.</li> </ol>

Currently, Oppia translates non-user-generated content via translatewiki and some user-generated content via the contributor dashboard. This project aims to extend the contributor dashboard's infrastructure to support translating exploration metadata (titles, tags) and skill (concept card) content. The solution involves building a highly extensible backend translation framework to display translation opportunities, surface reviewable suggestions, and display accepted translations to learners. Deliverables include migrating existing translation support to this new modular infrastructure (Milestone 1) and adding full support for metadata and skill content while removing legacy code (Milestone 2).

Oppia frontend codebase is fully typed, but our typing doesn’t yet pass strict TypeScript checks. This means that variable assignment, procedure parameters, and function return values will all be clearly connected with a type. Strict is a typescript compiler option that enables a set of tougher type rules that, when enabled, assist lower the possibilities of producing surprising outcomes and make the code more resilient, but Oppia's code base presently fails to pass these stringent requirements. As a result, the code is vulnerable to unexpected actions and failures. To avoid this, modify the strict TypeScript config file such that all newly-added files must be strictly typed, and Introduce strict typing for about 280 twins of files, as well as tests for those files (for a total of 560 files), and ensure that no more unknown type is used, as well as removing all unknown type usage from the newly strictly typed files. The document also lays out the whole implementation approach for the idea, as well as the milestones I'll need to fulfil to finish this project.

With this proposal, my aim is to make Oppia's learner-facing pages more accessible by by learners having any form of disability. My suggested method involves two-fold approach. I'll start by addressing the accessibility issues (a11y) that have already been reported on the site. This will entail addressing difficulties with heading-related issues, focus management, colour contrast, and more. Many of these a11y issues have contributors associated to them. While I resolve the unassigned problems, I will be available to help any contributors who get stuck or require further support. Second, I'll utilise Lighthouse to evaluate every Oppia page that is intended for students, raising their accessibility scores to a perfect 100. Each learner-facing page's Lighthouse test audits will need to be examined in order to make the necessary changes. This will include adding alternative text for images, making sure header tags have the right semantic structure, and making sure aria-roles are contained by the appropriate parent. Also, in order to aid contributors in understanding the Lighthouse audit procedure and troubleshooting any potential problems that may emerge throughout testing, I will be adding guidance on how to debug Lighthouse tests to the Oppia documentation.

Oppia Android's release process currently relies on a 17-page manual document that release coordinators follow step-by-step, covering everything from cutting branches and building binaries to signing, deploying to Play Console, and writing changelogs. This is slow, error-prone, and has caused QA testers to miss builds due to Play Store sync issues. This project replaces that manual process with six GitHub Actions workflows backed by Kotlin scripts that handle building, Cloud KMS signing, Play Console deployment, Firebase App Distribution for QA, LLM-powered changelog generation, and automated weekly alpha releases. All scripts are designed with interface-based abstractions (CloudSigner, PlayConsoleClient, VertexAiClient, GitHubClient) so they can be thoroughly unit-tested with fakes, requiring no real GCP credentials in tests. Security is handled through Workload Identity Federation (keyless auth) and Cloud KMS HSM-backed signing, ensuring the private key never leaves Google's hardware. Deliverables: 6 new Kotlin scripts with full test coverage, 6 GitHub Actions workflows, updated wiki documentation (playbook + manual fallback reference), and an end-to-end demo of the complete release cycle running through CI.

<p>My most favorite thing about Oppia is its Test-Driven-Environment. All these tests (FE, BE, E2E, Lint) will ensure that no new error or bug will be introduced into the system. Since Oppia is one of the most prominent open-source organizations, it needs rigorous testing and 100% coverage.</p> <p>Oppia’s frontend codebase can be broadly classified into four main categories.</p> <p>1.Components</p> <p>2.DIrectives</p> <p>3.Services</p> <p>4.Others</p> <p>We have a total of 205 components. In which, 163 components have 100% coverage. Partially covered components are 42. And finally, uncovered files are 0.</p> <p>We have a total of 203 directives. In which, 15 directives have 100% coverage. Partially covered directives are 188. And finally, uncovered files are 1.</p> <p>We have a total of 333 services. In which, 262 services have 100% coverage. Partially covered services are 71. And finally, uncovered files are 0.</p> <p>By excluding others category, we should thoroughly test and should achieve 100% coverage in components, directives, and service.</p> <p>My primary focus for this project is only unit testing. Although I'll be doing angular migration as an optional entity.</p>