Important: We are making some changes to how we run GSoC for 2025. Please read this page carefully, since some things have changed from previous years.

This year marks the 10th year that Oppia will be participating in Google Summer of Code (GSoC)! GSoC is a global program which offers post-secondary students, as well as newcomers to open source, an opportunity to discover and work with open source organizations. The contributions are supported by a stipend. Contributors work closely with one or more mentors to implement either a project idea by the organization, or a proposal of their own.

In order to receive updates about GSoC at Oppia, please subscribe to the Oppia GSoC Announce mailing list, as well as the Developer Announcements category on GitHub Discussions.

This year, based on previous years' feedback, Oppia plans to follow a slightly extended GSoC timeline: projects will have 7 weeks for each milestone, with an additional "holiday week" between the milestones. Each milestone includes 5 weeks of coding time, 1 week for evaluations, and 1 week for fixes, as well as a product demo session after the 4th coding week. Please refer to the Dates and Deadlines section below for more details.

Also, please note that acceptance into GSoC isn't a prerequisite for becoming an Oppia contributor. The Oppia project is run by a global community dedicated to making meaningful social change, and we warmly welcome anyone who'd like to help out! You can get started by following the instructions here (Web, Android).

Contributors

GSoC is an excellent opportunity for new contributors to get paid to work on an open source project. If you're interested in applying as a contributor, we strongly recommend reading this entire wiki page, including our FAQ which answers many of the common questions we receive.

You should also definitely read the following resources:

Google Summer of Code contributor guide
Google's list of resources
Google's GSoC FAQ

Furthermore, note that GSoC isn't just about code -- it's also about communication and interaction with the open source community! Hear what some of our previous contributors have to say:

I learnt a lot from this organisation -- tackling a huge codebase, writing clean and efficient code and communication.
I learn a lot of things in Oppia which I didn't learn in my school and college. It's not necessary that only a software engineer can contribute, anyone can contribute to Oppia with his/her skill.
I like the fact that the maintainers are so sincere in their work and are very responsive.
Oppia Foundation is really awesome and I get to interact with amazing people and learn a lot. The best part is that everything is organised really well and that makes it easy to solve my issues.
The Oppia Foundation excelled in fostering a supportive and inclusive environment for contributors. The responsiveness of the mentors and the community was remarkable, making it easy to seek guidance and get help whenever needed. The clear communication, structured processes, and well-documented codebase greatly helped my learning and development throughout GSoC.
I really enjoyed the process, and the feeling of owning a feature end-to-end is fantastic, even with the challenges. Over the past three months, I've learned a lot about feature testing, release testing, PM demos, and more.

You might also enjoy the "weekly journals" from some of our previous contributors: Rd4dev and @theMr17.

Getting started

Welcome! If you're interested in applying to work with Oppia for GSoC, please follow these steps:

Sign up to the oppia-gsoc-announce@ mailing list and the Developer Announcements category on GitHub Discussions, so that you can receive important notifications about Oppia's participation in GSoC. Make sure to set your preferences correctly so that you actually get the emails!
Get a better understanding of what Oppia is about:
- Read the user documentation to become familiar with important concepts like explorations and interactions.
- Play some lessons on Oppia.org, which hosts a live instance of Oppia.
To get started with development, read and follow the instructions in the contributors' guide carefully (Oppia Web, Oppia Android). If you're interested in Oppia Web, you might also find these tutorials helpful.
Do a few starter projects to become familiar with the contribution process. This will help us get an idea of what it's like to work with you. It will also help you get a better understanding of the codebase and our development process, which may help with writing a good project proposal. Once you've merged at least 2 pull requests, you will get an invitation to become a collaborator to the Oppia repository and be officially onboarded! This step is a prerequisite to applying for GSoC.

Note

You must be onboarded to the repository to which you will contribute during GSoC. For example, to work on an Oppia Web GSoC project, you need to be onboarded to the oppia/oppia repository, which means that your 2 pull requests need to be to oppia/oppia.

Tip

Quality is more important than quantity, so try to contribute to high-impact issues where possible. Also, we want to see examples of your best work, so please make sure to read the [["getting started" guide|Contributing-code-to-Oppia]] and [[PR instructions|Rules-for-making-PRs]] carefully, follow the tips for success, manually test your code before submitting (to ensure it does what you want it to and doesn't break anything else), ensure that your code conforms to the [[style rules|Coding-style-guide]], and pay attention to small details. These are good skills to learn when developing software in general, and they will also help you build credibility as a responsible developer who can be trusted to be a good steward of the Oppia codebase.

Select one or more GSoC project ideas that you're most interested in, and write your project proposal! You can get feedback from project mentors when you've completed a sufficient draft -- see the instructions in the GSoC proposal template section for details.

We require that all general discussion about GSoC projects take place in open channels. If you have questions about a project, you can ask in GitHub Web Discussions or GitHub Android Discussions. Note that individual projects have their own categories, so please use those if you have project-specific questions. Please also be specific when asking questions, since this makes it easier for us to help you.

Tip

During the application period, your first goal should be to figure out how to become an effective contributor. Start developing your project proposal only once you have experience getting some PRs merged. This will give you a much better idea of what you want to work on, and how much you can accomplish.

You might also want to ensure that you have the required skills for your chosen project. For guidance on how to do this, see the relevant section in the GSoC proposal template document and our FAQs.

Good luck!

FAQs

Q: What technical skills do I need to work on Oppia?

A: Please see the individual project ideas to determine which skills are recommended for the project in question. Also, in general:

For Oppia Web, Angular 2+, Python 3.9, Google App Engine and Apache Beam are useful and recommended, and experience with Docker and GitHub Actions is useful for developer workflow projects. Also, it is important to be able to write tests for the code you submit (using Karma, Webdriverio and unittest). You might also find this [[page of learning resources|Learning-Resources]] helpful, as well as other pages on our wiki that provide guidance on Apache Beam, testing frameworks, etc.
For Oppia Android, you will need to know how to program in Kotlin, and have experience with Android development. Knowledge of Bazel may also be helpful for some projects.
Note that, although GSoC is aimed at both students and beginner contributors to open source, "beginner to open source" is not the same as "beginner to coding" -- the projects do assume that you have some proficiency with coding. The fact that GSoC projects produce high-quality code that solves real problems for open-source projects does make GSoC challenging, but this is also part of what makes GSoC such a valuable experience for our contributors.

Q: How can I increase my chances of getting selected?

A: The most important thing is to ensure that you have the required skills for the project -- see the "Required Skills" section of the proposal template for more details. Aside from that, writing a good project proposal with a solid solution approach, engaging with the community, helping other contributors, successfully contributing PRs for high-priority issues, and demonstrating that you can work independently can all help you. We've also compiled some notes below on the selection criteria we'll be using this year.

Q: Which projects are most important for Oppia? Can you advise which project I should pick?

A: All the projects we've listed in the Ideas List are treated as equally important during selection, and we'd be very happy to see good progress made on any of them! Note that the relative importance of a project to Oppia is not part of the selection criteria. In general, we recommend that you pick a project based on whether you already have (or will be able to learn) the skills required for it, and that you'd enjoy doing over the summer!

Q: I do not have any experience in skill XYZ. What should I do?

A: If you are missing a skill that is needed for a project, we recommend trying to learn it -- in software development, it is common to develop experience and expertise as you take up and complete projects successfully. Some ways to do this include working on issues that give you a chance to develop that skill, referring to our wiki documentation, and following tutorials from elsewhere on the Web. Please note that, in general, we are unlikely to accept applicants who lack the required skills for a project, since this tends to result in significant difficulties during the coding phase.

Q: How will you assess whether I have the required skills for a project?

We will assess your application based on your proposal and the skills that you have demonstrated in your PRs and other interactions with the community. Please see the guidance in the "Required Skills" section of the proposal template, which explains how to demonstrate that you have the required skills for a project, and provides pointers on how to develop those skills.

Q: Is it okay if I only focus on the frontend or backend?

A: This probably depends on the project(s) you wish to apply for; check their "required skills" sections. However, note that most projects are full-stack and require ability in both the frontend and backend. We recommend becoming familiar with both of these, since this will open up more opportunities for you, as the projects we work on at Oppia often touch multiple layers of the stack.

Q: What is the minimum number of PRs that one should have?

A: You should have at least 2 merged PRs. Beyond that, remember that quality is more important than quantity, so consider taking some high-priority or "impact: high" issues if you're able to, since those fixes are more valuable. You can find a list of high-priority issues on the respective teams' project boards: LaCE, Dev Workflow, Contributor Dashboard, Android CLaM, Android Dev Workflow. Additionally, you'll also want to demonstrate that you have the required skills to successfully complete your chosen project; please see the guidance in the "Required Skills" section of the proposal template, which explains how to do this.

Q: Will I be penalized during selection if I ask for help while contributing?

A: Not at all! Asking for help when you need it is part of the learning process, and the Oppia open-source community is more than happy to help and onboard new members. Please just ensure that your questions are well-formed and that you (a) have read the relevant docs on the wiki, (b) provide the necessary information (such as a debugging doc) to help responders understand what you've figured out so far and where you are stuck.

Q: I only discovered Oppia recently. Does this mean that, during selection, my application would automatically be ranked lower than those by other applicants who have a longer tenure with Oppia?

A: Definitely not! Here are the selection criteria we use when selecting contributors for GSoC. Note that tenure with Oppia is explicitly not part of these criteria.

Q: How early should I start working on the proposal?

A: We recommend developing your project proposal and engaging with the community via GitHub Discussions as early as possible, so that you have enough time to get feedback from mentors and improve the proposal before the submission deadline. Make sure to follow all instructions in the proposal template (especially around sharing and access) to reduce delays in reviewing your proposal. That said, it's important to note that the proposal is only one part of the application process, and it is probably more important to figure out how to become an effective contributor by getting some PRs merged and demonstrating that you have the required skills for the project.

Q: Can I submit more than one proposal to Oppia?

A: Yes, you can. However, we strongly recommend picking one project and writing a solid proposal for it. Splitting attention across multiple projects might not be a great idea. (That said, GSoC is offering projects of multiple lengths, and if you're interested in doing either the 'full version' or the 'half version' of a project idea that can support both modes, you can submit both the 'full version' and the 'half version' as separate applications. Just make sure that you'd be happy with either outcome if you are selected!)

Q: If I only submit a proposal, without making any code contributions, will my application be considered?

A: No. See our selection criteria for more details.

Q: Can I use content from the project ideas list or PRD in my proposal?

A: It is fine for proposals to draw from the GSoC idea in the wiki and any linked PRDs. However, please note that if you copy content directly from any source (even if it is an Oppia doc), you must cite and link to the original source. Also, remember from our selection criteria that when we review proposals, one of the things we look for is evidence that the applicant understands the project and existing codebase well. Strong proposals will therefore contain details that are original (e.g. that are not copied from the PRD).

Q: I'm part of team X in Oppia. Can I submit a proposal for a project idea from a different team?

A: Yes, you can; there are no issues with that. There is a space in the proposal template to list teams at Oppia you've participated in, and we will get feedback from members of those teams about what their experience of collaborating with you has been like.

Q: What is the total number of contributors that will be accepted?

A: We generally request slots for as many projects as we think will succeed. However, the Google GSoC admins may impose limits based on how they decide to distribute contributor slots among the different open-source organizations.

Q: The Google GSoC FAQ mentions that the program is only for new contributors. I have already contributed to Oppia and I have write access. Can I still participate?

A: The GSoC program is open to students, as well as beginner contributors to open source. If you do not qualify as a student, see this FAQ on the GSoC website for whether you would be considered a beginner.

Q: Can you be flexible around my other summer commitments?

A: Probably not. We have not had good experiences offering flexibility in previous years, so this year, Oppia will strictly adhere to the Oppia GSoC timeline. Please refer to the Dates and Deadlines section below, and avoid taking up major commitments alongside GSoC. Experience from previous years suggests that you will be unlikely to successfully balance both.

Q: I'd love to contribute to open source, but I'm not sure I have enough time during the summer to do a GSoC project. Can I still help out?

A: Yes, GSoC is probably not the best choice if you don't have enough time during the summer, since it requires focused commitment. However, you can still start contributing to Oppia by following the instructions in the contributors' guide (Oppia Web, Oppia Android).

Dates and Deadlines

Noteworthy dates for 2025 (see also the Official GSoC Timeline):

Jan 27 - Feb 11: Mentoring organizations apply
Feb 27: Mentoring organizations are announced
Mar 1: GSoC Q&A session with Oppia
Mar 24 - Apr 8: GSoC contributor application period
May 8: Accepted GSoC contributors are announced
May 8 - June 1: Community bonding ("greenlight") period
- May 10 at 3 pm UTC: Briefing for accepted GSoC contributors (mandatory)
June 2 - Jul 18: Milestone 1 work period for GSoC
- Jul 4: Milestone 1 work due for internal evaluation
- Jul 5 - Jul 11: Testing of the milestone 1 work product
- Jul 12 - Jul 18: Buffer time for Milestone 1 revisions
- Jul 19 - Jul 25: Official GSoC midpoint evaluation
Jul 26 - Sept 12: Milestone 2 work period for GSoC
- Aug 27: Milestone 2 work due for internal evaluation
- Aug 28 - Sept 3: Testing of the milestone 2 work product
- Sept 4 - Sept 10: Buffer time for Phase 2 revisions
- Sept 15 - Sept 22: Official GSoC mentor evaluation due
Sep 23: GSoC period at Oppia officially ends

Note! For Oppia's participation in GSoC 2025, the coding period dates are strict, and we will not be offering extensions. Please ensure that you have sufficient time during the summer to work on your projects.

Types of work related to Oppia projects

The Oppia team is committed to making GSoC an enriching educational experience for contributors. In general, our goal for GSoC is for contributors to have a really meaningful experience, and to do something worthwhile over the summer that they can look back on with pride.

In order to ensure a well-rounded engineering experience, GSoC contributors will have the opportunity to do some or all of the following, depending on their project:

Write design documents for technical projects
Read and understand parts of the codebase related to their project
Receive code reviews for all code they write for their project
Develop user-focused, responsive and internationalized UIs.
Write automated tests for their projects
Meet regularly with other contributors on their Oppia development team (LaCE, Contributor Dashboard, Dev Workflow, Android)
Meet 1:1 with their mentors regularly to get developmental feedback
Give presentations and demos of their projects
Get personalized feedback on their project from the product team or a technical lead
Learn how to do code reviews

We've also asked our previous GSoC contributors what specific things they learned during their GSoC projects. Here are their collated answers:

Technical ability and domain knowledge
- Writing maintainable and readable code.
- Building an entirely new feature in a scalable way.
- Writing better automated tests.
- More confidence working with Angular.
- Making better design, UI and technical decisions.
- Getting a better understanding of overall full-stack development.
- Enhanced ability to debug and resolve technical issues.
Technical leadership skills
- How to manage my time well, and how to achieve deadlines.
- Improved skills in managing and executing projects.
- How to give, respond to and understand reviews.
- How to effectively convey ideas.
- How to write a good project proposal.
- Becoming a better developer, not only in terms of technical skills, but also in thinking of actual application of the built product and the edge case scenarios that the user might face.
Communication and personal development
- How to seek help when needed and overcome challenges.
- How to reach out to people, work with them, and help solve each other's problems.
- How to get myself unblocked.
- Putting forward my thoughts more systematically so that others can understand me well.
- Feeling more confident while joining online meetings.

Contributors have also told us why they continue to stay engaged with the project after GSoC ends:

Community
- It is really an awesome experience working with some amazing folks from all around the world at Oppia.
- The organisation is active and has a strong community bond.
- The kind of support the complete community provides is extraordinary.
Giving back
- The main reason to stay connected is the purpose the community serves. Providing education to those who do not have access to it helps me give back to the society.
- It makes me very happy that I'm part of an organization which provides free education and I think the education is the biggest blessing we can give to one to make them stand on their feet.
- I would love to be part of this org by knowing that maybe not much but yes I'm trying to make an impact and my contribution in the educational field. I really want to do this because where I come from there is not much of education.
Growth / learning:
- I like working in Oppia since it not only helps me improve my coding skills but also helps me grow as an individual.
- Working with Oppia has really helped me grow as a developer and I would really like to stick around to gain even more experience of real world software development.
- I feel my exponential growth while contributing in Oppia and got to learn many new things while getting help from mentors and other Oppia team members.
- The kind of work that Oppia does is really inspiring and there are a lot of opportunities to improve your skills be it be technical skills or leadership skills and most of all the people at Oppia are really fun to work with :)

GSoC Proposal Template

When submitting a proposal, please use the provided GSoC 2025 proposal template. We will only consider proposals submitted using this template. Note that there is a length limit: the proposal's technical "HOW" section should not exceed 20 pages at "Roboto 10" font size.

Note: There's no formal minimum length requirement for your proposal. The quality of what you write is much more important than the amount of text you write, and we encourage you to write shorter proposals that still convey the main aim of the project.

Important

The 2025 template differs from the 2024 template. Please make sure that you are using the 2025 one.

Some important notes:

Your proposal must be original (see section 2.4 of the Contributor Participation Agreement). During the selection process, proposals that are found to have passed off others' work as their own will automatically be disqualified. If you include any text in your proposal that is copied from the Internet or other sources (even if it is an Oppia doc), you must provide a link or reference back to the source. Note that you must attribute sources even if you paraphrase (i.e. re-write their content in your own words). In cases of doubt, we would encourage you to err on the side of citing your sources (since not doing so may be construed as plagiarism).
When the necessary criteria for requesting a review are met, add gsoc-2025-mentors@oppia.org as an editor for your proposal doc. (This makes some workflows, like inviting PMs or fixing typos, etc., easier, but if you're concerned about changes to your doc, then you can turn on notifications for edits.) After fixing the sharing settings, make a new post in the correct "proposal reviews" category in GitHub Discussions that is clearly titled with the name of the project that you are requesting a review for, and provide a link to the doc in your post.

Please use only the above channel for proposal reviews: all proposal-related communication should happen through GitHub Discussions or directly through comments in the proposal doc. Do not send proposals directly to individual GSoC mentors.

You can also request at most one "tech lead review" for at most one of your proposals during the pre-selection phase. To keep things fair, the tech lead will do only a single pass on your proposal and leave comments, but is not required to follow up on replies to those comments. Since you can only request a tech lead review once (per applicant), we recommend doing so after you have gotten feedback from mentors and completed a full draft of your proposal, but at least a week before the due date. Tech leads will process requests in the order they are received. To request a tech lead review, fill in this Google Form.
Your final proposal should be self-contained. In particular, to be fair to all applicants, key components of the proposal should not be editable after the deadline. Don't assume that reviewers will follow external links.

Tips for writing a good project plan

Here's some advice about proposals and milestone timeline planning that we collated from previous contributors and mentors:

Choose a project you're interested in! If you have a strong interest in your project, this might make it easier for you to pick up the necessary skills and tackle unforeseen difficulties that may arise during GSoC.
Familiarize yourself with the technologies for your project and the relevant part of the codebase. Reviewers will want to see that you understand how to integrate your project with the current Oppia structure — don't design in a vacuum.
Define milestones with enough detail to get a proper ETA. For example, don't just say "write e2e tests", otherwise you risk significantly underestimating the timeline.
Communicate and present your ideas clearly. Your proposal should show that you have a good understanding of the codebase and the final goal of the project. For example, in a user-facing proposal, don't just make a list of files that need to be changed; you should also show detailed mocks and user flow diagrams that demonstrate a clear understanding of the requirements.
Limit proposal length. A lengthy proposal is not necessarily better. In fact, adding large amounts of unnecessary detail can sometimes obscure the main points you are trying to get across.
Pick a project idea that is within your limits to tackle. Make sure that what you're proposing is within your capabilities.

What should applicants expect from mentors in a proposal review?

Please write your proposal on the assumption that you "own" your chosen project. From your perspective, the submitted proposal should be proofread and in as good a condition as possible before you ask for a review. Make sure that you have a sufficiently good understanding of the codebase/project so that you can find and fix flaws in the design; reviewers will give you feedback but not do this for you. Note that your proposal doesn't need to be flawless — we expect that you might make mistakes, and reviewers will be happy to guide you on how to improve. Instead, by "as good a condition as possible", we mean that your proposal should demonstrate:
- Your ownership of the project
- The research you have put into writing it
- Your analytical skills
- Your independence in making complex decisions
Make sure to present solutions and ask for feedback, rather than just asking for solutions. The proposal template contains a "key decisions" section which you can use to present the various options you came up with, analyze their advantages & disadvantages using a comparison table, and explain your proposed choice and the reasoning behind it. Note that this doesn't mean that you must always have multiple ideas to solve a problem, but you should instead always explain how you reached a solution, and why is it the best one from the end-user's perspective. Think about how you might gather data to validate your conclusions (e.g. by finding support in the peer-reviewed literature, or by showing your ideas to potential users in the target audience and asking for feedback, etc.).
Reviewers' suggestions are suggestions, not mandates. We do not expect you to always agree with your reviewers! This means that, as the proposal owner, you are always welcome to decide whether to accept/reject such suggestions. In either case, when accepting/rejecting a suggestion provided by a reviewer, try to explain your reasoning and the research that led to your decision.
If you're confused about something, try to identify the point of confusion and ask have specific discussions about it, rather than simply agreeing to whatever is proposed. Don't rely on an "appeal to authority" (e.g. "I am doing it this way because reviewer XXX said so") — the rational analysis and thought that underlie the decision are what's important, so make sure that you understand and clearly communicate the reasons behind the decisions you make.
Note that the process Oppia uses to select GSoC contributors typically includes multiple independent reviewers, most of whom will not have looked at the earlier versions of your submitted proposal. Your initial proposal reviewers may or may not be involved in the final selection process, and it is not a requirement that you need to implement all your reviewer's suggestions/requests in order to be selected. Instead, please consider your reviewer as a friendly advisor who is available to help you and provide guidance, rather than the main future evaluator of your proposal.

Selection Criteria

To select contributors for GSoC, we will evaluate candidates based on a set of criteria designed to ensure we select individuals who not only possess the necessary skills but also demonstrate the ability to contribute effectively to the project. The criteria are as follows, listed in order of significance::

Primary Criterion: Required Skills for the Project - This is the most critical factor in our selection process. A contributor must have the necessary skills for the project. Lack of these skills is a deal-breaker and can lead to immediate rejection of the proposal.
Secondary Criteria (of equal importance):
- Quality of the Submitted Proposal - This criterion helps us gauge the applicant's understanding of the project requirements. The proposal should align with project goals, and be clear, thorough, and feasible.
- Prior Experience Working with the Contributor - We consider our previous interactions with the contributor, focusing on their reliability, communication skills, independence, initiative, responsiveness, and willingness to assist others. This assessment allows us to predict how well the contributor will integrate with the Oppia developer community and contribute to the success of the project.

We believe that strong performance in these dimensions is likely to correlate well with the contributor having an enjoyable, fulfilling and productive experience over the summer, and successfully completing the GSoC program.

For the proposal, we generally look for a clear indication that the contributor has a good, clear understanding of the project, and has broken it down sufficiently well, in a way that makes it very likely to succeed. Some indicators that could help with this include:

Clear, unambiguous communication. (This is important; your proposal will be read by many mentors!)
A clear analysis of (and good design decisions that build on top of) the original project idea, with a strong focus on creating a simple, intuitive experience for end users.
A proposed solution approach which is sufficiently concrete and which demonstrates that the applicant has a good understanding of both the scope of the problem and the existing codebase.
A description, if applicable, of how the applicant plans to mitigate risks that could potentially derail the project.
A concrete, specific description of each milestone, together with a breakdown of the necessary work.

Communication

If you have questions pertaining to "how to get started with Oppia" or any other queries regarding GSoC at Oppia, please ask them on GitHub Discussions. Please be specific when asking questions; this makes it easier for us to help you. Also, please make sure to read the relevant "getting started" wiki page (Web, Android) first, since the answer to your question might already exist there!

To receive important announcements and updates about GSoC at Oppia, please subscribe to the Oppia GSoC Announce mailing list, and the Developer Announcements category on GitHub Discussions.

Oppia's Project Ideas List

Note: If you're coming to this section from an external link, please make sure to scroll up and read this entire wiki page carefully, not just this section. There's a lot of useful information on the rest of the page, including a FAQ and a section describing selection criteria. Thanks!

The following is a list of Oppia's 2025 GSoC project ideas. You are welcome to choose among these ideas, or propose your own! However, if you're planning to propose something original, it's essential to engage with the Oppia community beforehand in order to get feedback and guidance to improve the proposal. We'd also recommend taking a look at Oppia's mission and seeing if there is a natural way to tie your idea to the Oppia project's goals, otherwise it might not be a good fit at this time.

Please note that the list of project ideas below is not set in stone: more projects may be added later, and some project descriptions may also change a bit, so check back regularly. In addition, the mentor assignments listed below are provisional, and may change depending on which proposals are eventually accepted. (If you want to see what changes have been made to this page since you last viewed it, you can use the History tab.)

If you need clarification on any of these ideas, feel free to open a thread in GitHub Discussions following the process in this guide.

Learner and Creator Experience (LaCE) team

1.1. Clean up the structure for study guides and worked examples

Important

This is a popular project idea. Multiple applicants are interested in this project.

Project Description:

Oppia topics include a list of skills to teach. These skills are grouped into subtopics (like 'Basic Concepts of Division'), each with its own study guide (or 'subtopic page' in the backend). Currently, subtopic pages are implemented as a single large rich-text field, which makes them hard to translate and limits how we can display them. We'd like to split this rich-text field into multiple heading/content parts. In the above example, the updated subtopic page would have two sections ("What is division?" and "Parts of a division equation"), and the subtopic page editor would have a list of sections, each with its own "heading" plain-text field and "content" rich-text field.

Additionally, both skill explanations and subtopic pages should be able to include worked examples. Previously, worked examples were implemented as an explicit subfield of the SkillContents object that is contained in the Skill model. We would like to implement worked examples as a general rich-text component instead, since this allows them to be used in contexts beyond skills as well.

The aim of this project is therefore to clean up the incorrect modelling described above and make the necessary updates to the viewing and editing flows for subtopic pages, worked examples, and their associated translations/voiceovers.

Links to PRD and mocks:

Subtopic pages (study guides): Figma mocks and design thread
Worked examples: Figma mocks, design thread, and reference PRD. Note that some parts of the PRD are excluded -- see the "not in scope" section below.

Tracking issues: #18305, #19851

Not in scope:

Implementing new rich-text components other than "Worked Example".
Implementing the "Words to know!" and "Otter Tip!" sections in the revision card Figma mocks.
Enabling the use of worked examples in hints and feedback. (We will do this later once we have tried out the functionality in subtopic pages and skill descriptions.)
Implementing the more detailed validation described in the PRD (for limiting the number of worked examples to 2 if there are no images, or limiting them to 3 if there are images). For now, we will go with a general limit of 2.

Size: Large (~350 hours)

Difficulty: Moderate/Hard

Potential mentors: @kevintab95

Product/technical clarifiers: @seanlip (product), @kevintab95 (technical)

Discussion forum: https://github.com/oppia/oppia/discussions/categories/gsoc-q-a-1-lace-projects

Required knowledge/skills:

Figure out the root cause of an issue and communicate it well using a debugging doc.
Debug and fix CI failures/flakes.
Write Python code with unit tests.
Write TS + Angular code with unit tests.
Write or modify e2e/acceptance tests.
Write or modify Beam jobs, with tests.

Related issues:

RTE-related issues
Validation (backend + frontend)
Translation-related issues

Suggested Milestones:

Milestone 1: In SubtopicPageContents, carry out migrations to do the following:
- Convert the existing subtitled_html field into the new structure (a sections "repeated JsonProperty" field consisting of {heading: SubtitledUnicode, content: SubtitledHtml} dicts).
- Introduce a unique content ID for each translatable field, similar to explorations.
- Move the written translations and voiceovers for subtopic pages in EntityTranslationsModel and EntityVoiceoversModel, instead of within the SubtopicPage object (similar to explorations).
Update the subtopic page editor UI to accommodate the new structure, and the learner UI to match the Figma mocks. Then, deprecate the old subtitled_html field.
Milestone 2: Verify that the existing worked_examples fields are empty in production, then carry out a schema migration to safely deprecate the worked_examples field in the skill_contents part of the SkillModel, and remove it from the skill editor UI as well.

Implement a new 'Worked Example' RTE component that appears only in the skill explanation and subtopic page RTEs, and validate that skill explanations cannot have more than 2 such components. Add acceptance tests for the learner and creator flows to verify that they align with these mocks. Ensure that this component is translatable in the contributor dashboard, and update the translation guide to include it.

Org-admin/tech-lead commentary/advice

This is an interesting and high-impact project that “has a little bit of everything”, and that should give you a good understanding of the overall Oppia stack. There is very little in the way of completely new functionality here; almost all the parts of the project have some existing precedent in the codebase.

If you tackle it, it is important to have a good understanding of the systems involved. Make sure you are familiar with Beam jobs, since these will be important.

What we are looking for in proposals

Almost all parts of this project have some precedent in the existing codebase, and it is important to maintain consistency with the existing implementations. Thus, in your proposal, when describing your technical approach, please also point to the existing parts of the codebase that already use a similar approach.
Explain how the current structure for exploration translations works, and describe, by analogy, the ideal structure for skill and subtopic card translations. For the subtopic pages, what changes exactly will you make with regards to written translations and content IDs?
Explain in detail the steps you would take to carry out the structural migrations for subtopic pages and skills. For the former, what will the updated editor UI look like?
Explain how you would make the new 'worked examples' component appear only in the concept card and revision card RTEs.
Explain how you would structure the acceptance tests for both parts of the project, and the behaviours you would test.
What is the full list of places in the codebase which list functionality for the different RTE components, and which will need to be updated with details for the worked example component? Explain the approach you took to find these.

Technical hints / guidance

This project combines many concepts that already exist in the Oppia codebase, and understanding (and following) existing precedent is important. You will need to have a good understanding of the following in order to tackle this project:
- The relationship between the different models (topics, skills, subtopics, etc.)
- How to perform a (safe) schema migration (perhaps try doing a sample migration on your local machine). See this wiki page for details on how to write exploration state migrations; writing migrations for JSON properties in other entities follows a similar process.
- How to create an RTE component (perhaps try creating a test component on your local machine). See this wiki page for details on how to implement rich-text components.
- How to control which RTE components appear in which RTEs, and validate that the RTE content is valid (i.e. doesn’t include any invalid components)
- How translations work for existing entities, like explorations. (The original TDD for that project is here: Infrastructure for separate storage of translations, and you can examine the code related to the Contributor Dashboard for how the translation opportunities are generated and displayed.)
Note that "study guides" were previously known as "revision cards".
For subtopic page contents, be careful to ensure that each element in the list has its own unique content ID. Do not just base the content ID on the item's index in the list – if you have 3 elements in the list and then remove the middle one, the last element’s content ID should not change. This is why we need a counter to keep track of the "next content ID to assign" -- for example, you might consider introducing a next_section_id (similar to next_subtopic_id in the Topic object) to determine the correct ID to use when new sections are added.
To migrate the existing subtitled_html content, you can transform it into a single-element list with one item whose heading is the revision card's title, and whose body is the existing RTE content. The content_id and translation/voiceover migrations for SubtopicPages should be quite easy, because no translations/voiceovers exist for them yet. However, you will still need to figure out the new structure and fix the "plumbing".
For "ensure that this component is translatable in the contributor dashboard", you can temporarily enable it in exploration RTEs (e.g. in the hints RTE), and then test out the translation workflow. It's important to ensure that the new 'worked example' RTE component has behavioural parity with other RTE components in all places which refer to RTE components, even if it's not being used in the relevant contexts yet – for example, you should update the character-counting logic for hint/solution validation to handle worked-example RTE components as well, in case we decide to make this component available to explorations in the future. Note that @chris7716 is currently looking into a project that involves updating the translation structure for concept cards, topic descriptions, etc., and you might want to sync with him in order to ensure that your plan for introducing the necessary translation fields aligns with his work.

Suggested PM demo points

Milestone 1:
- Editor UI for revision cards is complete
- Learner UI is complete
Milestone 2:
- A worked example RTE component can be created, and used within a broader context (such as a study guide section or a skill explanation).

1.2. Fix the most common server errors

Project Description:

We currently see a number of unaddressed server errors on hosted instances of Oppia. Many server errors relate to user-facing bugs, and are a good clue that something is problematic in the application. Furthermore, frequently occurring errors result in the server logs getting noisy, to the point that they are no longer treated as alerts because the volume of errors is too high.

The aim of this project is to address the 15 most common server errors, and improve/clarify the logging infrastructure to make server errors easier to debug in general. This would also make it easier to catch new issues during test deployments, and reduce the overall error rate of the app. "Addressing a server error" entails the following:

Find a set of setup steps and actions that reliably reproduce the error on a local machine (see this tutorial). If more insight is needed, it is also fine to add some logging and do another deployment to get more information.
Identify the root cause of the error.
Confirm the expected behaviour with the product/tech leads, if needed.
Fix the error and add tests (which could be frontend, backend, or full-stack) to ensure that the error does not happen again. Some of the other steps listed in this wiki page might also be of interest. Note that some errors may be due to data issues, in which case a migration job or direct editing might be required, as well as stricter typing/validation to ensure that the issue doesn't reoccur.

Tracking issues:

#21807, #21841 and #21872 are quality-of-life improvements to help make server errors easier to debug.
See this link for a list of the most common server errors.

Note that the project will only cover a subset of the above, per the milestones described below. This will be the subject of a discussion between the contributor, mentor and org admins at the start of CBP.

Size: Medium (~175 hours)

Difficulty: Moderate

Potential mentors: @Nik-09

Product/technical clarifiers: @kevintab95 (product), @Nik-09 (technical)

Discussion forum: https://github.com/oppia/oppia/discussions/categories/gsoc-q-a-1-lace-projects

Required knowledge/skills:

Figure out the root cause of an issue and communicate it well using a debugging doc.
Write Python code with unit tests.
Write TS + Angular code with unit tests.
Write or modify e2e/acceptance tests.
Write or modify Beam jobs, with tests. (This is because you might need to write audit jobs for debugging certain errors.)
Figure out repro steps based on info from server logs.

Related issues:

Consider taking up issues like #21807, #21841 and/or #21872 to make errors easier to reproduce / debug.

You might also want to try some issues from this list to see whether this project is a good fit. In any issues you attempt, try to demonstrate your ability to (a) reproduce server errors deterministically, (b) write a debugging doc to narrow down the source of an error if you can’t pinpoint it in one go, (c) find the clear root cause of an error, and (d) prevent the error from happening in the future.

If you like, you can also suggest other improvements to the logging infrastructure that would make it easier to fix "server error" issues. (It is fine to file issues for these improvements and get assigned to them in the usual way. However, you should have tried to tackle at least one server error with a debugging doc, and the improvements you suggest should help address the problems you ran into while trying to figure out what caused the error.)

Suggested Milestones:

Milestone 1: Fix the 7 most common server errors, and improve the logging for server errors as needed.
Milestone 2: Fix the 8 next-most common server errors.

Org-admin/tech-lead commentary/advice

This project requires very good debugging skills. You will be exposed to a mix of server errors, some of which are very easy to solve, and others which will require a lot more investigation. Along the way, look for improvements to the infrastructure that would make the debugging process easier (ideally to the point that server errors can be tackled as easily as regular issues).

Laying out your work in a debugging doc is a very important skill for this project, since you will sometimes need to get help and it is important to provide responders with the context needed to do so.

What we are looking for in proposals

For the proposal, we recommend that you focus on identifying around 15 issues tagged as “server errors”, correctly outline their root cause, and propose a fix. These should include most of the ones from the list in the project description, as well as additional ones of your choice. You may also link to reproduction instructions (with video proof) and public debugging docs that you have already added to the corresponding issue threads.

Also, please note that, for this project, the proposal itself is a bit less important. The ability to solve some actual server errors is better evidence that the project will be a good fit. If you need to clarify the expected behaviour for an issue, feel free to start discussions in individual issue threads and in the project proposal.

Technical hints / guidance

All applicants for this project should read this tutorial on how to fix server errors. Note that, for this project, reading and understanding what the code is doing is very important, and so is writing debugging docs to explain what you know. The code fix is often simple, but the analysis to figure out which fix to make can be harder.

When attempting to fix a server error, first find a set of deterministic reproduction steps and add that to the issue. You will need to do this before you can be assigned that issue to fix. (Doing this investigation might result in linking the server error to a different existing issue that is already filed on GitHub, so general experience with bug-fixing is good to have as well.)

Note that @kevintab95 and @lkbhitesh07 have access to the server logs. Please correspond with Kevin Thomas and the server admins team if you want to run debugging jobs on the server.

Suggested PM demo points

Milestone 1: Demonstrate fixes for any server errors with a user-facing behaviour component.
Milestone 2: Demonstrate fixes for server errors with a user-facing behaviour component.

1.3. Lesson player redesign

Project Description:

The aim of this project is to redesign Oppia's existing lesson player according to these mocks. The goals of the redesign are to make the lesson player intuitive to navigate, easy to add features to in the future, and more engaging for younger audiences. The new lesson player should work well on mobile, desktop and tablet devices, as well as in RTL and LTR languages. (Note that some parts of the mocks are out of scope -- see the "Not in scope" section below.)

The new functionality should be developed behind the /lesson URL (which should, for now, redirect to the same backend handlers as /explore), and be gated behind a feature flag. Once the lesson player is ready to launch, all /explore URLs should be redirected to /lesson instead, and the new lesson player should be used for all lessons.

Relevant links: Mini-PRD and mocks

Tracking issues: #19217

Not in scope:

Implementing the speed adjuster in the voiceover toolbar
Implementing the "Get Help" control in the sidebar and the tutorials within it

Size: Large (~350 hours)

Difficulty: Hard

Potential mentors: @amyyeung17

Product/technical clarifiers: @seanlip (product), @amyyeung17 (technical)

Discussion forum: https://github.com/oppia/oppia/discussions/categories/gsoc-q-a-1-lace-projects

Required knowledge/skills:

Figure out the root cause of an issue and communicate it well using a debugging doc.
Debug and fix CI failures/flakes.
Write Python code with unit tests.
Write TS + Angular code with unit tests.
Write or modify e2e/acceptance tests.

Related issues:

Any non-backlog issues in the "Lesson Player CUJs" section of the LaCE project board (try to choose ones that relate specifically to the exploration player interface). Also, see the guidance in the last part of the "What we're looking for in proposals" section below.

Suggested Milestones:

Milestone 1: Move all non-UI-specific logic in the exploration player page to services, so that they can be used in both the existing and new exploration players. Then, build the following parts of the new exploration player page at the /lesson URL:
- The overall layout (sub-navbar, main player area, sidebar, footer, audio bar). Only the back-and-forth navigation and "Continue" buttons in the footer need to work at this stage; the rest can be implemented in Milestone 2.
- The main "conversation flow" UI (including all interactions).
- The "correct answer" pop-up and confetti.
By the end of this milestone, it should be possible to play any Oppia exploration via the /lesson/{{exploration_id}} URL (if the feature flag is turned on), submit and view wrong answers, and navigate back-and-forth through the lesson. Also, the exploration editor preview tab, practice questions page and diagnostic test pages (which use components of the lesson player) should show the new UI if the flag is turned on, and the old UI if it is not. Finally, if the flag is turned on, the /explore URL should redirect to the corresponding /lesson page.
Milestone 2: Transfer the remaining UI components to the new layout, updating or adding new acceptance tests as needed to verify their behaviour:
- Hints, solutions and concept cards
- The voiceover audio player
- The share, feedback, report and "exit lesson" buttons
- The progress-saving and checkpoints flow
- The end-of-lesson next steps (rate lesson, go to new lesson, practice, etc.)
Flip the launch flag, and, once the new player is serving in production, remove the code for the old lesson player.

Org-admin/tech-lead commentary/advice

Note that, although this project primarily involves UI changes, it also requires quite a strong understanding of Angular and "layered architecture", so it might be harder than you think.

The most important part is the very first part, which involves refactoring the existing UI (in a way that doesn't make any changes to functionality) so that the “services” code is properly separated from "UI" code. To do this properly, you will need to have a strong understanding of how the different pieces of the UI connect together in the new implementation, and be able to write out that specification.

After the service code is properly isolated, the rest of the implementation should be fairly straightforward. However, there are a number of subparts and constraints to keep track of, so it will be important to plan the work in an organized way.

What we are looking for in proposals

For the proposal, we would like to see answers to the following questions:

Give a detailed explanation of how you would identify and split out the “service” parts of conversation-skin.component.ts.
Give a broad, high-level overview of how you would implement the UI, paying attention to how you would do this in a maintainable way. In particular:
- What is the final structure of the three subfolders in core/templates/pages/exploration-player-page?
- For each component in the new exploration player, specify its API fully, including the types and descriptions of each of the component’s inputs.
- For each component, is there a reusable component implemented elsewhere in the app that you can reuse? If so, describe which one, and how you would refactor it (if needed) to support the new "exploration player page" use case.
Specify the naming convention system you would use for the CSS. (It needs to be consistent and predictable.)
How will you use feature flags to ensure that the old lesson player page (at /explore) remains intact while the new player functionality is being developed, and that the exploration editor preview tab, practice questions page and diagnostic test pages “behave correctly”? (In your proposal, please also specify what you believe the correct behaviour to be.)
How will you connect the code for each of the interactions to the new exploration player? If you are making custom versions of each interaction for the new learner view, how will you ensure that the old code is used when the feature flag is turned off, and the new code is used when the feature flag is turned on?
How will you handle "supplemental interactions" (see the "Technical hints" section below)?
For each component you create, how will you ensure that it is accessible? What is the full list of CUJs that you will write acceptance tests for? (This should be covered in the "Testing Plan" section of your proposal.)

While developing your proposal, you might find parts of the mocks that you would like clarification on. Please ask these questions in GitHub Discussions or leave comments directly on the Figma mock. If your technical plan relies on the answers to these questions, link to them (where appropriate) in the proposal you submit.

In addition to the proposal, the following is optional, but would significantly enhance your application if it is done well:

Create 1-2 PRs that focus on a specific lesson player sub-component. For this sub-component, move the shared logic between the old and new implementations to the services/ folder, and implement the “new lesson player” version of that sub-component with Karma unit tests. Demonstrate that, with your PR, the old versions of the lesson player still work correctly (including in the exploration editor preview page, the practice questions page, and the diagnostic test page, where applicable).

Technical hints / guidance

Note that parts of the lesson player functionality are reused in the exploration editor preview tab, practice sessions, and diagnostic test. Care should be taken to ensure that the new functionality is properly gated and does not break these other interfaces. Your acceptance tests should cover these cases as well.
Here is some guidance on how to launch new features, which also goes into detail on how to use feature flags.
The most important part of this project to get right (and also the hardest) is the first part of Milestone 1. If this is done properly then the rest of the project will be a lot more straightforward. To do this, make sure that you have a clear understanding, in your new implementation, of the list of services, list of components, and which components use which services (and how they do so) – this should all be specified clearly in your proposal. Then you can look at the existing services/components (for the old implementation) and figure out what modifications are needed to bring them in line with your proposal, and establish the right boundaries between UI and "domain logic" code. Here is a suggested technical approach for this part of the project:
- Within core/templates/pages/exploration-player-page, move all non-UI-specific logic from component.ts files to service.ts files in the `services/`` folder, so that such logic can be reused in both the existing and new exploration player layouts. Organize that folder to have just 3 subdirectories: a current-player-components folder with the Angular components for the existing experience, a new-player-components folder with the Angular components for the new experience, and a services folder for the services that both experiences have in common. Add a README to the root of the exploration-player-page folder explaining the layout.
- At the end of this process:
  - There should be no duplication of code logic throughout any of the files in /exploration-player-page – each piece of functionality should be specified in exactly one location, with no copy-pasting.
  - The only dependencies between files in the three root subfolders should be from current-player-components to services, and from new-player-components to services. No other inter-subfolder dependencies are allowed.
  - No further adjustments should be needed to files in current-player-components/ for the rest of this project.
- After the code is organized, it is important to be really careful when modifying services, as doing so would impact both the new and old functionality.
When developing the new UI components:
- Keep CSS scoped to each of the new UI components. There is a lot of “global CSS” in the old exploration player, but we do not want to repeat that pattern.
- More generally, the old lesson player may not conform to best practices. You do not need to repeat those mistakes in the new implementation! If you are not sure whether an existing practice in the old lesson player UI code should be followed in the new UI implementation, feel free to ask about that on GitHub Discussions, and we can give you advice.
- Where relevant, it is fine to copy UI code from the old components (if that matches the "new lesson player experience"), since we will be deleting the entire folder of old components at the end of the project.
- Ensure that the new UI works for both mobile/desktop and also for RTL/LTR languages as you go. Don't wait until the end of the project/milestone to handle this.
Note that the new exploration player will also need to handle "supplemental" interactions (like image click, music notes, etc.), where the interaction is a "canvas" that the learner enters answers in, and that doesn’t reset when Oppia gives feedback. Mocks do not exist for this case, but you can use the approach taken in the existing lesson player (e.g., for desktop view, show the "canvas" on the right of the screen and the conversation on the left side).

Suggested PM demo points

Milestone 1:
- The overall structural layout for the exploration player is in place on both desktop and mobile.
- A simple Oppia exploration (with just Continue, Multiple Choice and NumericInput) is playable in the new lesson UI.
- An Oppia exploration with all interactions is playable in the new lesson UI.
Milestone 2:
- All the controls in both sub-navbars and the sidebar are fully functional.
- All the controls in the footer are fully functional.

Contributor Dashboard team

2.1. Show AI-powered translation suggestions to translation submitters

Project Description:

This project involves showing auto-generated suggestions in the Contributor Dashboard translation submission modal, so that translation submitters can edit and submit those translations, rather than needing to generate completely new ones from scratch each time. These suggestions would arise from autogenerated translations from an AI-powered translation service.

The project involves implementing a system for updating EntityTranslationsModel to associate each (content_id, language) pair with both a "manual" and "auto" translation (similar to VoiceoverType in feconf.py for voiceovers). The manual translation should only be populated once a translation is approved by a human reviewer (possibly after edits); this translation is shown to the learner when playing lessons. On the other hand, automatic translations will only be shown as suggestions to translation submitters via the contributor dashboard. To understand the effectiveness of the AI suggestions, the contributor admin dashboard will also display information about how many times the AI suggestions were used as-is, without any edits.

There should also be a button on the Admin page that can bulk-generate auto-translations via a Beam job. This job should be run to populate the initial auto-translations once the pipeline is ready. Subsequently, any additions/edits to a curated entity (lesson, topic, skill, etc.) should trigger an auto-translation of the added/edited content, and publishing a curated entity should trigger an auto-translation of all strings in the entity. In other words, the auto-translations should always be up-to-date with the English strings in the current version of the entity.

Link to PRD: Language Management and Lesson Auto-Translation PRD (a bit out of date)

Tracking issues: #16164 (part), #19681

Not in scope:

Configuring the list of prioritized languages for translation
Auto-generation of voiceovers (in any language)
Enabling translations for concept cards, review cards, or practice questions
Showing auto-generated translations in the learner view (see oppia/oppia#16164 for more information).

Size: Large (~350 hours)

Difficulty: Hard

Potential mentors: @chris7716

Product/technical clarifiers: @seanlip (product), @chris7716 (technical)

Discussion forum: https://github.com/oppia/oppia/discussions/categories/gsoc-q-a-2-contributor-dashboard-projects

Required knowledge/skills:

Figure out the root cause of an issue and communicate it well using a debugging doc.
Debug and fix CI failures/flakes.
Write Python code with unit tests.
Write TS + Angular code with unit tests.
Write or modify e2e/acceptance tests.
Write or modify Beam jobs, with tests.

Related issues:

Issues related to translation submitters are good ones to tackle: https://github.com/orgs/oppia/projects/18/views/4?sliceBy%5Bvalue%5D=Translation+submitters

Suggested Milestones:

Milestone 1: The computer-aided translation (CAT) backend is completed, and can process any rich-text field properly (including components like images, skill links, etc.), including validating that the autotranslated string has the same number and type of rich-text components as the original string. Storage models are updated to store these autogenerated translations, and the relevant statistics models and regeneration jobs are also updated to include the number of times a translation suggestion exactly matches the auto-translation. The wiki pages are also updated to explain how to add new languages and translation providers to the system.

At the end of the milestone, admins should be able to configure the CAT service provider for each language, and run a job to generate auto-translations for any untranslated texts for curated lessons. (They can select 'all entities', 'all entities of a specific type', or a specific entity; and they can select 'all prioritized languages' or a particular language.)
Milestone 2: When a curated entity (lesson, topic, skill, etc.) is edited, this should trigger an auto-translation of the added/edited content. When a curated entity is published, this should trigger a full auto-translation of all strings that don't have auto-translations yet. These auto-generated translations are then shown to contributors in the contributor dashboard UI, together with an annotation explaining their origin.

Org-admin/tech-lead commentary/advice

This is a difficult project that involves building and completing a pipeline that can greatly reduce the effort needed to internationalize lessons. The main things to be prepared for are Beam jobs and working with an external translation service.

When planning your milestones, try and do the Beam testing as early as possible so that you have enough time to debug any issues that arise. For the translation service, it is essential to have a quick way to test it, because you will likely need to fine-tune how you send the strings to the service. Getting that set up can involve some registration/activation steps, so it's worth getting familiar with the pipeline to ensure that you will have a good development environment to iterate in.

What we are looking for in proposals

Please explain the following clearly in your proposal:

Details of all the Beam jobs you plan to write for this project.
What is your plan for translating each of the rich-text component types, and how will you handle this when sending the string to the third-party system for translation? How will you validate that the correct number and type of rich-text fields are preserved between the original and the translated content?
How will you structure the system so that different service providers can be specified for different languages, with each service provider having a ‘services.py’ file in core/platform/translate? (For this project, it is fine to include the implementation for only one provider, but the framework should be extensible and there should be clear instructions in the wiki for contributors on how to add a new provider.)
What are the different tasks that need to be completed for this project, and in what order should they be done?
What transformations need to be done to the content before it is sent to the cloud translation service, and what transformations need to be done to the received translation before it is saved in the datastore (so that it can be presented directly to translation submitters, without further edits)?
What is your plan for setting up a quick-debugging loop that helps you fine-tune what you send to the cloud translation service? (It would be a good idea to try and get a proof-of-concept set up on your machine that shows you are able to do effective testing with a cloud translation service while developing locally.)
What is the updated schema for the storage models, and (if necessary) how will you handle the migration of the existing models to the new structure?
What updates you will make to the Contributor Admin dashboard files, and what modifications you will make to the Beam backfill statistics-regeneration jobs, to add a new statistic for submitted translations which match the AI ones.

Technical hints / guidance

Much of the computer-aided translation (CAT) backend work has already been done (see this doc for details). You might like to look at previous unfinished PRs: #12604 / #14418. However, please bear in mind that the translations system has evolved significantly since those PRs were created.
You will need to gate the new functionality behind a SHOW_TRANSLATION_SUGGESTIONS_IN_CD feature flag that gates the integration of translation suggestions to the contributor dashboard. We will only turn on this feature flag once the feature testing process has been completed.
This design issue tracks the progress of the mocks for showing translation suggestions on the contributor dashboard, and you can follow it for updates. That said, for your proposal, please focus more on the technical aspects than the mocks – in general, anything that contributor dashboard submitters can reasonably understand and make use of is fine.
The technical approach we are taking involves pre-generating the auto-translations, to reduce latency at the time of translating. There should therefore be no need to generate auto-translations “in the moment” while a volunteer is submitting a translation via the contributor dashboard. If, for some reason, a stored auto-translation is not available for a piece of content, it is fine to just not show that part of the submission modal. (Don’t error noisily in a way that blocks the experience for the translation submitter.)
The list of languages for which to auto-generate translations can be derived from the information stored in VoiceoverAutogenerationPolicyModel, which contains language codes as keys. This list is currently shown on the /voiceover-admin page.
If you need to migrate JSON properties, following the approach used for migrating the states in the Exploration domain object might help (i.e. introduce a schema version field and use that to perform the migration safely).
To enable the (new version of the) Contributor Admin dashboard, go to /release-coordinator and turn the cd_admin_dashboard_new_ui flag on.
Here is a suggested technical sketch for the statistics model changes:
- Add a new exactly_matches_ai_suggestion boolean field, which defaults to False, to the GeneralSuggestionModel. This is used to increment new submitted_ai_translations_exact_match_count fields in TranslationContributionStatsModel and TranslationSubmitterTotalContributionStatsModel when a contributor’s translation suggestion is exactly the same as the auto-AI suggestion stored in EntityTranslationsModel.
- Display the new count from TranslationSubmitterTotalContributionStatsModel in the relevant table of the Contributor Admin dashboard. (You don't need to display the corresponding count from TranslationContributionStatsModel in the contributor's "Contribution Stats" dashboard -- the reason we're storing it there is to make it easy to backfill the TranslationSubmitterTotalContributionStatsModel from it if needed, similar to how its other attributes are backfilled.)
- Update any Beam backfill jobs that regenerate these statistics, as needed. (Note that TranslationContributionStatsModel would need to be backfilled based on the suggestions and entity translations.)

Suggested PM demo points

Milestone 1:
- Translation autogeneration works properly for rich-text content with different components (skill links, images, etc.).
- A Beam job allows generation of all autotranslations.
Milestone 2:
- Autogenerated translation suggestions are shown in the contributor dashboard UI.

Developer Workflow Team

3.1. Acceptance tests

Important

This is a popular project idea. Multiple applicants are interested in this project.

Project Description:

In order to streamline releases, we are planning to ensure that all critical user journeys (CUJs) on the Oppia web application are covered by acceptance tests. This is important because it will provide assurance that, on the merge of every PR, these critical user journeys still function correctly, which means that no major breakages will result if the develop branch gets deployed to production. Additionally, having a complete set of acceptance tests that are organized by CUJ makes it easier to audit whether or not a particular CUJ has been included, and it also helps developers add tests for new CUJs while still keeping the tests well-organized.

This project includes:

Writing acceptance tests for the as-yet-uncovered CUJs in a way that keeps the tests organized and maintainable. This might also include small updates to the acceptance test framework, e.g. extracting utility functions to enable code reuse or providing relevant functionality for a group of tests.
Tightening all page utility functions to have pre/post checks (in the form of "wait" statements) and proper error messaging, so that it is easier to debug flakes. The pre-check wait ensures that the conditions are good for performing the action, and the post-check wait ensures that the action has fully completed.
Deleting e2e tests whose functionality has been fully replaced by the acceptance tests.

Relevant documents:

Current CUJ tracker: Critical User Journeys v2
Spreadsheet that details most of the tests that need to be written: Web QA Test Matrix (arranged by user type)

Tracking issues: #21646

Not in scope:

Configuring the list of prioritized languages for translation
Auto-generation of voiceovers (in any language)
Enabling translations for concept cards, review cards, or practice questions
Showing auto-generated translations in the learner view (see oppia/oppia#16164 for more information).

Size: Large (~350 hours)

Difficulty: Easy / Moderate

Potential mentors: @imchristie

Product/technical clarifiers: @seanlip (product), @imchristie (technical)

Discussion forum: https://github.com/oppia/oppia/discussions/categories/gsoc-q-a-3-dev-workflow-projects

Required knowledge/skills:

Figure out the root cause of an issue and communicate it well using a debugging doc.
Debug and fix CI failures/flakes.
Write TS + Angular code with unit tests.
Write or modify e2e/acceptance tests.

Suggested Milestones:

Milestone 1: Tighten all existing page utility functions in core/tests/puppeteer-acceptance-tests to have appropriate pre/post checks. Complete all acceptance tests for exploration creators, logged-out users, and logged-in users (as specified in #21646), and ensure that they run on all PRs by adding them to the "acceptance test" GitHub workflow. Remove any existing webdriverio tests whose functionality is fully covered by the new acceptance tests.
Milestone 2: Complete all other remaining acceptance tests (as specified in #21646), and ensure that they run on all PRs by adding them to the "acceptance test" GitHub workflow. Remove any existing webdriverio tests whose functionality is fully covered by the new acceptance tests. If any webdriverio tests remain after this step, translate them into CUJs and work with the QA team to make them part of the CUJ document, then implement the corresponding acceptance tests. Finally, remove the old webdriverio and e2e test framework completely.

Org-admin/tech-lead commentary/advice

This is a relatively straightforward project, since a lot of the infrastructure has been written and there are lots of examples that you can follow. The most important thing is to set up a good development cycle so that you can debug issues with tests quickly.

It is important that you are able to get the tests running on your machine, so that you can pause them when needed and investigate to see what is going wrong.

What we are looking for in proposals

For this particular GSoC project, the proposal is less important and we are more interested in your previous PRs. In particular, each of the following can significantly enhance your application:

Tackling at least one PR that solves a part of #21646.
Showing at least one debugging doc that correctly diagnoses the root cause of an e2e/acceptance flake.
Making at least one PR that resolves at least one E2E/acceptance flakiness issue (many of these are collected here).

Some things you could address in your proposal:

How will you break down this project into individual sub-milestones? Provide a clear timeline for this.
How will you set up your debugging cycle so that you can easily figure out what is going wrong with a test, or fix a flake in it? Explain this for both (a) local development, and (b) getting a test to pass in the CI environment.
Do an audit of which page-level functions are missing pre- or post-checks. List these in your proposal. You might also consider making a PR to fix them for at least one of those files, to demonstrate that you know how to add the checks correctly and to get feedback from reviewers.
For each existing webdriverio test file, specify the set of CUJs which need to be covered by acceptance tests in order for it to be removed. (If you identify gaps in the spreadsheet CUJs during this audit, feel free to suggest additions/updates to those.)
Suggest any improvements that you would make to how the tests are currently organized. How would you make it easy for the QA team to verify whether a particular CUJ is covered by acceptance tests? Also, how would you make it easy for developers to figure out which CUJ they need to update (or if they need to add a completely new one)?
Suggest any missing CUJs that you would add. You can cross-reference the testing spreadsheet with the CUJ document that is currently used for release testing, or identify those journeys yourself through direct experimentation with the test server or your local dev setup. Focus only on critical user journeys -- you do not need to go into detail for all the edge cases. When suggesting missing CUJs, include test specs for the corresponding user journeys (there is a format for this in the GSoC proposal template).

Technical hints / guidance

Start by writing tests for just one CUJ to make sure you can do it properly. If you are able to do that well, then there is a good chance that you will be successful with this project.
For this project, user journeys are detailed in a shared sheet, divided into distinct tabs. During the implementation phase, applicants should tackle each user journey in a structured way, leveraging lessons and code from earlier phases to inform later work. This will help streamline implementation and ensure efficient reuse of developed solutions.
You might want to join the Release Testing team to help out with testing releases and becoming familiar with the application. The QA team, who coordinates the release testing team, can also advise on CUJs and provide detail on them if any are unclear. Feel free to reach out to them if you have questions.
The acceptance tests ultimately need to pass in the CI environment, which is different from the local environment. How will you set up your debugging workflow so that you can test things on CI quickly? (One approach might be to temporarily comment out the other tests/workflows so that, when you make a push, only the acceptance test you are interested in runs. You might want to try this out for yourself and elaborate on what you did in your proposal.)
The QA team owns the CUJ document. If you need to clarify CUJs, feel free to work directly with them on this.

Suggested PM demo points

Milestone 1: Acceptance tests for the exploration creator user journeys have been written.
Milestone 2: Acceptance tests for the contributor dashboard user journeys have been written.

3.2. Consolidate entity migration jobs

Project Description:

The Oppia codebase includes several different versioned entities which store learning material: explorations, skills, stories, subtopic pages, questions, topics, and collections. The infrastructure to maintain each of these versioned entities has been developed separately, and is a bit patchy (for example, migrations of old snapshots have not been implemented for some of the entities). This is making it difficult to remove some of the old version upgrade functions in the codebase which are no longer needed.

The aim of this project is to standardize these migration jobs so that there is a single, standard way to migrate and upgrade versioned models. This will (a) ensure that all the versioned models can be easily updated on a periodic basis, (b) let us delete the code for upgrading from old versions once all the entities of that version have been upgraded, and (c) simplify the remaining version upgrade code.

Tracking issues: #22023

Size: Medium (~175 hours)

Difficulty: Moderate

Potential mentors: @U8NWXD

Product/technical clarifiers: @seanlip (product), @U8NWXD (technical)

Discussion forum: https://github.com/oppia/oppia/discussions/categories/gsoc-q-a-3-dev-workflow-projects

Required knowledge/skills:

Figure out the root cause of an issue and communicate it well using a debugging doc.
Write Python code with unit tests.
Write or modify Beam jobs, with tests.

Additionally, strong technical design skills and a good sense of code architecture are helpful.

Related issues:

#16556 is a good issue to look into, since it will help you become familiar with the migration job infrastructure.
Issues related to Beam jobs are also good ones to look at.

Suggested Milestones:

Milestone 1: Create a BaseVersionedDomainObject which specifies object member mappings to storage model properties in a declarative way, and also specifies the "schema version field" corresponding to each JsonProperty-related field. Add tests to ensure that all JsonProperties are accounted for. Then, replace all existing domain objects for versioned models with subclasses of BaseVersionedDomainObject. Additionally, ensure that all functions that convert storage models to domain objects also migrate domain objects to the latest schema version.
Milestone 2: Create BaseMigrateVersionedModelJob and BaseMigrateVersionedModelSnapshotsJob classes with the core logic for upgrading models and snapshots to the latest schema versions, respectively. Use these to build both job and audit job subclasses for all versioned models (explorations, skills, stories, subtopic pages, questions, topics, collections) with proper logging and error reporting (e.g. if a migration fails, the model that could not be migrated should be logged for debugging). Test these jobs on production data to ensure that they work correctly, and fix any issues that arise. Finally, run all the jobs in all our production environments, so that all the models and snapshots on the server are upgraded to the latest schema versions, then remove the old jobs and the old conversion functions for all 7 versioned models, as well as the methods they call (similar to what was done in https://github.com/oppia/oppia/pull/12256/files).

Org-admin/tech-lead commentary/advice

This project requires a very good understanding of how our migration pipeline works, and a solid grasp of technical architecture so that you can make good design decisions for how the base classes and their subclasses are structured. However, once that is well-understood, it should not be too difficult to implement. You will probably find deleting all the old code at the end quite satisfying!

What we are looking for in proposals

In addition to your implementation approach, please also:

Analyze the jobs for the existing entities to understand and catalogue their differences. Then, for each of those differences, make a proposal for how you plan to standardize it, and explain the implementation of each of the resulting base job and audit job classes for migrating entities and entity snapshots.
Describe what error reporting or logging you would add to the Beam job to make it easy for you or server admins to detect/debug issues when it is run.
Describe how you would name the new jobs. Try to use a standard naming convention that is easily extended to versioned models that are introduced in the future.
For each entity type, list the functions/constants that you plan to delete (in addition to the conversion methods) after you have confirmed that all models are using the latest schema versions. Describe how you determined that this is the complete list of orphaned functions/constants.
Provide a full example of how you would set up the BaseVersionedDomainObject with declarative definitions for at least one of the existing versioned models. Clarify what goes into the base domain object and what goes into the subclasses.
List the validation checks that the versioned domain object classes must satisfy, and describe how your backend tests will automatically pick up all the versioned domain object classes in the codebase when new ones are added.

Technical hints / guidance

There are existing jobs and audit jobs in the codebase for migrating models and snapshots (e.g. MigrateExplorationJob, ExpSnapshotsMigrationAuditJob, etc.). All these should be deleted at the end of the project. This old wiki page with instructions for writing schema migrations might also provide some useful background: https://github.com/oppia/oppia/wiki/Writing-state-migrations
The bulk of the logic for all the new jobs should be in the two base classes, BaseMigrateVersionedModelJob and BaseMigrateVersionedModelSnapshotsJob. In general, if some functionality is common to all versioned models, it should be included in the base class, otherwise it should be defined in the relevant subclass(es). Ideally, the subclasses would just point to the relevant storage models / domain object classes and not include any custom logic – see SNAPSHOT_METADATA_CLASS in ExplorationModel for an example of this. The corresponding audit jobs for these two jobs should be trivial subclasses of the main jobs with DATASTORE_UPDATES_ALLOWED = False. (Look at the usage of DATASTORE_UPDATES_ALLOWED in the codebase for more information.)
Part of this project includes standardizing the infrastructure for migrating JSON properties. Here is a more detailed technical sketch for how this could be done:
- Create a BaseVersionedDomainObject whose subclasses declaratively specify a mapping from any versioned field to its corresponding schema version field. (These fields correspond to JsonProperty in the datastore's storage model.) Un-versioned fields of type Dict or `List[Dict]`` should be explicitly declared as un-versioned. Subclasses must also reference constants in feconf.py that specify the minimum and maximum version of each field.
- Write backend tests that:
  - Identify all subclasses of BaseVersionedDomainObject in the codebase and verify that every Dict or `List[Dict]`` field contained in the object is either included in the mapping mentioned above or included in a list of un-versioned fields. This ensures that all versioned domain objects have the necessary infrastructure for performing schema upgrades for their respective JsonProperties.
  - Ensure that the relevant migration functions for each upgradable field are present in the corresponding domain object class with the function signatures (including type hints). Specifically, each conversion function should accept one parameter of the same type as the versioned field and should return one value of the same type. The migration functions can be named using a standard scheme, e.g. _convert_{{field_name}}_v{{x}}_dict_to_v{{x+1}}_dict, and the backend test can check for that. This test should also use the minimum and maximum schema versions to check that upgrade functions from the minimum up to the maximum version are present.
- Add a migrate_to_latest_schema_versions function to BaseVersionedDomainObject to handle schema upgrades in a generalized way across all domain objects.
- Ensure that all the different getter functions in the _services/fetchers.py files that convert storage models to domain objects also use migrate_to_latest_schema_versions to translate that object’s fields to use the latest schema versions.
- Replace all domain objects corresponding to VersionedModels with the new BaseVersionedDomainObject.

Here's a schematic depiction of a possible end state for versioned domain models:

class BaseVersionedDomainObject:
  - Class Variables:
     - schema_versioned_attributes = {}
  - Methods:
    - def migrate_to_latest_schema_versions():
      - Use the versioned_attributes map to find versioned fields. Then call update functions on each of those until the entire domain object is fully upgraded.

class Exploration(BaseVersionedDomainObject:
  - Class Variables:
    -  schema_versioned_attributes: {
        "states_dict": {
          "version_field": "states_schema_version",
          "version_min": feconf.MIN_STATE_SCHEMA_VERSION (e.g. 5),
          "version_max": feconf.CURRENT_STATE_SCHEMA_VERSION (e.g. 10)
        }
      }
  - Methods:
    - def _convert_states_v5_dict_to_v6_dict
    - ...
    - def _convert_states_v9_dict_to_v10_dict

Suggested PM demo points

Milestone 1: At least one domain object is using BaseVersionedDomainObject, and all the get/save functionality works correctly.
Milestone 2: All jobs run correctly on the backup server.

3.3. Standardize and validate domain objects and storage models

Project Description:

Oppia's production data is organized using NDB storage models, which in simple terms can be thought of as objects having different properties. For instance, data related to a user can be stored in a UserSettingsModel with properties like username, user ID, etc.

Different inter-model relationships exist as well, corresponding to relationships between prod data. For instance, a story includes a list of explorations. So, a StoryModel might include the IDs of all the ExplorationModels it is composed of.

For proper functioning of the Oppia application, it is important to ensure that all the models are internally consistent and that the relationships between models are valid. The aim of this project is therefore to ensure that all production data is valid by:

Ensuring that domain objects exist for all prod models, and that they have full validate() functions.
Implementing Beam jobs that audit production data and flag any errors. These jobs should validate the model properties as well as inter-model relationships. After these jobs are run, any errors should be investigated, and checks should be implemented to ensure that such problems don’t reoccur in the future with new data.

Tracking issues:

#21970
#21905
#21869

Not in scope: Migrating existing datastore data to address the validation issues found in the first milestone.

Size: Large (~350 hours)

Difficulty: Moderate

Potential mentors: @ankita240796

Product/technical clarifiers: @seanlip (product), @ankita240796 (technical)

Discussion forum: https://github.com/oppia/oppia/discussions/categories/gsoc-q-a-3-dev-workflow-projects

Required knowledge/skills:

Figure out the root cause of an issue and communicate it well using a debugging doc.
Write Python code with unit tests.
Write or modify Beam jobs, with tests.

Related issues:

oppia/oppia#21970
oppia/oppia#21905
oppia/oppia#21869
The first checkbox item from any of the following:

Suggested Milestones:

Milestone 1: Domain objects exist for all storage models, and include validate() methods that fully validate the domain object's internal consistency and correctness. The usage of storage models in the domain layer is restricted to the interfaces for getting and saving datastore models, and they are not passed further around the codebase. 50% of the validation jobs for the storage models are implemented and run successfully. For each validation error found, an issue is filed with clear action steps for (a) stopping the error from happening for new data, and (b) migrating old data to fix the error.
Milestone 2: All remaining validation jobs for the storage models are implemented and run successfully, and issues are filed for all validation errors as described in Milestone 1. All root causes of the validation issues found in Milestones 1 and 2 are identified and fixed, so that the error no longer happens for new data. (This corresponds to part (a) of each issue in Milestone 1.)

Org-admin/tech-lead commentary/advice

This project is relatively straightforward if you can identify the validation checks correctly and are able to analyze the codebase to figure out why incorrect data is being written. The design brief provided in the technical hints should help provide a lot of the necessary structure. Note that the validation requirements for the different models can vary greatly in terms of difficulty.

What we are looking for in proposals

For your proposal, please include the following:

A complete list of all storage models, with “validity” clearly defined for (a) the corresponding domain objects, (b) the models themselves (including inter-model relationships).
How you would structure the sub-milestones to enable you to run jobs efficiently on the server in batches.
A worked example of how you would do each part of the project (domain-object creation, only using storage models in get/put, writing a validation job, filing the GitHub issue, fixing the root cause). You can link to sample PRs if you like. For the purposes of this illustration, we suggest that you pick one or two "average" or "hard" examples – try not to pick a trivial model.
Any complicated cases you identify for any of the above steps, and an explanation of how you would tackle them. (For example, customization arg validation for interactions.)
An explanation of how you would ensure/verify that storage models are not used beyond the get and save functions in the *_services.py file. (For example, you might come up with a standard pattern for get/save that you can implement universally to make that verification easy to do, or you might analyze import statements that involve to the storage layer, or you might add a backend test to ensure that ndb.Model instances are not passed beyond specific functions.)

We also recommend taking up at least one checkbox item from each of the following, in order to confirm that this project is a good fit for you:

oppia/oppia#21970
oppia/oppia#21869
The first checkbox from any of the following (to demonstrate ability to “identify the root cause of an error and stop it from happening”):

Technical hints / guidance

Please go through the following guides in the Oppia wiki:
- Storage models
- Testing jobs and other features on production
- Debugging datastore locally
- Apache Beam Jobs · oppia/oppia Wiki · GitHub
  - Note that, in general, any Beam jobs you write should be idempotent, i.e., running them twice should result in the same outcome as running them once. This allows us to just rerun them if a job fails for some reason (e.g. due to an internal Beam error).
See this design brief for a design approach that you can follow for the validation jobs.
To understand how validation jobs work, you might like to take a look at the existing audit and validation jobs. Some examples:
- https://github.com/oppia/oppia/blob/develop/core/jobs/batch_jobs/user_validation_jobs.py
- https://github.com/oppia/oppia/blob/develop/core/jobs/batch_jobs/blog_validation_jobs.py

Suggested PM demo points

Milestone 1: Validation jobs for at least 5 prod models are written & run, and errors arising from those jobs have been filed as issues on GitHub.
Milestone 2: A full list of errors is compiled with clear action items.

Android team

4.1. Flashbacks

Project Description:

When learners make a mistake on a concept they have previously demonstrated in an earlier part of a lesson, it often makes sense to redirect them back to an earlier card to try and reinforce earlier concepts that the learner may have not fully understood. However, in the current app implementation, learners subsequently need to re-answer all the cards between the earlier state and the state they had reached, which is frustrating.

This project aims to provide a new feature called 'flashbacks' which helps to bring the benefits of earlier redirection (i.e. reviewing an earlier concept that directly ties to the learner's likely misconception) without the frustrating experience of having to redo the all the questions up to returning back to the question that originally caused the learner to become stuck.

Additionally, this project also includes improving the general look-and-feel of submitted answers for both multiple choice and item selection interactions as these both currently rely on HTML generation rather than having a cleaner, natively rendered experience. This change will also allow them to be displayed properly in the 'flashback' experience.

Relevant links: Tracking issue with mocks links (oppia/design-team#179) and PRD (incomplete). Please note the following regarding these mocks:

The mocks don't include explicit changes for multiple choice and item selection.
The mocks don't quite represent the correct 'inline' experience that needs to be introduced for the 'Learn Again' button (which should be part of the answer & response section of the incorrect answer that is prompting for a revisit).
Only the mocks with the orange toolbars are actually correct and need to be implemented (except for the otter, and the return button should be part of the flow rather than overlaid).

Tracking issues: #5732

Size: Medium (~175 hours)

Difficulty: Moderate

Potential mentors: @adhiamboperes

Product/technical clarifiers: @seanlip (product), @BenHenning (technical)

Discussion forum: https://github.com/oppia/oppia-android/discussions/categories/gsoc-q-a-4-android-projects

Required knowledge/skills:

Figure out the root cause of an issue and communicate it well using a debugging doc.
Build the app and install it on a local device or emulator. Then verify that you can (a) build a non-test library target locally, (b) run a unit test locally, and (c) play through the app locally.
Write new Kotlin code with unit tests.
Change Android UIs, write tests for them, and manually verify that they work.

Related issues:

Key issue: #5572. This tracks introducing a short-term solution of the broader problem this GSoC project aims to solve.

Issues related to portions of the codebase that will be affected by this project:

#5728
#5568
#3646
#2973
#1273

Suggested Milestones:

Milestone 1:
- The new flashback dialog is implemented and hooked up to the existing soft redirection button. (The in-line flow does not need to work at this stage.)
- When a learner is redirected, the Flashback Dialog should appear. Upon confirmation, the learner is taken back to the most recent instance of the card without adding a duplicate to the stack. This ensures a smoother learning experience without unnecessary reattempts of intermediate questions.
Milestone 2:
- Integrate the Flashback Dialog into the learner flow with an in-line view, where the "Learn Again" button is directly attached to the incorrect answer that triggered the flashback.
- Implement the updated designs for multiple choice and item selection interactions submitted answers to ensure a cleaner, natively rendered experience.
- Additionally, add relevant UI tests to verify the new functionality.

Org-admin/tech-lead commentary/advice

This project involves a lot of very gritty coding work in the most critical code pathways in the app: the core learner flow. These are not simple areas of the app as Oppia's core lesson flow is fundamentally complex, but fortunately there are dozens of past projects and changes to these coding areas which may act as good references, and the codepath has generally excellent test coverage (which means we can be confident when we make changes to these areas).

Making changes to the core lesson flow may be a combination of feeling like a lot of progress is being made (when adding some of the fairly substantial boilerplate involved in adding views to the lesson flow), and other times where it can take a while just to add a few lines of code (due to the surrounding area being particularly complex, such as for the actor-based ExplorationProgressController). It may be very difficult to fully grok the full dependency and data flow for explorations, but it's usually straightforward to jump in and start making changes that, in turn, quickly show up in the lesson viewer frontend.

What we are looking for in proposals

An explanation for how the new functionality will be gated behind a feature flag to ensure that changes don't get shipped to end users before the feature is completed.
A list of test names that will be added (we generally add automated tests for every code change).
Multiple diagrams, particularly:
- A dependency diagram showing how different components (i.e. classes) of the implementation call into each other.
- A flow diagram to show how user interactions flow into different state changes in code.

Technical hints / guidance

General changes explanation:
- The new flows are introducing a novel navigation pathway (being able to navigate 'back' to an earlier state, but interact with it in a completely unique way), as well as a parallel "I'm stuck" flow that's similar to hints and solutions, but more explicit (due to being largely controlled by a "I'm stuck" button). This pathway diverges for cases when the user is stuck on the first card of an exploration.
- This will require changes to both state navigation and general conceptual modeling for ephemeral states. This means refactoring how the app tracks and restores state when moving between flashbacks and the main learner flow.
- Note: we want to show the associated solution from hints and solutions, but only if available. The "See solution" should only be visible if the learner is stuck on the first question.
UI places that need to be updated
- StateFragment & related models, including new views. More importantly, StateItemViewModel will have several new types and subclasses:
  - One for the "I need help" button.
  - One for the "See solution" box (which has two different states based on whether it's revealed).
  - Ones for the pre-baked responses, e.g. "Need help? No problem..." and "Now that you have reviewed the solution..." responses. These could potentially be combined into one.
  - One for the "Try again" button.
  - One for the "Return to question" button.
- New dialog fragment models & listeners for the confirmation prompts for both navigating to a previous card and for revealing the solution.
- SelectionInteractionViewModel to not precompute a list-based HTML answer (i.e. convertSelectedItemsToHtmlString should be removed).
- StatePlayerRecyclerViewAssembler probably has multiple changes needed, but particularly it needs to properly support the new cases where multiple choice and item selection answers should be rendered as separate lists with an indicator for the correct answer. Note that part of this is probably already supported for drag and drop, but it needs to be reanalyzed and appropriated (or copied) for the new use case.
Domain changes
- ExplorationProgressController: to handle detecting new routing state, and to compute when it's appropriate to show a solution. Navigation is also different in these situations and requires additional changes to the controller (or StateDeck).
- StateDeck: requires changes to represent the new ephemeral state of previous cards (only when they're navigated to through the stuck flow; manually navigating back should show the normal CompletedState--this means that the deck is no longer immutable and can have transient states that only show up for specific scenarios).
Model changes
- exploration.proto
  - A new destination added to AnswerOutcome for "refresh previous state" with the state name.
  - A new state_type for reviewable_state of type CompletedState (since no new fields are needed over that, it's just the view itself that needs to be handled differently in the UI layer).
  - Changes to PendingState to represent a new property of whether the user can show the solution. The AnswerOutcome change already provides a signal on whether to show the "I need help" button, but not whether the user has exhausted enough submission attempts to warrant just giving them the solution.
  - UserAnswer probably will need to be changed to mark which item among a list of items is the actual correct answer (for multiple choice and item selection).
  - AnswerAndResponse will need to be turned into a oneof since it can now represent several different things (important: this needs to be done in a binary-compatible way for checkpoint loading to work--checkpoints of older states should be tested as part of this project):
    - An actual answer and response (as it does today).
    - One of the pre-baked responses, e.g. "Need help? No problem..." and "Now that you have reviewed the solution..." responses.
    - The "see solution" box (two versions, revealed and unrevealed).

Suggested PM demo points

Milestone 1: Trigger a "user is soft redirected" state to demonstrate the flashback dialog.
Milestone 2: Demonstrate the "user is soft-redirected" flashback with the in-line "Learn Again" button along with the new item selection and multiple choice interaction views (for submitted answers).

4.2. Platform parameters dashboard

Important

This is a popular project idea. Multiple applicants are interested in this project.

Project Description:

Feature flags are a special type of configurable platform parameter which allows the team to stage features behind remotely configurable flags until they're ready to be launched. This allows features to be developed across multiple releases without users seeing part of the feature (or app stability issues when the feature is enabled), ensuring the team releases high-quality features and doesn't hurt the overall quality and performance of the app. Broadly, platform parameters allow the team to configure the overall app (which can be useful both for feature flags, as described above, and safety 'knobs' such as controlling rate limits to remote APIs to help reduce the chance of server outages).

This project entails introducing a developer-only UI (as part of the developer options section of the app) which displays all platform parameters and feature flags in the app, their current enabled/disabled status (for feature flags) or values (for platform parameters), and their sync status (i.e. whether they're being synced from the server or using a local developer default). It also allows an explicit manual override to force the feature on or off, or to override the platform parameter's value.

Relevant links:

Sample mocks for the new UI
#5725: a reimplementation of the platform parameter and feature flag system
#5565: introduction of cleaner support for overriding platform parameters and feature flags in tests

Tracking issues: #5345

Size: Medium (~175 hours)

Difficulty: Moderate

Potential mentors: @Rd4dev

Product/technical clarifiers: @BenHenning (product + technical)

Discussion forum: https://github.com/oppia/oppia-android/discussions/categories/gsoc-q-a-4-android-projects

Required knowledge/skills:

Figure out the root cause of an issue and communicate it well using a debugging doc.
Build the app and install it on a local device or emulator. Then verify that you can (a) build a non-test library target locally, (b) run a unit test locally, and (c) play through the app locally.
Write new Kotlin code with unit tests.
Change Android UIs, write tests for them, and manually verify that they work.

Related issues:

Issues related to portions of the codebase that will be affected by this project:

#46 - Note that this is a good issue to build familiarity with the developer workflow menu workings, and has smaller chunks that can be done in isolation.
#5600 - Note that this is a specific part of #46 above.
#5636
#3506

Suggested Milestones:

Milestone 1: Key deliverables:
- Display a list of platform parameters and feature flags from a Developer Options menu, along with their current values and sync statuses.
- Set up initial tests to demonstrate that the UI displays correctly.
- The new UI correctly shows all platform parameters and feature flags, and their correct values and sync statuses.
Milestone 2: Key deliverables:
- Support for overwriting and resetting both feature flags and platform parameters back to their default values, including force-restarting the app upon navigating away from the menu (so that the changes can take effect).
- Updated UI tests for the new functionality.
- The new screen fully supports overriding various platform parameters and feature flag values.
- Support for force downloading flags from Oppia web (i.e. by calling PlatformParameterController.downloadRemoteParameters() and asking for an app restart).
- Pending overrides and the indicator for downloading state both should 'survive' device rotations (that is, rotating the device should not cause any temporary state in the UI to be lost).

Org-admin/tech-lead commentary/advice

This project involves introducing a new, isolated user interface that only affects developers (and possibly testers or user study facilitators in the future) which means it doesn't require the same level of gating as regular learner-facing features. It's often nice to work on brand new UIs, as well, since everything is starting in a fresh, clean state rather than building on existing complexity and tests.

The domain side of platform parameters can seem complex at the surface, but it's straightforward to explain and analyze the dataflow after seeing one example of how the app goes from Oppia web to a frontend flag being used to gate a feature (i.e. the whole dataflow of a parameter). This is expected to be a straightforward project that balances domain and frontend work (with a majority of the work being UI-related). Expect to spend a lot of design time during the proposal period working to understand how parameters and flags work, especially with regards to their plumbing and related code generation.

What we are looking for in proposals

A strong understanding of:
- Feature flags and platform parameters lifecycle:
  - Provide a detailed walkthrough of the lifecycle of a specific feature flag or platform parameter describing its behavior under different conditions.
- Developer options menu:
  - Explain how the developer options menu works and its inclusion / exclusion in different builds.
- Dagger dependency gating:
  - Detail how dependencies are configured differently based on the flavor of the app being built, and whether it's a test environment.
A list of test names that will be added (we generally add automated tests for every code change).
Multiple diagrams, particularly:
- A dependency diagram showing how different components (i.e. classes) of the implementation call into each other.
- A flow diagram to show how user interactions flow into different state changes in code.

Technical hints / guidance

General changes explanation:
- Much of the new UI is fairly straightforward to implement, and both the sync status and values are well represented in protos.
- The main complexity comes in providing clean pathways for overriding values, and retaining these values across app restarts.
UI changes:
- New developer options view model & listener for representing the platform parameter/feature flag dashboard.
- New modal fragment/presenter and listener for supporting back navigation and confirming an app restart after making an override change.
- New fragment, presenter, view model, listeners, and RecyclerView view models + views for the actual platform parameter and feature flag list screens themselves, plus changes for override functionality.
Domain changes:
- Introduce a new implementation of PlatformParameterController specific to developer options (similar to how HintHandlerDebugImpl exists and is used). This controller:
  - Delegates functionality to the production implementation of the controller, but overrides as necessary.
  - Exposes the necessary functionality for displaying platform parameters and feature flags.
  - Supports local override for syncing by:
    - Introducing a new persistent cache store for the LocalOverridePlatformParameterDatabase mentioned below).
    - Introducing a new method for computing the list of ephemeral platform parameters by using both the remote sync and local override, with a resolution order of: pick local override if present, pick remote if present, fallback to default otherwise. This should build on the existing functionality provided by the production implementation.
  - Introduce an update function for locally overriding platform parameters that changes the new database (but should not affect current in-process state set in PlatformParameterProcessState).
  - Introduce support for resetting a flag/parameter (which should just remove its entry from the override database).
Model changes:
- A new LocalOverridePlatformParameterDatabase proto (essentially mirroring the existing RemotePlatformParameterAndFeatureFlagDatabase proto) for storing overridden values. This is kept separate from the other database so that a flag/parameter 'reset' can restore back to the original sync state.
- Add 'LOCAL_OVERRIDE' to sync status. This should be used in the override database by default so that the UI is able to properly display the badge for a locally overridden value.
Testing hints:
- Refer to this example to simulate an app restart in tests. Testing should ensure that overridden values are retained across restarts.

Suggested PM demo points

Milestone 1: The new UI correctly shows all platform parameters and feature flags, and their correct value and sync statuses.
Milestone 2: The new screen fully supports overriding various platform parameters and feature flag values. This includes demonstrating the user flows for overriding feature flags and overriding platform parameters in the new UI, and showing that the value changes correctly take effect in the app after a prompted (and accepted) app restart. Double check that force downloading remote parameters works, and that device rotations don't result in temporary UI state being lost.

4.3. Android lint infrastructure and fixes

Project Description:

The Android build ecosystem supports a linting tool which catches a variety of Android-specific problems (beyond those that can be caught by more general-purpose linters like ktlint). Historically a Gradle feature, Android Lint is not yet directly supported in the Bazel world (though there are some alternatives available). This project involves:

Introducing an Oppia Android script that runs Android lint directly.
Supporting the same exemption override support (via XML) but using a textproto interface for parity with the allow-listing and deny-listing configurations used in other Oppia Android scripts.
Pre-populating the exemption list with existing known failures.
Adding wiki documentation to explain how to use the new script.
Filing and/or updating issues with findings such that all remaining Android lint issues are properly tracked in the repository.
Updating CI to run the Android lint script.
Fixing the following categories of lint issues:
- All categories classified as 'errors' by the tool.
- All of the following 'warning' categories:
  - OldTargetApi
  - UnusedAttribute
  - Typos
  - StringFormatCount
  - ObsoleteSdkInt
  - UnusedResources
  - UselessLeaf
  - UselessParent
  - UnusedIds
  - DuplicateStrings
  - SelectableText
  - LabelFor
  - RtlSymmetry
  - UnknownNullness

Tracking issues: #5734

Size: Large (~350 hours)

Difficulty: Hard

Potential mentors: @BenHenning

Product/technical clarifiers: @BenHenning (product + technical)

Required knowledge/skills:

Figure out the root cause of an issue and communicate it well using a debugging doc.
Build the app and install it on a local device or emulator. Then verify that you can (a) build a non-test library target locally, (b) run a unit test locally, and (c) play through the app locally.
Write new Kotlin code with unit tests.

Related issues:

Issues related to portions of the codebase that will be affected by this project:

Most issues under the 'priority' section of the CLaM team board are likely to help build familiarity with broad parts of the codebase which will help with addressing lint issues.
Adding tests for scripts will help build familiarity with the scripting work: #4971. The stats script is especially relevant, too, as it is built to wrap utilities normally used via the command line (not unlike Android lint), including AAPT and apkanalyzer.
#5169 - currently tracked lint categories (note that these aren't all possible categories that can and will be found by the script).

Suggested Milestones:

Milestone 1: Key deliverables:
- Introduce a new script that can run Android lint checks with support for a local textproto file that can override specific failures to allow them to pass.
- Check in a populated exemption list with all known exemptions.
- Introduce a new wiki page explaining how to use the script and update the exemption list.
- Introduce CI support for the new script so that it runs for every change to develop and for all PRs.
Milestone 2: Key deliverables:
- Fix all of the error categories of lint issues, plus the warning categories mentioned in the project description.
- Ensure all exemptions that aren't fixed as part of this project have corresponding tracking issues filed and spec'd with enough context for contributors to work on them.

Org-admin/tech-lead commentary/advice

Scripts usually seem like straightforward changes, and they often can be. However, they almost always uncover unexpected complexities that need to be solved mid-project (which is why this is considered a more difficult project overall). It's also the case that many of the lint issues that are included as part of this project may not have known solutions ahead of time which requires additional problem solving that may occur after the design phase of the project.

That being said, there are many examples of both scripts and exemptions to reference when designing and constructing the script itself. While the exact functionality being implementing (wrapping the Android linter and creating an intermediary step between the exemption XML and a textproto version of it) isn't well defined yet (and should be explained clearly in your proposal), the other boilerplate of a script (textproto loading, script library, running scripts in CI, etc.) is well defined and referenceable.

What we are looking for in proposals

Key details that we expect to be included:

A working demonstration of running the lint tool directly (i.e. not through Gradle) and producing similar output to the examples listed in the technical hints section below.
A strong understanding of:
- How at least 1 specific script in the codebase works (it must have support for textproto exemptions) with a detailed explanation of its dataflow.
A list of test names that will be added (we generally add automated tests for every code change).
Multiple diagrams, particularly:
- A dependency diagram showing how different components (i.e. classes) of the implementation call into each other.
- A flow diagram to show how user interactions flow into different state changes in code.
Clear explanations of each category of lint issue that will be addressed and how.
A clear explanation of what wiki changes will be needed (note that the entire page shouldn't be written out at this stage, but an outline with explanations for each section is expected).

Technical hints / guidance

General changes explanation:
- Background on running the linter
  - Gradle should be running the 'lint' process that's included in the Android cmdline tools (https://developer.android.com/studio#command-tools). A quick dive into that reveals a number of important JARs as part of the classpath:
    - tools.lint-model.jar
    - tools.lint-checks.jar
    - tools.lint-api.jar
    - lint-checks-proto.jar
    - cli.jar (under lib/lint/cli)
    - com.android.tools.lint.Main seems to be the main entrypoint.
    - You either need to see if these libraries are published on Maven, or depend on the command line utilities directly (and wrap com.android.tools.lint.Main in the script).
  - Note that you can download cmdline tools to inspect the lint command line on its own. Some very important details to note:
    - The linter can hang at the end of its process (potentially due to some rogue non-daemon threads). The script will need to work around this limitation.
    - It's up to you to analyze how Gradle interacts with the lint tool in order to understand how to construct a valid command line and run the linter. A place to start is a working Gradle run of the linter for reference which can be done following the instructions in this Gist.
  - Example reports:
    - app/
    - data/
    - domain/
    - testing/
    - utility/
  - Important: The files above were produced using lint 4.2.2, but the latest (as of drafting these notes) is 8.2.0.
    - You should aim to use the latest compatible version of the lint tool (8.2.0 likely won't work due to requiring JDK 17, but you'll need to check this).
    - Furthermore, different versions will have differing results. You should aim to find the most number of issues possible (i.e. configure the tool and its arguments to catch as many problems as it's able to within the codebase).
- The general flow of the script will probably be to process the exemptions proto in order to generate an Android-lint compatible XML exemption file (to pass in), and then run the linter and interpret the results to determine a pass/fail for the overall process.
  - The lint tool supports text-based output, XML, and SARIF. It's expected that the script will parse either XML or SARIF formats as they are strongly formatted whereas text may change in future versions of the tool.
Script changes:
- A new proto message needs to be added in script_exemptions.proto to properly represent exemption failures that are found by Android Lint.
  - These exemptions should be designed in a way to ensure that they aren't fragile, i.e. prefer exemption specific categories of failures on a per-file basis rather than per-line. While not perfect, we ultimately aim to reach 0 exemptions in the long-term so per-file is a reasonable stop-gap (we use this approach in other places, though Android lint's exemptions are more elaborate since we need categorical exemptions).
- A new textproto under scripts/assets to contain the new exemptions (all existing failures should be exempted by default before fixes are checked in).
- A new script + tests for wrapping Android lint (no new utilities are expected to be needed at this stage, though it's possible we will need something for interacting with cmdline tools).
  - The script will probably need to fail gracefully if it can't locate Android lint, e.g. because cmdline tools wasn't installed, with instructions on how to install it (e.g. using sdkmanager). This should only be necessary if it's not possible to bundle the tool with the script (such as by using the Maven dependency mentioned above).
- Changes to static_checks.sh and static_checks.yml to include the new lint script in each, respectively.
UI/domain changes:
- Unlikely that there are substantial changes here, but a lot of UI files will require changes as part of addressing the issues of the lint categories mentioned in the project description.

Suggested PM demo points

Milestone 1: Demonstrate that the script can be run locally to catch lint issues. Demonstrate that the script runs on develop, and is passing. Demonstrate that the script runs for pull requests and catches lint failures being introduced by the pull request. Show that exemptions listed in the exemptions file are not reported.
Milestone 2: Demonstrate that each category of lint failure in the project description has been fully resolved (i.e. by demonstrating that the linter is running for those checks, no exemptions for those types of issues exist, and the script passes). Verify that each category of issue is properly caught by demonstrating the linter catching these failures if reintroduced in the codebase.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Google-Summer-of-Code-2025.md

Google-Summer-of-Code-2025.md

Table of Contents

Contributors

Getting started

FAQs

Dates and Deadlines

Types of work related to Oppia projects

GSoC Proposal Template

Tips for writing a good project plan

What should applicants expect from mentors in a proposal review?

Selection Criteria

Communication

Oppia's Project Ideas List

Learner and Creator Experience (LaCE) team

Contributor Dashboard team

Developer Workflow team

Android team

Learner and Creator Experience (LaCE) team

1.1. Clean up the structure for study guides and worked examples

1.2. Fix the most common server errors

1.3. Lesson player redesign

Contributor Dashboard team

2.1. Show AI-powered translation suggestions to translation submitters

Developer Workflow Team

3.1. Acceptance tests

3.2. Consolidate entity migration jobs

3.3. Standardize and validate domain objects and storage models

Android team

4.1. Flashbacks

4.2. Platform parameters dashboard

4.3. Android lint infrastructure and fixes

Files

Google-Summer-of-Code-2025.md

Latest commit

History

Google-Summer-of-Code-2025.md

File metadata and controls

Table of Contents

Contributors

Getting started

FAQs

Dates and Deadlines

Types of work related to Oppia projects

GSoC Proposal Template

Tips for writing a good project plan

What should applicants expect from mentors in a proposal review?

Selection Criteria

Communication

Oppia's Project Ideas List

Learner and Creator Experience (LaCE) team

Contributor Dashboard team

Developer Workflow team

Android team

Learner and Creator Experience (LaCE) team

1.1. Clean up the structure for study guides and worked examples

1.2. Fix the most common server errors

1.3. Lesson player redesign

Contributor Dashboard team

2.1. Show AI-powered translation suggestions to translation submitters

Developer Workflow Team

3.1. Acceptance tests

3.2. Consolidate entity migration jobs

3.3. Standardize and validate domain objects and storage models

Android team

4.1. Flashbacks

4.2. Platform parameters dashboard

4.3. Android lint infrastructure and fixes