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.