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.

2. 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 and self-review your work before submitting it for review.

3. 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, and explain your decisions clearly in your commit messages and on your pull requests. Communicate accurately and succinctly -- no AI slop!

4. 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

• 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 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:

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 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 or #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.