By signing up, you agree to the Code of Conduct, which applies to all online and in-person spaces managed by the Public Lab community and non-profit.

As an open source community, we believe in open licensing of content so that other members of the community can leverage your work legally -- with attribution, of course. By joining the Public Lab site, you agree to release the content you post here under a Creative Commons Attribution Sharealike license, and the hardware designs you post under the CERN Open Hardware License 1.1 (full text). This has the added benefit that others must share their improvements in turn with you.

Wrapping up Outreachy and GSoC 2019

Summer of Code and Outreachy wrap up shortly -- in just a few days. As we discussed on this week's Code Open Call, folks are starting to publish their final work, get some huge projects completed, and to write documentation!

In final evals, we'll be looking for much the same stuff as in Evals 1 and 2, but with more of an eye towards how you leave your work at the end. Not only how well you did at completing your project tasks, but whether you're leaving your work in an understandable state for others as you finish up!

Turn your remaining work into well-documented onramps for new contributors

To students who are approaching the end of their projects, an important step is re-assessing what's left, and what they can finish up in the remaining time. But rather than considering any unfinished pieces "missing", it's great to take them as an opportunity to invite others into your projects, by turning them into well-documented issues on your project repositories.

If you offer enough context, you should be able to recruit people to take up the remaining tasks once the summer ends, and whether or not you continue work afterwards, folks will be able to carry your work forward. This may mean writing a first-timers-only issue, for example, to welcome a new coder into the project.

Mentors: I think it's great to encourage students to document their work (and what's left to do) as issues that are up for grabs. It's better for morale to plan ahead for other people to pick up where you left off, and to think about your project living on, than to focus on asking them what they didn't do! And it's better for the project overall anyways!

Write issues for yourself, but as if written for others

Actually, although we encourage this throughout the year, now at the end of the summer, we really mean Write issues for others, haha -- because you'll be returning to school or other projects, and you really want your work to live on even if you're not available!

Finally, a few other tips:

READMEs are a great place for any final documentation - showing how to use your project, either for developers or for users.

If there are critical tasks or milestones, prioritize these of course!

If you have "nice-to-have" features you think would be great, but aren't critical, turn them into well-documented issues to circle back to later. Maybe someone else will pick them up as well! Leave thorough notes to lines of code etc.

A wrap-up post like this one on Leaflet Environmental Layers or this one on Image Sequencer is a great way to provide a walkthrough of your work to others, and helps mentors do a good evaluation. It's OK if they're a bit redundant with a README or with your issues - they serve a different purpose!

Finally, take a deep breath -- it's been a lot of work this summer -- and try writing an issue about your long-term goals for your project. Where do you see it in a year, or five years? What's the long-term trajectory? This is a nice way to round out your work!

Thanks to everyone for a tremendous summer. You've done some epic work, and you're almost there! Good luck in these final few days!