Student

We love working with students and having them solve fun and challenging problems. For many, it’s their first time contributing to an open source project. We’ve had students from Google Summer of Code (GSoC), Undergraduate Capstone Open Source Projects (UCOSP), and Fedora Summer Coding.

Getting Started

Step 7: Alter sharing settings for your proposal

1. Create a GitHub account
2. Introduce yourself on our mailing list
   • Include your GitHub username so we can add you to the Freeseer organization
3. Get familiar with IRC and start hanging out in #freeseer on Freenode
4. Fork & clone Freeseer
5. Get Freeseer up and running, play around with it, look at the source code
6. Read over the assessment document
7. Copy the project proposal document to your Google Drive
   • File → Make a copy
   • Change the sharing settings so anyone with the link can view and comment, then share the link with us
   • Replace the highlighted sections with your own content
8. Bookmark the style guides that we use: PEP 8 and Google’s Python Style Guide
   • Reference them when writing code
9. Sign up for a blogging platform (or use your own website)
   • Share the URL on the mailing list
10. Start thinking of ways how you can improve Freeseer!

Tip

As a student, you can apply for a free micro account at github.com/edu and get 5 private repositories!

What Happens at the Sprint

Depending on which program you’re participating in, you may have to attend a sprint with your new teammates. Use the sprint to ask questions, help your teammates, brainstorm what to work on, get started on your project proposal, open a pull request, make new friends, and generally have a good time.

We’ll also decide on a time for our weekly G+ hangouts, which are done scrum style. Each team member will briefly update the others with what they’ve accomplished since the last meeting, what they will be working on next, and any stumbling blocks they ran into. Any detailed discussion should happen outside the meeting.

Deciding What To Work On

We let students choose their projects. We’ll suggest a couple of project ideas. You can also look through our open issues or come up with your own idea and open an issue for it.

You should have a copy of the project proposal document on your Google Drive. Feel free to add or remove sections that you think are relevant or irrelevant to your project. It also includes a timeline to help schedule your work. There are no set work hours – meet your deadlines and you’ll be fine. Decide with your professor and/or project mentor when your exact end date will be.

Done is better than perfect when it comes to your proposal. Don’t spend too much (or too little) time on it. Iterate on it quickly and often, you don’t need a highly polished document on your first try.

When you finish your first draft of the proposal, notify everyone on the mailing list and include a link so they can view it on Google Drive. We’ll give you feedback so you can make any changes if necessary.

Note

You can add or update translations in addition to your main project.

Tip

Start working on your project while your proposal is still in progress.

Communicate

One of the biggest indicators of success is staying in touch with us. If we don’t know what’s happening on your side, we can’t help you. If we don’t hear from you, we usually won’t go looking after you.

Make an effort to hang out in the IRC channel daily (lurking is fine). Participate in the mandatory weekly status update meetings. Be responsive on GitHub and the mailing list.

You’ll also be required to write weekly blog posts about your progress. These will cover the updates you’ll discuss in the weekly meetings, but you can go into more detail on your blog. You may write your blog posts at fosslc.org if you don’t want to use a personal blog. Remember to tell us on the mailing list where we can read your latest blog post.

Your updates in the weekly meetings and blog posts shouldn’t come as a big surprise to us. If that’s the case, you should probably be communicating more often.

See also

How to succeed or fail at Google Summer of Code

Expectations

• Be available for others to contact you
• Keep up to the date with the mailing list
• Communicate often, at the very least lurk on IRC
• Be a team player, not just a teammate
• Don’t be afraid to ask for help
• Treat your project as a scientific experiment; a failed outcome is not a failed project if well documented
• 8-10 hours of work per week, as much as any other course