snapshot of https://github.com/zulip/zulip.git @ 48c69911c7dd4e03b20552eb3bd77ad8151c1357 (2026-09-15)

docs/outreach/apply.md

@@ -0,0 +1,171 @@
+# How to apply
+
+This page should help you get started with applying for an outreach program
+with Zulip.
+
+We try to make the application process as valuable for the applicant as
+possible. Expect high-quality code reviews, a supportive community, and
+publicly viewable patches you can link to from your resume, regardless of
+whether you are selected.
+
+## Application criteria
+
+We expect applicants to have experience with the technologies relevant
+to their project, or else have strong general programming
+experience. If you are just getting started learning how to program,
+we recommend taking time to learn the basics (there are many great
+online materials available for free!), and applying in the next
+program cycle.
+
+In addition to the requirements of the specific outreach program
+you're applying to, successful applicants are expected to demonstrate
+the following:
+
+1. **Responsibility for their own work.** Strong applicants consistently take
+   responsibility for all their interactions with the Zulip community: the code
+   changes they propose, PR descriptions and comments, discussions in the
+   development community, etc. They understand the importance of respecting the
+   time of everyone they interact with. If they use AI, they always follow
+   [Zulip's AI use
+   policy](../contributing/contributing.md#ai-use-policy-and-guidelines).
+
+1. **Ability to contribute to a large production codebase.** Accepted applicants
+   generally have five or more merged (or nearly merged) pull
+   requests, including at least a couple involving significant
+   complexity. The quality of your best work is more important than
+   the quantity, so be sure to [follow our coding
+   guidelines](../contributing/code-style.md) and [self-review your
+   work](../contributing/code-reviewing.md#reviewing-your-own-code)
+   before submitting it for review.
+
+1. **Clear communication.** Building open-source software is a collaborative
+   venture, and effective communication is key to making it successful. Learn
+   how to [ask great questions](../contributing/asking-great-questions.md), and
+   explain your decisions clearly [in your commit
+   messages](../contributing/commit-discipline.md#commit-messages) and [on your
+   pull requests](../contributing/reviewable-prs.md). Communicate accurately and
+   succinctly -- no AI slop!
+
+1. **Improvement in response to feedback.** Don't worry if you make
+   mistakes in your first few contributions! Everyone makes mistakes
+   getting started — just make sure you learn from them!
+
+We are especially excited about applicants who:
+
+- Help out other applicants
+
+- Try to solve their own obstacles, and then [ask well-formed
+  questions](/contributing/asking-great-questions)
+
+- Develop well thought out project proposals
+
+## Applicant eligibility
+
+In our experience, a large (350-hour) project is incompatible with a second
+internship or job. Trying to do both leads to a stressful summer where you don't
+really get to benefit from the mentorship on offer, and will likely struggle to
+complete the GSoC program at all. Any outside commitments beyond the following
+require explicit discussion and approval:
+
+- 10 hours/week for a large project
+- 25 hours/week for a medium project
+
+We are happy to accept both student and non-student GSoC participants.
+
+## Getting started
+
+If you are new to Zulip, our [contributor
+guide](../contributing/contributing.md) is the place to start. It offers a
+detailed walkthrough for submitting your first pull request and beyond, with
+many pointers to additional documentation.
+
+## Putting together your application
+
+::: warning
+**We do not allow the use of AI for writing GSoC applications.** We want to see
+what _you_ think and how you communicate it. If we see that an application was
+written using AI, it will be rejected without review.
+:::
+
+### What to include
+
+In addition to following all the instructions for the program you are applying
+to, your application should describe the following:
+
+- Why you are applying:
+  - Why you're excited about working on Zulip.
+  - What you are hoping to get out of your participation in the program.
+  - How you selected your project.
+- Your summer obligations beyond GSoC (e.g., jobs, exams, travel plans, etc.),
+  and how you plan to manage your time to complete your project with those
+  obligations in mind. Do you expect to complete the program in 12 weeks, or
+  would an extended timeline be more realistic?
+- Relevant experience:
+  - Summary of your **prior experience with the technologies** used by Zulip.
+  - Your **prior contributions to open-source projects** (including pull requests, bug
+    reports, etc.), with links.
+  - Any other **materials which will help us evaluate how you work**, such as
+    links to personal or school projects, along with brief descriptions.
+- Your **contributions to Zulip**, including pull requests, bug reports, and helping
+  others in the development community (with links to all materials).
+- A **project proposal** (see below).
+
+**A note for Outreachy applicants**: It is not practical for us to individually
+help you develop a specific timeline for your application. We expect you to
+submit a project proposal as described below, and will help you manage the
+timeline for your project if your application is selected.
+
+### Project proposals
+
+Your first priority during the contribution period should be figuring out how to
+become an effective Zulip contributor. Start developing your project proposal
+only once you have experience with iterating on your PRs to get them ready for
+integration. That way, you'll have a much better idea of what you want to work
+on and how much you can accomplish.
+
+As [discussed in the guide to having an amazing experience during the
+program](./experience.md#what-about-my-proposal):
+
+> We have a fluid approach to planning, which means you are very unlikely to end
+> up working on the exact set of issues described in your proposal. Your proposal
+> is not a strict commitment (on either side).
+
+Your proposal should demonstrate your thoughtfulness about what you want to work
+on, and consideration of project complexity. We will evaluate it based on the
+following criteria:
+
+- Does it give us a good idea of what areas of Zulip you are most excited to
+  work on?
+- Does it demonstrate some familiarity with the Zulip codebase, and reflection
+  on what makes for a coherent project that is well-aligned with your interests
+  and skill set?
+- Does it demonstrate your ability to put together a reasonable plan? Have you
+  thought carefully about the scope of various pieces of your project and their
+  dependencies? Are you taking into account the fact that there can be a lot of
+  time in software development between having an initial prototype and merging
+  the final, fully reviewed and tested, version of your code?
+- Are you proposing a project that would make a significant positive impact on the
+  areas you plan to focus on?
+
+Regardless of which program you are applying to, you can use the [GSoC project
+ideas list](./gsoc.md#project-ideas-by-area) as a source of inspiration for
+putting together your proposal.
+
+### Circulating your application for feedback
+
+We highly recommend posting a rough draft of your application at least one week
+before the deadline. That way, the whole development community has a chance to
+give you feedback and help you improve your proposal.
+
+- If you do not have a complete draft ready, at a minimum, we recommend posting
+  your **project proposal**, along with **your contributions to Zulip** for
+  context.
+
+- Please post a link to your draft in the Zulip development community
+  channel dedicated to your program (e.g.,
+  [#GSoC](https://chat.zulip.org/#narrow/channel/14-GSoC) or
+  [#Outreachy](https://chat.zulip.org/#narrow/channel/391-Outreachy)). Use
+  `Your name - project proposal` as the topic.
+
+- We recommend linking to a draft in an app that works in the browser and allows
+  commenting, such as Dropbox Paper or Google Docs.

docs/outreach/experience.md

@@ -0,0 +1,338 @@
+# How to have an amazing experience
+
+If you are joining Zulip as part of an outreach program (e.g.,
+[GSoC](https://summerofcode.withgoogle.com/) or
+[Outreachy](https://www.outreachy.org/)), welcome! Please make sure you read
+this page carefully early on, and we encourage you to come back to it over the
+course of the program.
+
+## Your goals
+
+Your experience as a Zulip outreach program participant is your
+responsibility, and we strongly encourage you take full ownership. The
+more care, attention, and energy you put in, the more you'll be able
+to get out of the program. We're here to support you, but the journey
+is yours to make!
+
+The following are the main goals we'll be guiding you towards, as they are
+shared by the great majority of program participants, and are aligned with the
+objectives for our umbrella programs. If you have additional goals in mind for
+your experience, please let your mentor and the community know, so that we can
+help you along.
+
+- You should gain mastery of the skills needed to be a self-sufficient and
+  effective open-source developer. By the end of the program, all but the most
+  complex PRs should ideally go through only a couple of rounds of code review
+  before being merged. Our most successful contributors gain the expertise to
+  become a maintainer for one or more areas within Zulip.
+
+- You should become a valued member of the Zulip community, who works to make it
+  better for all involved. Reviewing PRs, helping others debug, providing
+  feedback, and finding bugs are wonderful ways to contribute beyond the code in
+  your own project.
+
+- You should feel proud of the significant positive impact you've made on the
+  areas you focused on. Your areas should be more polished, and have several
+  new major features that you have implemented. The sections of code you worked
+  on should be more readable, better-tested, and have clearer documentation.
+
+Please note that outreach programs are not a competition. Different participants
+have different types of projects and progress will look different for each project.
+Your focus should be on making steady and consistent progress and continuously
+learning from your work.
+
+Don't forget to have fun! Spending a few months coding on open source is an
+amazing opportunity, and we hope you'll have a blast. Your acceptance to the
+program means that we are confident that if you put in the effort, your
+contributions to the open source world will be something you can be proud of for
+the rest of your life.
+
+## You and your mentor
+
+Zulip operates under a **group mentorship** model. Every participant in a Zulip
+mentorship program will:
+
+- Have an assigned mentor, who will be their go-to for personal questions and
+  concerns, and a consistent point of contact throughout the program.
+
+- Receive lots of feedback and mentorship from others in the Zulip development
+  community, in code reviews on pull requests, and by posting
+  [questions](../contributing/asking-great-questions.md) and ideas in public
+  channels.
+
+Mentors and contributors should stay in close contact. We recommend setting up a
+weekly check-in call to make sure you stay on track and have a regular
+opportunity to ask your mentor questions and get their feedback. Talk with your
+mentor about the status of your projects, and get their advice on how to make
+progress if some project feels stuck.
+
+Bring up problems early, whether technical or otherwise. If you're stressed
+about something, mention it your mentor immediately, so they can help you solve
+the problem. If you're stressed about something involving your mentor, bring it
+up with an organization admin.
+
+## Communication and check-ins
+
+Communicating proactively with your mentor, your peers, and the rest of the
+Zulip community is vital to having a successful mentorship program with Zulip.
+It's how we can help you make sure you're working on a great set of impactful
+issues, and not getting stuck or taking an approach that won't work out.
+
+A key communication tool we use is posting regular public check-ins, which are
+a required part of the program. We recommend reading your peers' check-ins
+to get a feel for what they are working on and share ideas!
+
+### Getting feedback and advice
+
+We strongly encourage all Zulip contributors to post their questions and ideas
+in public channels in the [Zulip development
+community](https://zulip.com/development-community/). When you post in a public
+channel, you give everyone the opportunity to help you out, and to learn from
+reading the discussion.
+
+Examples of topics you might ask about include:
+
+- Making a technical decision while solving the issue.
+
+- Making a product decision, e.g., if the issue description does not address some
+  details, or you've identified a problem with the plan proposed in the issue.
+
+- Making a design decision, e.g., if you have a couple of different ideas and
+  aren't sure what looks best.
+
+See our guide to [asking great
+questions](../contributing/asking-great-questions.md) for detailed advice on how
+to ask your questions effectively.
+
+### How to post your check-ins
+
+A check-in is a regular update that you post in the Zulip development community.
+You can find many examples in the
+[#checkins](https://chat.zulip.org/#narrow/channel/65-checkins) and
+[#GSoC](https://chat.zulip.org/#narrow/channel/14-GSoC) channels.
+
+- **Frequency**: _Regular check-ins are a required for all program
+  participants._ If you are working 20+ hours per week, post a check-in at least
+  twice a week, e.g., Tuesday and Friday. If you are working less than 20 hours
+  per week, post a check-in at least once a week.
+
+  Swatches of low productivity are very common, so post your check-ins no matter
+  how much progress you've made. Regular communication helps your mentor keep up
+  with your progress. Mentors can also help you out if you are facing any difficulties.
+
+- **Where to post**: Unless your mentor or program administrator requests
+  otherwise, post your check-ins in the
+  [#checkins](https://chat.zulip.org/#narrow/channel/65-checkins) channel, using your
+  name as the topic.
+
+- **What to include** in each check-in:
+
+  - The **status** of each ongoing project, e.g., in progress, awaiting feedback,
+    addressing review feedback, stuck on something, blocked on other work, etc.
+    To make your update easy to read, include brief descriptions of what you're
+    working on, not just issue/PR numbers. Please also include what has changed
+    for each project since the last check-in. If nothing has changed, mention
+    that explicitly as well.
+
+  - For projects where you are waiting on feedback, what **type of feedback** is
+    needed (e.g., product review, next round of code review after initial
+    feedback has been addressed, answer to some question, etc.). Use [silent
+    mentions](https://zulip.com/help/mention-a-user-or-group#silently-mention-a-user)
+    to indicate whose feedback is required, if you think you know who it should
+    be.
+
+  - Any questions or problems you **feel stuck** on. If there's an ongoing thread
+    elsewhere, please link to it. Please post each question/problem in a
+    separate message to make it convenient to quote-and-reply to address it.
+    Note that discussions about your work will happen in all the usual places
+    (#**frontend**, #**backend**, #**design**, etc.), and those are the
+    channels where you should be _starting_ conversations. Your check-ins are a
+    place to point out where you're feeling stuck, e.g., there was some
+    discussion in a channel or on GitHub, but it seems to have petered out
+    without getting to a decision, and you aren't sure what to do.
+
+  - What you've been **actively working** on since your last check-in.
+
+  - What you **intend to focus** on until your next check-in. Indicate if you are
+    unsure and would appreciate some suggestions or feedback on your plan.
+
+## Peer reviews
+
+Reviewing others' changes is one of the best ways to learn to be a better
+developer, since you'll both see how others solve problems and also practice the
+art of catching bugs in unfamiliar code. As discussed in the [code review
+guide](../contributing/code-reviewing.md):
+
+> Doing code reviews is a valuable contribution to the Zulip project. It’s also
+> an important skill to develop for participating in open-source projects and
+> working in the industry in general... Anyone can do a code review – you don’t
+> have to have a ton of experience.
+
+For programs with multiple participants, we will set up a **code review buddies**
+system at the start of the program:
+
+1. Everyone will be assigned to a group of 2-3 people who will be your buddies
+   for first-round code reviews. (In some cases, your buddy will be your
+   mentor.)
+
+2. Start by [self-reviewing your own code](../contributing/code-reviewing.md).
+
+3. When ready, request a review from your code review buddies. Use [GitHub's
+   review request
+   feature](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review)
+   to send your request. This makes the PR's status clear to project maintainers.
+   You may also want to send a quick direct message to let your buddies know
+   their attention is needed.
+
+4. Please respond to code review requests promptly (within one workday), and
+   follow the guidelines [in the code review
+   guide](../contributing/code-reviewing.md).
+
+Your initial reply does not have to be a full review. If you’re pressed for
+time, start by quickly sharing your initial thoughts or feedback on the general
+direction, and let the PR author know when you expect to provide a more detailed
+review.
+
+Make sure the GitHub comments on the PR are always clear on the status -- e.g.,
+buddy code review has been requested, feedback is being discussed, code buddy
+has approved the PR, etc. This will help project maintainers know when it's time
+to move on to the next step of the review process.
+
+## How do I figure out what to work on?
+
+Our goal is for contributors to improve their skills while making meaningful
+contributions to Zulip. We like to be flexible, which means that you are
+unlikely to work precisely on the issues described in your proposal, and that's
+OK!
+
+In practice, this means that over the course of the program, you will:
+
+- Get frequent guidance regarding what to work on next by posting your ideas and
+  questions about what to tackle next in your
+  [check-ins](#how-to-post-your-check-ins).
+
+- Like other Zulip contributors, [claim
+  issues](../contributing/contributing.md#claiming-an-issue) only when you
+  actually start work on them.
+
+If someone else fixes an issue you were planning to fix, don't worry about it!
+Consider [reviewing their work](../contributing/code-reviewing.md) to build your
+expertise in the subsystem you're working on.
+
+### Prioritization
+
+Always keep the following order of priorities in mind:
+
+1. Your top priorities should be **fixing any regressions you introduced** with
+   recently merged work, and **fixing any important bugs or regressions** that
+   you pick up or are assigned.
+
+2. **Review others' pull requests** promptly. As you'll experience yourself, getting quick
+   feedback on your PR helps immensely. As such, if you are asked to review a
+   PR, aim to provide an initial reply within one workday.
+
+3. If any of your PRs are actively undergoing review or are marked as
+   "integration review" ready, be sure to **rebase** them whenever merge
+   conflicts arise.
+
+4. Next, prioritize **responding to code review feedback** over starting new
+   work. This helps you and your reviewers maintain context, which makes it
+   easier to make progress towards getting your work integrated.
+
+5. Do any relevant **follow-ups to larger projects** you've completed, to make sure
+   that you've left things better than how you found them.
+
+6. Finally, if all of the above are in good shape, **find a new issue** to pick up!
+
+### What about my proposal?
+
+We have a fluid approach to planning, which means you are very unlikely to end
+up working on the exact set of issues described in your proposal. Your proposal
+is not a strict commitment (on either side).
+
+In terms of managing your work:
+
+- Regardless of whether an issue was mentioned in your proposal, make
+  sure you bring it up in your check-ins when you plan to start
+  working on something. Project priorities shift over time, and we
+  may have suggestions for higher-priority work in your area of
+  interest, or issues that will serve as good preparation for other
+  work you are excited about. It's also possible that a project idea
+  is not ready to be worked on, or needs to be sequenced after other projects.
+
+- When asking for recommendations for what to work on next, it's helpful to
+  include a reminder of what areas you're most excited about, especially early
+  on in the program when we're still getting to know you. Do not expect program
+  administrators to remember what issues were listed in your proposal.
+
+While some program participants stick closely to the spirit of their proposal,
+others find new areas they are excited about in the course of their work. You
+can be highly successful in the program either way!
+
+### Tips for finding issues to pick up
+
+- Look for, claim, and fix bugs to help keep Zulip polished. Bugs and polish
+  make a huge difference to our users' experience. If you can fix a
+  [high-priority
+  bug](https://github.com/zulip/zulip/issues?page=2&q=is%3Aopen+is%3Aissue+label%3Abug+label%3A%22priority%3A+high%22)
+  in an area you've been working on, it is likely to have more impact than any
+  new feature you might build.
+
+- If you're working on something other than the Zulip server / web app codebase,
+  follow your project on GitHub to keep track of what's happening.
+
+- The Zulip server / web app project is too active to follow, so instead we
+  recommend joining [Zulip's GitHub teams](https://github.com/orgs/zulip/teams)
+  that relate to your projects and/or interests. When an area label is added to
+  an issue or PR, [Zulipbot](https://github.com/zulip/zulipbot) automatically
+  mentions the relevant teams for that area, subscribing all team members to the
+  issue or PR thread.
+
+### Staying productive
+
+Here are some tips for making sure you can always be productive, even when
+waiting for a question to be answered or for the next round of feedback on a PR:
+
+- You should be working on multiple issues (or parallelizable parts of a large
+  issue) at a time. That way, if you find yourself blocked on one project, you
+  can always push on a different one in the meantime.
+
+- It can help to plan a bit in advance by thinking about the issue you intend to
+  pick up next. Are there decisions that will require input from others? Try to
+  start the conversation a few days before you need an answer.
+
+- If you are waiting for some decision to be finalized, consider doing
+  preparatory refactoring that will make the feature easier to complete and can
+  already be merged.
+
+## How else can I contribute?
+
+- Participate and be helpful in the community! Helping a new contributor get
+  started or answering a user's question are great ways to contribute.
+
+- Test and give feedback on new features that are deployed in the development
+  community! It's fun, and it helps us find bugs before they reach our users.
+
+- As you are doing your work, keep thinking about what could make contributing to Zulip
+  easier for both yourself and the next generation of Zulip contributors. And then
+  make those ideas reality!
+
+## Timeline extensions for GSoC
+
+Starting in 2022, it became possible to extend the timeline of a GSoC project.
+This can be a great idea if you don't have a lot of time to dedicate each week,
+or have an interruption during the program (e.g., getting sick, travel, family
+obligations, etc.).
+
+We're generally very flexible, so if extending your project dates would make it
+less stressful to put in the required hours, please discuss this with your
+mentor and Zulip's GSoC administrator. Please start this conversation
+proactively as soon as you realize that you might need an extension, as this
+will give us confidence that you'll be able to manage your time effectively to
+successfully complete the program.
+
+It is possible to have the midterm evaluation happen more than half-way through
+the project timeline. If the balance of hours you plan to spend on GSoC is
+significantly weighted towards the latter half of your GSoC contribution period,
+please contact Zulip's program administrator to discuss pushing out the midterm
+evaluation.

docs/outreach/gsoc.md

@@ -0,0 +1,378 @@
+# GSoC project ideas
+
+This page describes ideas you can use as a starting point for your project
+proposal. If you have not done so yet, you should **start by reading our [guide on
+how to apply](./apply.md)** to a Zulip outreach program. As noted in the guide:
+
+> Your first priority during the contribution period should be figuring out how
+> to become an effective Zulip contributor. Start developing your project proposal
+> only once you have experience with iterating on your PRs to get them ready for
+> integration. That way, you'll have a much better idea of what you want to work
+> on and how much you can accomplish.
+
+## Project size
+
+We have designed all our projects to have incremental milestones that can be
+completed throughout the program. Consequently, Zulip projects described below
+are generally compatible with both large-sized (350 hours) and medium-sized (175
+hours) projects. Of course, the amount of progress you will be expected to make
+depends on whether you are doing a 175-hour or 350-hour project. Because it
+takes significant time investment to learn how to contribute complex features to
+Zulip's codebase, we are not planning to offer small-size projects.
+
+Contributors who master the art of consistently packaging their work
+into correct, [reviewable pull
+requests](../contributing/reviewable-prs.md) are able to make major
+improvements to the Zulip app. If you pay attention to the contributor
+guidelines, carefully review your own work before asking anyone else
+for review, take the time to clearly communicate your changes, and
+apply the feedback you receive to your next contribution, you'll be
+amazed at what you can accomplish.
+
+## Focus areas
+
+For 2026, we are particularly interested in GSoC contributors who have
+strong skills at full-stack feature development, Typescript, visual design,
+HTML/CSS, Flutter, or performance optimization. So if you're an applicant with
+those skills and are looking for an organization to join, we'd love to
+talk to you!
+
+The Zulip project has a huge surface area, so even when we're focused
+on something, a large amount of essential work goes into other parts of
+the project. Every area of Zulip could benefit from the work of a
+contributor with strong programming skills, so don't feel discouraged if
+the areas mentioned above are not your main strength.
+
+## Project ideas by area
+
+This section contains the seeds of project ideas; you will need to do research
+on the Zulip codebase, read issues on GitHub, read documentation, and talk with
+developers to put together a complete project proposal. It's also fine to come
+up with your own project ideas. As you'll see below, you can put together a
+great project around one of the [area
+labels](https://github.com/zulip/zulip/labels) on GitHub; each has a cluster of
+problems in one part of the Zulip project that we'd love to improve.
+
+### Full stack and web frontend focused projects
+
+Code: [github.com/zulip/zulip](https://github.com/zulip/zulip/) -- Python,
+Django, TypeScript/JavaScript, and CSS.
+
+- **Cluster of priority features**. Implement a cluster of new full
+  stack features for Zulip. The [high priority
+  label](https://github.com/zulip/zulip/issues?q=is%3Aissue+is%3Aopen+label%3A%22priority%3A+high%22)
+  documents hundreds of issues that we've identified as important to
+  the project. A great project can be 3-5 significant features around
+  a theme (often, but not necessarily, an [area
+  label](https://github.com/zulip/zulip/labels)); the goal will be to
+  implement and get fully merged a cluster of features with a
+  meaningful impact on the project. Zulip has a lot of half-finished
+  PRs, so some features might be completed by reading, understanding,
+  rebasing, and reviving an existing pull request. 175 or 350
+  hours; difficulty will vary. **Skills required**: Depends on the
+  features; Tim Abbott will help you select an appropriate cluster
+  once we've gotten to know you and your strengths through your getting
+  involved in the project.
+
+  Experts: Tim Abbott and various others depending on project area
+
+- **Complete some unfinished projects**. This is a variant of the
+  previous project idea category, but focused on projects with
+  significant existing work to start from and polish, rather than
+  projects that have not been seriously attempted previously.
+
+  We maintain a [completion candidate label][completion-candidate]
+  for pull requests where a previous contributor
+  (sometimes via GSoC!) did significant work towards something
+  valuable, and there's significant feedback from maintainers, but the
+  project was never finished, and requires significant further effort
+  from a new contributor in order to progress. One of our
+  goals for this summer's GSoC is to complete many of these
+  issues. Start by picking something that's interesting to you, and
+  you feel you have the skills required to complete. Read the code and
+  the feedback, and then create your own PR for the issue. See the [guide on
+  continuing unfinished work][continuing-work] for details.
+  175 or 350 hours; difficulty will vary.
+  **Skills required**: Varies with project; a common skill will be
+  good reading comprehension and organization/communication skills, to
+  walk maintainers through how you resolved problems, addressed any
+  pending feedback on the previous PR, and your understanding of the
+  outstanding questions for a given project. Taking the time to get
+  really good at resolving merge conflicts is likely to be valuable
+  here as well.
+
+  Experts: Tim Abbott and various others depending on project area
+
+[completion-candidate]: https://github.com/zulip/zulip/pulls?q=is%3Aopen+is%3Apr+label%3A%22completion+candidate%22
+[continuing-work]: ../contributing/continuing-unfinished-work.md
+
+- Add the core infrastructure for **topic-based permissions and settings**
+  like [pinned topics](https://github.com/zulip/zulip/issues/19483)
+  and [read-only topics](https://github.com/zulip/zulip/issues/26944),
+  and then build some of those settings. This project will be a
+  mixture of Python 3/PostgreSQL work, including thinking about
+  database transactions and races, writing database migrations
+  intended to be run live at scale, and complex logic to handle moving
+  messages correctly in the context of these settings, including
+  significant changes to the Zulip API and API documentation.
+  175 or 350 hours; fairly difficult.
+  **Skills required**: A high level of fluency with writing readable
+  Python 3 and thinking about corner cases.
+
+  Experts: Tim Abbott, Prakhar Pratyush
+
+- Zulip's [**REST API documentation**](https://zulip.com/api/), which is an
+  important resource for any organization integrating with Zulip, as
+  well as the developers of our API clients. Zulip has a [nice
+  framework](../documentation/api.md) for writing API documentation
+  built by past GSoC students based on the OpenAPI standard with
+  built-in automated tests of the data both the Python and curl
+  examples. However, the documentation isn't yet what we're hoping
+  for: there are a few dozen endpoints that are missing, several of
+  which are quite important, the visual design isn't perfect
+  (especially for, e.g., `GET /events`), many templates could be deleted
+  with a bit of framework effort, etc. See the [API docs area
+  label][api-docs-area] for some specific projects in the area, and
+  [this api documentation discussion][czo-api-endpoints] for current
+  priorities on API endpoints to document (`git grep pending_endpoints`).
+  Our goal for the summer is for 1-2 students to resolve all open issues
+  related to the REST API documentation. 175 or 350 hours; difficulty
+  easy or medium. **Skills required**: Python programming. Expertise
+  with reading documentation and English writing are valuable, and
+  product thinking about the experience of using third-party APIs is
+  very helpful.
+
+  Expert: Lauryn Menard
+
+[api-docs-area]: https://github.com/zulip/zulip/issues?q=is%3Aopen%20is%3Aissue%20label%3A%22area%3A%20documentation%20(api)%22
+[czo-api-endpoints]: https://chat.zulip.org/#narrow/channel/412-api-documentation/topic/Undocumented.20endpoint.20priorities/with/2397881
+
+- **Improve the UI and visual design** of the Zulip web app. We are working on a
+  major redesign for the core surfaces of the Zulip web app -- see the [redesign
+  label][redesign-label] for specced out work, with more to come. We're
+  particularly excited about students who are interested in making our CSS clean
+  and readable as part of working on the UI. 175 or 350 hours; medium to
+  difficult. **Skills required**: Design, HTML and CSS skills; most important is
+  the ability to carefully verify that one's changes are correct and will not
+  break other parts of the app; design changes are very rewarding since they are
+  highly user-facing, but that also means there is a higher bar for correctness
+  and reviewability for one's work. A great application would include PRs making
+  small, clean improvements to the Zulip UI (whether logged-in or logged-out
+  pages).
+
+  Experts: Aman Agrawal, Karl Stolley, Alya Abbott
+
+[redesign-label]: https://github.com/zulip/zulip/issues?q=is%3Aopen+is%3Aissue+label%3Aredesign
+
+- **Improve type safety of node tests**. Rework Zulip's [automated
+  node tests](../testing/testing-with-node.md) to use objects that
+  consistently have the correct type. Currently, many tests use fake
+  message, user, or channel objects with only a handful of fields
+  relevant to the test. We've been working towards
+  `web/tests/lib/example_*`. A good starter project would be to try to
+  convert a small test module that currently does not use the
+  `make_user` type functions to do so. The [main TypeScript migration
+  thread](https://chat.zulip.org/#narrow/channel/6-frontend/topic/typescript.20migration/with/2085240)
+  is useful background reading, and
+  [#frontend](https://chat.zulip.org/#narrow/channel/6-frontend)
+  channel is a good place to start new topics while working on this
+  project. 175 or 350 hours; medium difficulty. **Skills required**:
+  TypeScript fluency, and the discipline
+  to write easily reviewed pull requests that often will include a
+  series of changes to clean up an individual test while you're
+  working on it.
+
+  Experts: Afeefuddin, Lalit
+
+- **Replace hundreds of `dict[str, Any]` types with modern
+  dataclasses**. While functionally efficient, `dataclasses` are more
+  readable, safe against typos, and have nice support for optimizing
+  them further using `__slots__`. A lot of Zulip server code was
+  written before dataclasses existed, and while a lot has been
+  converted naturally as part of other projects, we'd like to make a
+  focused push to replace the remaining ones. This project will
+  involve making dozens of small commits and PRs, each a clean
+  refactor converting a single type. Use [this
+  conversation](https://chat.zulip.org/#narrow/channel/3-backend/topic/migrating.20to.20dataclasses/near/2085283)
+  for discussion and coordination. **Skills required**. Solid
+  understanding of statically typed Python, and the discipline to
+  learn to write refactoring commits that are easy to integrate,
+  following our standard guidelines, because they convincingly don't
+  change any product behavior while improving type-safety.
+
+  Experts: Tim Abbott, Anders Kaseorg
+
+- **Optimize performance and scalability**, either for the web
+  frontend or the server. Zulip is already one of the faster web apps
+  out there, but we have a number of ideas for how to make it
+  substantially faster yet. This is likely a particularly challenging
+  project to do well, since there are a lot of subtle interactions to
+  understand. 175 or 350 hours; difficult. **Skill recommended**:
+  Strong debugging, communication, and code reading skills are most
+  important here. JavaScript experience; some Python/Django
+  experience, some skill with CSS, ideally experience using the Chrome
+  Performance profiling tools (but you can pick this up as you go) can
+  be useful depending on what profiling shows. Our [backend
+  scalability design doc](../subsystems/performance.md) and the
+  [performance label][perf-label] may be helpful reading for the
+  backend part of this.
+
+  Experts: Tim Abbott
+
+[perf-label]: https://github.com/zulip/zulip/labels/area%3A%20performance
+
+- Fill in gaps, fix bugs, and improve the framework for Zulip's **library of
+  native integrations**. We have about 120 native integrations, but there are a
+  number of others we would like to add. Also, several extensions to the
+  framework that would dramatically improve the user experience of using
+  integrations, e.g., being able to do callbacks to third-party services
+  like Stripe to display more user-friendly notifications. The [the integrations
+  label on GitHub](https://github.com/zulip/zulip/labels/area%3A%20integrations)
+  lists some of the priorities here (many of which are great preparatory
+  projects). 175 or 350 hours; medium difficulty with various possible difficult
+  extensions. **Skills required**: Strong Python experience, will to install and
+  do careful manual testing of third-party products. Fluent English, usability
+  sense and/or technical writing skills are all pluses.
+
+  Experts: Niloth, Lauryn Menard
+
+- **Make Zulip integrations easier for nontechnical users to set up**.
+  This includes adding a backend permissions system for managing bot
+  permissions (and implementing the enforcement logic), adding an
+  OAuth system for presenting those controls to users, as well as
+  making the `/integrations` page UI have buttons to create a bot,
+  rather than sending users to the administration page. 175 or 350
+  hours; easy to difficult depending on scope. **Skills recommended**:
+  Strong Python/Django; JavaScript, CSS, and design sense
+  helpful. Understanding of implementing OAuth providers, e.g., having
+  built a prototype with [the Django OAuth
+  toolkit](https://django-oauth-toolkit.readthedocs.io/en/latest/)
+  would be great to demonstrate as part of an application. The [Zulip
+  integration writing guide](../documentation/integrations.md) and
+  [integration documentation](https://zulip.com/integrations/) are
+  useful materials for learning about how things currently work, and
+  [the integrations label on
+  GitHub](https://github.com/zulip/zulip/labels/area%3A%20integrations)
+  has a bunch of good starter issues to demonstrate your skills if
+  you're interested in this area.
+
+  Experts: Niloth, Lauryn Menard
+
+  [all-settings-issues]: https://github.com/zulip/zulip/issues?q=is%3Aopen+is%3Aissue+label%3A%22area%3A+settings+%28admin%2Forg%29%22%2C%22area%3A+settings+%28user%29%22%2C%22area%3A+stream+settings%22%2C%22area%3A+settings+UI%22
+
+- Work on Zulip's **development and testing infrastructure**. Zulip is a
+  project that takes great pride in building great tools for
+  development, but there's always more to do to make the experience
+  delightful. Significantly, about 10% of Zulip's open issues are
+  ideas for how to improve the project's contributor experience, and
+  are [in](https://github.com/zulip/zulip/labels/area%3A%20tooling)
+  [these](https://github.com/zulip/zulip/labels/area%3A%20testing-coverage)
+  [four](https://github.com/zulip/zulip/labels/area%3A%20testing-infrastructure)
+  [labels](https://github.com/zulip/zulip/labels/area%3A%20provision)
+  for tooling improvements.
+
+  This is a somewhat unusual project, in that it would likely consist of dozens
+  of small improvements to the overall codebase, but this sort of work has a
+  huge impact on the experience of other Zulip developers and thus the community
+  as a whole (project leader Tim Abbott spends more time on the development
+  experience than any other single area). 175 or 350 hours; difficult. **Skills
+  required**: Python, some DevOps, and a passion for checking your work
+  carefully. A strong applicant for this will have completed several projects in
+  these areas.
+
+  Expert: Tim Abbott
+
+### Terminal app
+
+Code: [The official multi-platform terminal app, written in
+Python](https://github.com/zulip/zulip-terminal).
+
+Experts: Neil Pilgrim, Aman Agrawal
+
+- **Contribute to Zulip Terminal, our terminal user interface (TUI) client**.
+  Zulip Terminal is out in beta, but there's still a lot to do for it to
+  approach parity with the web app - and Zulip keeps coming out with new features too!
+
+  Previous contributors have themed their projects according to a **cluster of
+  features** or **completing unfinished projects**, or some combination, much
+  like the first two bullets in the Full-stack project list.
+  Project complexity and potential scope can vary substantially, since the
+  required changes can involve touching different parts of the application
+  stack. For example, these may be purely improving multiple elements of the UI,
+  platform/terminal, or client-side model of the data available to a user - or
+  multiple of these in a full-stack style.
+
+  We would be happy to accept multiple strong students to work on this project.
+  175 or 350 hours; medium difficulty.
+  **Skills required**: Python 3 development skills, good communication and
+  project management skills. Reading and understanding complex code and tests,
+  and taking the initiative to propose clean refactoring and other solutions,
+  will be highly valuable.
+
+### Desktop app
+
+Code:
+[Our cross-platform desktop app, written in JavaScript on
+Electron](https://github.com/zulip/zulip-desktop).
+
+Expert: Anders Kaseorg
+
+- **Contribute to our [Electron-based desktop client
+  application](https://github.com/zulip/zulip-desktop)**. There's plenty of
+  feature/UI work to do, but focus areas for us include things to (1) improve
+  the release process for the app, using automated testing, TypeScript, etc.,
+  and (2) polishing the UI. Browse the open issues and get involved! 175 or 350
+  hours. This is a difficult project because it is important user-facing code
+  without good automated testing, so the bar for writing high quality,
+  reviewable PRs that convince others your work is correct is high. **Skills
+  required**: JavaScript, Electron; you can learn Electron as part of your
+  application.
+
+- **Prototype a next generation Zulip desktop app implemented using
+  the Tauri Rust-based framework**. Tauri is a promising new project
+  that we believe is likely a better technical direction for client
+  applications than Electron for desktop apps, for security and
+  resource consumption reasons. The goal of this project would be to
+  build a working prototype to evaluate to what extent Tauri is a
+  viable platform for us to migrate the Zulip desktop app to. 350
+  hours only; difficult. **Skills required**: Ability to learn
+  quickly. Experience with Rust and secure software design may be
+  helpful.
+
+### Mobile app
+
+Code: [Zulip's mobile app for Android and iOS, written in
+Flutter](https://github.com/zulip/zulip-flutter)
+
+Experts: Greg Price, Chris Bobbe, Rajesh Malviya
+
+- Work on the **Flutter-based Zulip client**.
+  Zulip's brand new Futter-based mobile app was [released last
+  summer][flutter-release-post].
+
+  This project will involve building features for the mobile app,
+  including code for UI, data structures, and interacting with the
+  Zulip server and the Android and/or iOS platforms.
+  For a sense of the features we're working on, see our
+  [project board][flutter-board];
+  the tasks we'll be working on during GSoC will come mostly from
+  the [M9: 2026 Q2][flutter-milestone-M9] and
+  [MXA: Later][flutter-milestone-MXA] milestones.
+  For some features, we [may find][flutter-upstream-summary]
+  ourselves [contributing changes][flutter-upstream-autocomplete]
+  upstream to the Flutter project itself. 175 or 350 hours; difficult.
+
+  **Skills required**: Ability to learn quickly, check your work
+  carefully, and communicate clearly and accurately. The code for
+  this project will be written primarily in Dart atop Flutter;
+  previous experience may be helpful, but you can learn both during
+  the contributions leading up to your application. Previous
+  experience with Android or iOS may also be helpful but is not
+  necessary.
+
+[flutter-release-post]: https://blog.zulip.com/2025/06/17/flutter-mobile-app-launched/
+[flutter-board]: https://github.com/orgs/zulip/projects/5/views/4
+[flutter-milestone-M9]: https://github.com/zulip/zulip-flutter/milestone/14
+[flutter-milestone-MXA]: https://github.com/zulip/zulip-flutter/milestone/4
+[flutter-upstream-summary]: https://chat.zulip.org/#narrow/channel/2-general/topic/Flutter/near/1524757
+[flutter-upstream-autocomplete]: https://github.com/flutter/flutter/pull/129802

docs/outreach/index.md

@@ -0,0 +1,13 @@
+# Outreach programs
+
+```{toctree}
+---
+maxdepth: 3
+---
+
+overview
+apply
+experience
+gsoc
+mentoring
+```

docs/outreach/mentoring.md

@@ -0,0 +1,122 @@
+# Mentoring
+
+Mentoring an outreach program participant is a great way to help bring up the
+next generation of open-source contributors and support the Zulip community. The
+experience of watching your mentee's skills develop can be truly rewarding, and
+we encourage you to give it a try.
+
+Signing up to mentor means committing to being reliable source of support on your
+mentee's open-source journey over the course of the program. By signing up,
+you're committing to dedicating roughly 3-5 hours a week to the program.
+
+Mentors generally have weekly calls with their mentees to answer any questions
+and help make sure that everything is on track. You are also expected to help
+program administrators keep an eye on your mentee's progress, and flag any
+concerns you might have.
+
+Mentors can refer to the excellent [GSoC Mentor
+Guide](https://google.github.io/gsocguides/mentor/) for detailed guidance,
+including GSoC's expectations, and best practices that can apply to any program.
+
+## Who can mentor
+
+In order to mentor with Zulip, you need to have spent significant time working
+on Zulip yourself. You need to be familiar with what it takes to get work
+integrated, so that you can help your mentee with this process. We encourage
+anyone who has successfully completed a mentorship program with Zulip as a
+participant to give mentorship a try!
+
+Note that you do _not_ need to have any expertise in the part of the
+codebase that your mentee is working in. We have seen many successful
+mentor-mentee relationships where the mentor was new to the parts of
+the codebase that were the focus of the project.
+
+You also do not need to be a currently active contributor to Zulip. Our
+expectations and patterns of getting work done have been quite consistent over
+time, and it should be easy for you to catch up on anything that's changed since
+you were actively involved.
+
+## Supporting your mentee
+
+At the start of the program, please read our [guide](experience.md) for program
+participants to understand Zulip's expectations for your mentee.
+
+What exactly you focus on in your mentorship will vary from week to week, and
+will depend on what your mentee needs. It might be any combination of:
+
+- Helping your mentee plan, chunk, and prioritize their work.
+
+- [Manually testing](../contributing/code-reviewing.md#manual-testing) UI
+  changes and helping find bugs or identify corner cases needing
+  further discussion.
+
+- Providing early feedback on visual and technical design questions.
+
+- Helping your mentee figure out how to test their changes.
+
+- Helping your mentee break their PRs into [coherent
+  commits](../contributing/commit-discipline.md).
+
+- Doing [code review](../contributing/code-reviewing.md) of your
+  mentee's work.
+
+- Helping with the technical design of projects and making sure
+  they're aware of useful and relevant reference materials.
+
+- Pair programming with your mentee to share useful tricks.
+
+- Emotional support when things feel like they aren't going well.
+
+It might seem challenging to review code if you're not an expert on
+your mentee’s focus area. Don't let yourself be intimidated!
+Reviewing changes to code your don't fully understand is a common
+experience in software development, and you can still provide valuable
+feedback.
+
+If you don’t understand something about the changes being made, there
+is a good chance others would also find it confusing. Asking your
+mentee for an explanation will itself be valuable feedback on what
+parts of the PR need to be commented or rewritten in a more clear way.
+
+### Establishing communication patterns
+
+Over the course of the program, you will interact with your mentee both
+synchronously (e.g., on calls, pair programming, and/or via chat in the
+development community), and asynchronously (in the development community and on
+GitHub).
+
+It's important to ensure that there are regular opportunities for synchronous
+interactions, which are the best way to resolve some types of questions and
+concerns, and will help your mentee feel supported.
+
+Please schedule at least one synchronous interaction opportunity with your
+mentee per week. A weekly call is highly recommended, as calls can be especially
+helpful for getting a feel for how your mentee is doing, and lowering the bar
+for asking questions and sharing concerns. A good pattern might be a weekly
+call, plus 1-2 other regular time slots when you and your mentee check in in the
+development community.
+
+## Managing challenges
+
+We rely on you to proactively flag your concerns to Zulip's program
+administrators as early as possible. Situations you should bring up include:
+
+- Lack of communication from your mentee, e.g., missing a scheduled call,
+  missing multiple [check-ins](./experience.md#communication-and-check-ins), lack
+  of response to PR reviews, etc.
+
+- If your mentee's rate of progress on their projects is not commensurate with
+  the hours of work they are supposed to be dedicating to the project.
+
+- If you are not seeing improvement in response to the feedback you give.
+
+- If your mentee seems to be struggling, deeply frustrated, or otherwise is not
+  having a good experience with the program.
+
+- Any significant questions or concerns raised by your mentee that you cannot
+  resolve, which for some reason your mentee cannot raise directly.
+
+- If it turns out that you cannot dedicate sufficient time to support your mentee
+  for all or part of the remaining duration of the program. As long as Zulip's
+  program administrators are informed, we can make sure someone else covers for
+  you.

docs/outreach/overview.md

@@ -0,0 +1,87 @@
+# Outreach programs overview
+
+This page describes what it's like to participate in a Zulip outreach program,
+such as [Google Summer of Code (GSoC)](https://summerofcode.withgoogle.com/) or
+[Outreachy](https://www.outreachy.org/).
+
+## About Zulip
+
+[Zulip](https://zulip.com) is the only modern team chat app that is ideal for both
+live and asynchronous conversations. Zulip has a web app, a cross-platform
+mobile app for iOS and Android, cross-platform desktop and terminal apps, and
+over 100 native integrations. The entire Zulip codebase is 100% open source.
+
+Zulip has been gaining in popularity since it was [released as open source
+software][oss-release] in late 2015, with code contributions from [over 1000
+people](https://zulip.com/team/) from all around the world. Thousands of people
+use Zulip every day, and your work on Zulip will have meaningful impact
+on their experience.
+
+[oss-release]: https://blogs.dropbox.com/tech/2015/09/open-sourcing-zulip-a-dropbox-hack-week-project/
+
+As an organization, we value engaged, responsive mentorship and making sure our
+product quality is extremely high. You can expect to receive disciplined code
+reviews by highly experienced engineers. Since Zulip is a team chat product,
+your internship experience with the Zulip project will be highly interactive.
+
+> _“The experience of working with Zulip for the summer was really phenomenal and
+> taught me a lot about software development and working with a community. Zulip
+> has one of the best open source communities out there who are super friendly
+> and welcoming. You learn a lot just by watching others work and talk.”_ – Sai
+> Rohitth Chiluka, Zulip GSoC 2021 participant
+
+As part of our commitment to mentorship, Zulip has over 185,000 words of
+[documentation for
+developers](../index.md#zulip-documentation-overview), much of it
+designed to explain not just how Zulip works, but why Zulip works the way that
+it does. To learn more about our mission and values, check out [this blog
+post](https://blog.zulip.com/2021/04/28/why-zulip-is-on-github-sponsors/)!
+
+## Outreach program experience
+
+Zulip has been a [GSoC](https://summerofcode.withgoogle.com/) mentoring
+organization since 2016, and we accept 10-20 GSoC participants each summer. We
+have also mentored several interns through the
+[Outreachy](https://www.outreachy.org/) program, and hundreds of Google Code-In
+participants.
+
+Zulip operates under a **group mentorship** model. While you will have an
+assigned mentor, you will also get lots of feedback from other members of the
+[Zulip development community](https://zulip.com/development-community/) by
+posting your questions and ideas in public channels. We encourage outreach
+program participants to help each other out as well!
+
+Program participants work on a variety of issues in their areas of interest,
+from major features to small bugs. You will see your work integrated into Zulip
+throughout the program, and even experience the impact of the changes yourself
+in the [development community chat](https://zulip.com/development-community/).
+
+Many program participants stay involved with the project past the
+official end of the program. A number of folks who get started as participants
+go on to mentor the next cohort, and several have joined Zulip's team of core
+maintainers.
+
+To learn more about the experience of doing an outreach program with Zulip:
+
+- Check out our blog posts about Zulip's
+  [2025](https://blog.zulip.com/2025/12/02/google-summer-of-code-2025/),
+  [2024](https://blog.zulip.com/2024/10/09/google-summer-of-code-2024/),
+  [2023](https://blog.zulip.com/2024/01/24/google-summer-of-code-2023/),
+  [2022](https://blog.zulip.com/2022/11/02/google-summer-of-code-2022/), and
+  [2021](https://blog.zulip.com/2021/09/30/google-summer-of-code-2021/) Google
+  Summer of Code programs.
+
+- Watch our [3-minute video](https://youtu.be/h4s-JUei3Z0) about what it's like
+  to do GSoC with Zulip.
+
+- Watch our [Having a Great GSoC](https://youtu.be/dPUAEZVBrJg) Google Summer of
+  Code Community Talk.
+
+- Read our [guide](experience.md) to having an amazing experience with Zulip's
+  outreach programs.
+
+> _“It has been the best summer I've ever had! I'm thankful to my mentors, my
+> peers, Zulip, and Google for providing me an opportunity of getting involved
+> in the community! You have helped and supported me to become a better software
+> developer and a passionate open-source contributor.”_ – Sarthak Garg, Zulip
+> GSoC 2021 participant