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. You want
people to be able to quickly understand what your project goals were, what you
accomplished, where your code is, and any potential next steps.
The best examples we've seen in past years look like a "final report"
that contains:
- A short description of the goals of the project.
- What you did.
- The current state.
- What's left to do.
- What code got merged (or not) upstream.
- Any challenges or important things you learned during the project.
To look at examples, start at the
2022 Project List,
pick projects at random, and then click VIEW CODE. Please note many of these
projects didn't follow our suggestions, which means only hurts them in being
able to show off their work.
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. (Too many people have done this is the past, it's
not helpful for people wanting to understand more about what you did.)
- 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.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2024-07-23 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-07-23 UTC."],[[["\u003cp\u003eAll Google Summer of Code contributors must submit a link to their work for final evaluation, or they risk failing the program.\u003c/p\u003e\n"],["\u003cp\u003eThe submitted link should clearly showcase the project's goals, accomplishments, current state, remaining tasks, and code contributions in an easily accessible format, like a final report or a detailed blog post.\u003c/p\u003e\n"],["\u003cp\u003eThe work should be in a stable, publicly accessible location where others can review, understand, and potentially build upon it.\u003c/p\u003e\n"],["\u003cp\u003eContributors should discuss their work submission link with their mentor before the final evaluation to ensure it meets expectations and program requirements.\u003c/p\u003e\n"],["\u003cp\u003eAvoid submitting links to general repositories, personal clones, or compressed archives; instead, focus on providing direct access to specific changes and clear documentation.\u003c/p\u003e\n"]]],["Contributors must submit a link to their program work for final evaluation; failure to do so may result in failing the program. The link should clearly showcase their work, including project goals, accomplishments, current state, and future steps. Accepted formats include blog posts, detailed pull requests, or public documents with comprehensive details. The link must be stable and enable others to understand and extend the work. Submissions must be shared with mentors beforehand for review, which should include checking it compiles and contains proper documentation.\n"],null,["# Work Product Submission Guidelines\n\nAs part of the final evaluation, all participating contributors must provide a link\nto the work they have done for the program. **Failure to do so properly may\nresult in failing the program**. There are several different ways to do this, so\nplease read this document carefully.\n\nThese links will be published on the\n[public archive of GSoC projects](https://summerofcode.withgoogle.com/archive).\nThey help demonstrate the work that was done during the program. They are also a\ngreat way for you to refer back to your work for future employers. You want\npeople to be able to quickly understand what your project goals were, what you\naccomplished, where your code is, and any potential next steps.\n\nThe best examples we've seen in past years look like a \"final report\"\nthat contains:\n\n- A short description of the goals of the project.\n- What you did.\n- The current state.\n- What's left to do.\n- What code got merged (or not) upstream.\n- Any challenges or important things you learned during the project.\n\nTo look at examples, start at the\n[2022 Project List](https://summerofcode.withgoogle.com/archive/2022/projects),\npick projects at random, and then click VIEW CODE. Please note many of these\nprojects didn't follow our suggestions, which means only hurts them in being\nable to show off their work. \n**NOTE TO CONTRIBUTOR:** Once you submit your final work submission, you\ncan edit it until your final work submission deadline.\n\nYou should share your link with your mentor BEFORE submitting your evaluation\nto make sure it meets their expectations.\n\nRequirements\n------------\n\n- It must be easy to identify the work you have done. (i.e. the changes you made or new code.)\n - When someone goes to the provided URL it should be clear what work you did without requiring them to do significant additional digging.\n- It should be in a stable location. The URL cannot be changed after submission.\n- Someone else should be able to use the content at (or referenced from) the target of the link to extend your work.\n - If your work is 100% complete, they should be able to use it.\n - If your work is not 100% complete, it should be clear what's left to do.\n\nGood Examples\n-------------\n\nYou don't have to do all (or any) of these things, but these are some ways you\ncan satisfy the requirements.\n\n- 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.\n - ❗ 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.\n- If using GitHub, and all of your work is covered by a single pull request, you can use that link.\n - Ensure that the pull request description is detailed. (See suggestions for blog post content above.)\n - Make sure the description clearly notes that this is for Google Summer of Code.\n - If the pull request is going to have more work done after GSoC is over, make sure the last GSoC commit is noted.\n - ❗ This example has the benefit of having the change log, a list of commits, and the review comments all in one place.\n- If your GitHub repository is single purpose for GSoC, add a README.md with more detail.\n- Send an email to the publicly archived developer mailing list, with the above, and link to that too.\n- Create a [public folder](https://support.google.com/drive/answer/2494822?ref_topic=7000947) in Google Drive and include all of the patches you've created.\n- Create a public spreadsheet with Google Sheets and list all your commits.\n- 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.\n- 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.\n\nBad Examples\n------------\n\nDon't do these things.\n\n- Link to a tarball/zipfile containing the entire project's source code or your working directory. (Too many people have done this is the past, it's not helpful for people wanting to understand more about what *you* did.)\n- Link to the top of the project's primary source repository.\n - I.e. if you're working on cpython, this link is not useful: \u003chttps://github.com/python/cpython\u003e\n- Link to your clone of the project's source repository.\n - This makes it hard to see what your changes are because your work is mixed with others.\n- Link to your GSoC project page.\n - We already know what that is. (i.e. `https://summerofcode.withgoogle.com/projects/#1234567890`)\n\nMentors\n-------\n\nPlease help your contributor do a proper code submission. It's important to do\nthis *before* the final work submission period.\n\nCheck that...\n\n- The submission meets the requirements above.\n- The code compiles.\n- There's documentation of what and why.\n\nThe idea of GSoC isn't that contributors churn out code -- it's important that the\ncode be potentially useful to the hosting Open Source project."]]
