The process of defining ideal GSoC projects is not just a “summertime” activity. Such projects are generally useful to the overall open source software development effort. The same qualities that go into a good GSoC project go into entry projects for new developers and even projects that help recruit new developers.
Putting together a well-defined GSoC project also forces you to think about your project from a new point of view. This is a valuable exercise for defining the current scope of, and potential new avenues for, your work. In other words, it can be much more than just getting help with your existing workload.
Your goal for GSoC is to generate a list of project ideas that capture the development needs of your organization, attract the interest of potential GSoC contributors, and help you get things done. This is often done as a community effort that involves as many potential mentors as possible, helps create buy-in from these mentors, and gives a broad range of perspectives on organizational needs. Creating your list of project ideas should also be part of an ongoing long-term strategy, rather than a rushed act to meet the application deadline. Many organizations maintain such project lists year-round.
There is an art to writing a project description that leads to good applications. It is tempting to write a detailed project plan for the GSoC contributor to follow. However, GSoC contributors tend to echo such plans in their applications, making it difficult to evaluate their quality. It is better to briefly describe a general high-level need, and the motivation behind that need. Keeping the scope modest helps encourage more applicants, while adding a “stretch” goal to the project description may encourage stronger GSoC contributors to take on the challenge of meeting it.
One strategy is to leave an opening for GSoC contributors to propose their own original project ideas. Some great ideas can come out of this process. Emphasize that the GSoC contributors proposing something original must engage with the community strongly before or during the application period to get feedback and guidance to improve the proposal.
Writing a Good Ideas List
Note that the quality of the project descriptions on an organization’s “Ideas list” is the main criterion for the organization’s admittance into GSoC. It is worth spending some extra effort to ensure that the projects you propose are worthy of the GSoC banner.
When Google Administrators review the hundreds of organization applications the primary thing they look at is the quality of the Ideas list. An Ideas list should follow these guidelines:
- Each project on the Ideas list should include: a) a project title/description b) more detailed description of the project (2-5 sentences) c) expected outcomes d) skills required/preferred e) possible mentors f) expected size of project (90, 175 or 350 hour – yes, 3 options starting in 2023). And if possible, an easy, medium or hard rating of each project. This helps the more inexperience folks not get overwhelmed and they can focus on reviewing easy project ideas.
- Projects should take ~90 hour, ~175 hours or ~350 hours for GSoC contributors to complete. We understand some GSoC contributors will take less time (if they have more knowledge of the topic or codebase) while others could spend more time. It is also possible that a given project idea could be 90 hours, 175 hours or 350 hours depending on the scope of the idea. If the GSoC contributor proposes to do a smaller scope of the idea then it might be a 175 hr project versus if they propose doing more work with their proposal it could be a 350 hour project.
- Have multiple ideas. Even if you are a new organization and only want one or two GSoC contributors showing that you have multiple ideas (a bare minimum of 4 solid ideas) is vital. And for an organization hoping for 4 or more GSoC contributors you should have at least 8-10 ideas and having them categorized is a nice touch if you have subcategories of topics within your project.
- Make it easy for Administrators to find your Ideas list. When reviewing many hundreds of organizations Program Admins can only spend a certain amount of time looking for your Ideas list. Many organizations are rejected because Program Admins couldn’t find the actual Ideas list because the URL the org gave had a bunch of other unrelated information on it and wasn’t clear where to find the actual Ideas list.
- Make sure to update your Project Ideas. Even if you plan to use some of the ideas that weren’t chosen from a previous year at least put effort into changing the page to say 20XX Ideas list. It is not encouraging for Program Admins to see an outdated list. It also makes it seem like your project might be stale as you don’t have new ideas for GSoC contributors to work on if it still shows ideas from the previous year or even two years before and is marked as such.
- Never link to just a bug tracker. This is almost always an automatic rejection. Yes, really. When Admins open the issue tracker if there is an expanded description of the project with the items listed in #1 above that is acceptable. If an org can’t take the time to create a document or a page with their Ideas List fleshed out then why would Google expect they would be willing to mentor GSoC contributors for 3+ hours a week for the next 3+ months?
- Don’t be vague about the ideas. Be sure to write a few sentences describing what you need accomplished and not just an overall theoretical version of what you might want.
- Be sure the URL you link to for your Ideas list works. Have someone else test it as well before you submit your application. Sometimes people don’t have permissions set correctly or paste an incorrect URL which will also mean a rejection.
There are many ways to define a good GSoC project–probably as many ways as there are GSoC contributors-mentor pairings. Here are just a few:
Low-hanging fruit: These projects require minimal familiarity with the codebase and basic technical knowledge. They are relatively short, with clear goals.
Risky/Exploratory: These projects push the scope boundaries of your development effort. They might require expertise in an area not covered by your current development team. They might take advantage of a new technology. There is a reasonable chance that the project might be less successful, but the potential rewards make it worth the attempt.
Fun/Peripheral: These projects might not be related to the current core development focus, but create new innovations and new perspective for your project.
Core development: These projects derive from the ongoing work from the core of your development team. The list of features and bugs is never-ending, and help is always welcome.
Infrastructure/Automation: These projects are the code that your organization uses to get its development work done; for example, projects that improve the automation of releases, regression tests and automated builds. This is a category in which a GSoC contributor can be really helpful, doing work that the development team has been putting off while they focus on core development.
The projects you propose will define the tone and scope of your organization’s participation in GSoC. It is a key part of your organization’s application. Further, it may be the first impression made on a potential applicant.
Pro Tip: Maintain an “ideas page” with a running list of entry projects year-round. This can benefit your development effort throughout the year. It can also make your organization’s GSoC application easier to put together the following summer.
Don’t Be That Person: Don’t propose projects that neither you nor anyone else wants to mentor.