Requirements for Passing

Formal requirements

Each team – contributor and mentor (both are responsible) – ensures that the following formal milestones are reached.

• Blog posts: The contributor must complete 3 mandatory blog posts, Introductory , Mid-term and Final. Each blog post must include a timely review by at least one of the mentors. The blog posts will constitute the overview documentation and links to the posts must be added to the project information page.
• Live project demonstration, alternatively screen casts, which include thorough documentation.
  • mid-term (must not at all be complete – go for quick break throughs!).
  • at the end of GSoC.
• Weekly reports (see below) are submitted on time and checked by a mentor within one day.
• Technical documentation in a step-by-step manner that allows anyone to pick up the project, meaning they can start from scratch with an empty workspace and quickly reach the latest development. This includes a list of user stories or tasks that are not completed, but would be the next steps.

Project requirements

In addition, of course, the contributor must work on the agreed-upon tasks (which can be adjusted in an agile manner if necessary) for the agreed-upon amount of time. Both mentors and contributors need to communicate in a timely manner and try to create a good working environment to deliver good results on the project.

Software Development

• Scrum rocks!
• On GitHub, we recommend following the fork & pull development model, see https://help.github.com/articles/using-pull-requests.

Project Documentation

You and your mentor are free to choose where you want to document your project progress. For example, you could write your project blog on your own existing blog. Or you can use GitHub’s wiki feature.

In addition, each project must have one “project information page”:

Project Information Page

• Each project must have a single project information page based on a shared Google Document
• a short description of the project,
• a short description of the contributor,
• a list of references to any internal or external pages about the project, such as blogs, developer or user documentation,
• a summary of the project and its status at the end of the project, and
  links to the source code and links to relevant documentation (could be within the GitHub repo).

Weekly Reports

• Weekly reports are due each Monday evening UTC and must be added to the project’s Taiga.io board.
• Follow the mandatory structure: “1. Status”, “2. Problems”, and “3. Tasks for the next week”. Do not point to local URLs (such as http://192.168.42.17/my/service?request=stuff), but rather deploy a test software to the demo server and reference that or include links to GitHub issues detailing the problem (possibly with screenshots – avoid attaching files to your email).
• Status
  • Start the report by relating to the problems of the last week.
  • Be concise, but specific enough to justify the amount of hours/week agreed upon and that you have put into that week.
  • Please keep this short and refer to longer issue descriptions on GitHub if you have to report on major issues.
• Problems
  • These should be open issues that prevented you from completing a planned task. If you had a problem and solved it, put it in the status section. If you have an idea for solving an open issue, make it a to-do for the coming week.
• Next Tasks
  • Keep them in a list and divide them into independent items. This way they are more easy to track.
  • Be specific: “Start implementing X” is not specific enough.
  • Link to issues on GitHub
• Avoid spoken language.
• Add hyperlinks when you say that you “looked at libraries x (link), thing y (link), and other project z (link)”. This allows you to be specific without being too extensive.
• Include your results in the report, not just what you did. “I looked at library x” is useless information, but “I tested library x and found that it does not provide features f and g that we need, so I continued to look for a suitable alternative” is useful.

Blog Posts

General information

• Blog posts are due on specific dates, with a full draft for mentor review due a week earlier.
• Get yourself acquainted with styles and potential contents of the student blog posts by looking at previous ones: http://blog.52north.org/category/gsoc/
• Some examples of nice introductory blog posts:
  • http://blog.52north.org/2013/06/20/trajectory-analysis-in-r/
  • http://blog.52north.org/2012/05/30/dynamic-output-formats-for-the-sensor-observation-service/
  • http://blog.52north.org/2014/05/30/envirocar-ux-design/
• Examples of mid-term blog posts:
  • http://blog.52north.org/2013/08/02/opensensorsearch-midterm-blog/
  • http://blog.52north.org/2014/06/26/sensor-data-access-for-rasdaman-mid-term-blog-post/
• Examples of final blog posts:
  • http://blog.52north.org/2012/08/23/demonstrating-exchangeable-encodings-for-sos-a-quantum-leap-for-me/
  • http://blog.52north.org/2012/09/19/on-demand-transformation-of-openstreetmap-data-into-common-gis-formats/
  • http://blog.52north.org/2014/08/17/access-control-ui-for-sos-servers-final-blog-post/

Writing

• Write your draft as a Google Doc (or similar)
• Start and end with a simple paragraph that gives the big picture, without technical details. The overall message must be understandable to the layperson!
• The blog post does not replace the weekly report and should not be as technical, but should give everyone (imagine explaining things to a relative who is not in computer science!) a good overview of planned or achieved goals.
• Use links extensively to point to other pages (GitHub, Wikipedia) with the details – try to keep the post concise and compelling.
• The correct name is “52°North“, not “52N”, “52North”, or “52 North”, even if you see these forms on other pages or use them in spoken language.
• At the end of the post, make a list of tags for the most important keywords in your post.
• Add images, e.g. architecture diagrams, use case snapshots, make screenshots of old versions or inspiring other user interfaces – anything that makes sense and makes the post more visual is allowed!
• Include an image caption and reference the image from the text (“… as shown in the figure…”).
• Send images as files to the WordPress editor Ann Hitchcock.

Review/Publishing

• Inform your mentor that they can review your post (send a link to your draft).
• Once you have revised your post according to your mentor’s comments, notify WordPress editor Ann Hitchcock for the final review.
• The final post will be published by the WordPress editor (Ann Hitchcock)

Dissemination

• Distribute the automatically created message on your social media channels, think about who you could share this with directly (your teachers showing them what you do, related projects, other developers…) – use the blogpost to create a community around your project!
• Re-post the entry on your development blog.

Your end of the bargain

• Follow our internal Guidelines
• Active communication with mentors and within the community (Slack, through GitHub issues and discussions, or direct email communication with mentors).
• Full-time work on an interesting software development project.
• Weekly status reports.
• Three blog posts about your GSoC project on 52°North’s blog.
• Have fun coding!

Our end of the bargain

• Mentors and org admins communicate with you respectfully and focus on your learning experience.
• Your mentors respond in a timely manner.
• Org admins provide support for organizational issues and when a mentor is unable to fulfill their responsibilities.