Work Product Submission Guidelines

Stay organized with collections Save and categorize content based on your preferences.

As part of the final evaluation, all participating contributors must provide a link to the work they have done for the program. Failure to do so properly may result in failing the program. There are several different ways to do this, so please read this document carefully.

These links will be published on the public archive of GSoC projects. They help demonstrate the work that was done during the program. They are also a great way for you to refer back to your work for future employers.

In brief: The target of the link should contain a short description of what work was done, what code got merged, what code didn't get merged, and what's left to do. The best examples of this we saw in past years were "final reports" that made it easy to find the code, summarized the current state of the project, and enumerated challenges and learnings.

To look at examples, start at the 2021 Project List, pick projects at random, and then click VIEW CODE.

NOTE TO CONTRIBUTOR: Once you submit your final work submission, you can edit it until your final work submission deadline.

You should share your link with your mentor BEFORE submitting your evaluation to make sure it meets their expectations.

Requirements

  • It must be easy to identify the work you have done. (i.e. the changes you made or new code.)
    • When someone goes to the provided URL it should be clear what work you did without requiring them to do significant additional digging.
  • It should be in a stable location. The URL cannot be changed after submission.
  • Someone else should be able to use the content at (or referenced from) the target of the link to extend your work.
    • If your work is 100% complete, they should be able to use it.
    • If your work is not 100% complete, it should be clear what's left to do.

Good Examples

You don't have to do all (or any) of these things, but these are some ways you can satisfy the requirements.

  • Create a blog post or web page or public GitHub gist that describes the work you've done and links to the commits you've made and repositories you've worked on. If there is still work to be done on the project, include that too. You can also share highlights or challenging pieces.
    • ❗ This is the best option because it allows you to easily include a lot of information. This is good because it will clearly show what work you did, as well as make it easy for others to use and understand your code.
  • If using GitHub, and all of your work is covered by a single pull request, you can use that link.
    • Ensure that the pull request description is detailed. (See suggestions for blog post content above.)
    • Make sure the description clearly notes that this is for Google Summer of Code.
    • If the pull request is going to have more work done after GSoC is over, make sure the last GSoC commit is noted.
    • ❗ This example has the benefit of having the change log, a list of commits, and the review comments all in one place.
  • If your GitHub repository is single purpose for GSoC, add a README.md with more detail.
  • Send an email to the publicly archived developer mailing list, with the above, and link to that too.
  • Create a public folder in Google Drive and include all of the patches you've created.
  • Create a public spreadsheet with Google Sheets and list all your commits.
  • Link to a single bug that clearly contains references to the work and anything else appropriate. It should track all the work you've done. Make sure it lists all the commits or is otherwise easy to find them.
  • Link to a unified or context diff of your changes. Be sure to include a header that notes what project it's for and who you are, so it's useful to others.

Bad Examples

Don't do these things.

  • Link to a tarball/zipfile containing the entire project's source code or your working directory.
  • Link to the top of the project's primary source repository.
  • Link to your clone of the project's source repository.
    • This makes it hard to see what your changes are because your work is mixed with others.
  • Link to your GSoC project page.
    • We already know what that is. (i.e. https://summerofcode.withgoogle.com/projects/#1234567890)

Mentors

Please help your contributor do a proper code submission. It's important to do this before the final work submission period.

Check that…

  • The submission meets the requirements above.
  • The code compiles.
  • There's documentation of what and why.

The idea of GSoC isn't that contributors churn out code -- it's important that the code be potentially useful to the hosting Open Source project.