Differences between revisions 12 and 15 (spanning 3 versions)
Revision 12 as of 2015-03-03 07:30:26
Size: 11423
Editor: TerriOda
Comment:
Revision 15 as of 2016-06-05 22:01:24
Size: 14445
Editor: TerriOda
Comment:
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
 1. '''Choose an organization to work with.''' Python has a lot of sub-projects (over 20 in 2014!), so this can be hard. See "[[https://wiki.python.org/moin/SummerOfCode/FAQ#How_do_I_choose_a_project_or_a_sub-org.3F|How do I choose a project or a sub-org?]]" if you need help.
 2. '''Start communicating with the developers.''' Join the mailing list, IRC channel, or any other communication channels the developers use. Listen, get to know the people involved, and ask questions.
 1. '''Choose an organization to work with.''' Python has a lot of sub-projects (over 20 in 2014!), so this can be hard.  You ''do'' need to choose a sub-org if you're working with Python; projects without a sub-org are usually rejected at selection time. See "[[https://wiki.python.org/moin/SummerOfCode/FAQ#How_do_I_choose_a_project_or_a_sub-org.3F|How do I choose a project or a sub-org?]]" if you need help. 
  * Hint: Don't choose "Core python" as your default if you don't know what to do: our other sub orgs usually have a greater range of projects and mentors available!
 
2. '''Set up your own development environment.''' Document what you do so you can remember it later, and so you can help others if they get stuck! And if you get stuck, don't be afraid to ask for help.
 3
. '''Start communicating with the developers.''' Join the mailing list, IRC channel, or any other communication channels the developers use. Listen, get to know the people involved, and ask questions.
  * In almost all cases, you should communicate in public rather than in private. GSoC is a busy time for many developers and many beginner questions get asked repeatedly. Help keep your devs less stressed out by reading what they've written already and making it easier for them to have a record of the things they've answered.
Line 11: Line 14:
 3. '''Set up your own development environment.'''
Line 14: Line 16:
  * Having trouble figuring out which bugs are beginner-friendly? Send an email to the project mailing list saying something like "Hi, I'm a student developer interested in getting some open source experience and I was wondering if anyone could suggest some bugs that are suitable for a beginner in this project?"   * Having trouble figuring out which bugs are beginner-friendly? Check and see if anyone else has asked recently (usually during GSoC a *lot* of people are looking for easy bugs) and read the answer they got, but if no one's asked in a month or so, you can ask the developers via public mailing list or IRC. (Hint: don't ask privately; this is a question that other people want to know the answer to)
Line 51: Line 53:
 4. '''If you're really having trouble getting in touch with your mentors, talk to the Python org admins by emailing soc2015-general-owner@python.org''' The Python org admins should have contact info for mentors with each project and can help connect you. (Note: please don't complain that you can't get in touch with us on the general google lists or #gsoc. They're just going to redirect you to TerriOda anyhow!)  4. '''If you're really having trouble getting in touch with your mentors, talk to the Python org admins by emailing gsoc-admins(at)python.org''' The Python org admins should have contact info for mentors with each project and can help connect you. (Note: please don't complain that you can't get in touch with us on the general google lists or #gsoc. They're just going to redirect you to TerriOda anyhow!)
Line 84: Line 86:

= What does it take to be a mentor? =


 * We expect around a 0-10hr/week commitment, which sounds scary, but it's not actually that variable. You usually spend up to lots of time for the first few weeks, where you're fleshing out your ideas page, discussing projects with many students, and selecting students from their proposals. After students are selected, it becomes more like a 1hr commitment per week for a weekly meeting, and maybe a few more hours here and there for code review or questions. (That depends on your studen: experienced students may need very little supervision, inexperienced students may need more. It also depends on you: You and your co-mentor(s) select the student and project you mentor, so you can choose according to the time commitment you have.)
 * We want at least two mentors per projects, so hopefully no one ever gets overwhelmed and feels like they're always on call (Google does ask that we try to answer questions within 48h so students can't get stuck for too long), and no one mentor has to know all the answers.
 * I recommend at least one mentor has a weekly 1hr meeting with the student so they get to know each other, keep everyone on track, and give a chance to talk about other stuff (lots of students have questions about jobs, courses, architecture, open source, etc. and it's nice to have someone to talk to). Some weeks this meeting may be the only mentoring time needed.
 * Mentors don't have to be the Best At Everything. A lot of what mentors do is keep students on track and keep them from getting stuck for too long. Sometimes that means just knowing who to ask or where to look rather than knowing the answer yourself. In an ideal world, at least one mentor can answer at least basic architectural questions and knows how to get code accepted upstream, though.
 * Mentors do have to do two evaluations on the student, one mid-term and one at the end. (only one evaluation per student, though, so only one mentor needs to do this). There's a few questions about how the student is doing and then a pass/fail that determines if the student gets paid and continues in the program.

This page collects some frequently asked questions related to Summer of Code with the Python Software Foundation.

Where do I start?

  1. Choose an organization to work with. Python has a lot of sub-projects (over 20 in 2014!), so this can be hard. You do need to choose a sub-org if you're working with Python; projects without a sub-org are usually rejected at selection time. See "How do I choose a project or a sub-org?" if you need help.

    • Hint: Don't choose "Core python" as your default if you don't know what to do: our other sub orgs usually have a greater range of projects and mentors available!
  2. Set up your own development environment. Document what you do so you can remember it later, and so you can help others if they get stuck! And if you get stuck, don't be afraid to ask for help.

  3. Start communicating with the developers. Join the mailing list, IRC channel, or any other communication channels the developers use. Listen, get to know the people involved, and ask questions.

    • In almost all cases, you should communicate in public rather than in private. GSoC is a busy time for many developers and many beginner questions get asked repeatedly. Help keep your devs less stressed out by reading what they've written already and making it easier for them to have a record of the things they've answered.
    • If you want to make the best first impression, DO NOT start emails with "Dear Sir." (see How should I address my emails (or Why shouldn't I start my emails with "Dear Sir")? for some alternatives and more information.)

  4. Find some beginner-friendly bugs and try to fix them. Many projects have these tagged as "easy" "bite-size" or "beginner-friendly"

    • Note that if you apply as a student with the PSF you will be asked to submit a code sample, generally code related to your project. A few fixed bugs with code accepted upstream will make your application look great!
    • Having trouble figuring out which bugs are beginner-friendly? Check and see if anyone else has asked recently (usually during GSoC a *lot* of people are looking for easy bugs) and read the answer they got, but if no one's asked in a month or so, you can ask the developers via public mailing list or IRC. (Hint: don't ask privately; this is a question that other people want to know the answer to)
    • Some projects have beginner-friendly "bite-sized" bugs listed in the OpenHatch search engine, found here: http://openhatch.org/search/

  5. Find bugs and report them. Hopefully you won't encounter too many, but it's always a good idea to get familiar with your project's bug reporting process.

  6. Help with documentation. As a beginner in your project, you're going to see things that are confusing that more experienced developers may not notice. Take advantage of your beginner mindset and make sure to document anything you think is missing!

  7. Help others. This is a great idea for a lot of reasons: explaining things can help you learn them better, demonstrating your skills as a good community member can make you more memorable when your mentors have to choose candidates, and being helpful makes your community a better place!

How do I choose a project or a sub-org?

Choosing a project is a pretty personal choice. You should choose something you want to work on, and none of us can tell you exactly what that would be! But here's a few questions you might want to ask yourself to help figure that out:

  • What software do you already use? If you use the software, you know a lot more about it and probably have stronger opinions about what would make it better!

  • What would you like to learn? GSoC is meant to be a bit of a learning opportunity. Have you always wanted to be more involved with biology? Astronomy? Mathematics? Education? See which projects might help you improve your skills.

  • Who do you like working with? Hang out where the developers do and get to know some of your potential mentors. Which developers inspire you?

  • How do you want to change the world? Do you want to help people learn more? Communicate better? Understand our world better? Lots of python projects can help you do social good!

  • How do you like to communicate? Do you like realtime communication on IRC? Perhaps you should choose a project with mentors close to you in time zone. Do you like asynchronous communication on mailing lists? Find a group with active lists. Communication is a big part of summer of code (or really any open source development in a team) to finding a team that works the way you want to work can make your summer more awesome.

There's a list of sub-orgs for this year and for previous years linked from SummerOfCode. Be aware that all sub orgs might not be able to participate every year, and make sure to check and see if they're planning to participate before assuming.

If you're chosen as a GSoC student, you're going to be expected to make at least a few decisions on your own, so you can make a better first impression on mentors by showing that you're able to narrow down your field of choices!

What does "don't ask to ask" mean?

You'll hear this phrase sometimes on IRC, and it means "please just ask your question, don't say something like 'can I ask a question?' first."

Why? Developers are often pretty busy, and if you just ask the question, someone can jump in the minute they see your message with the answer or direct you to folk who can answer it better.

If you ask "can I ask a question?" you're basically just waiting for someone to say "yes" before any useful information is communicated. Many folk consider this slow, annoying, and perhaps even rude. Save everyone (including yourself!) some time and just ask the question right from the start. Culturally speaking, in open source projects it's generally ok launch right in to a question on IRC; you don't even have to say hi first!

What should I do if no one answers my question?

  1. Be patient. If you're on IRC, stick around for an hour or so (you can do something else, just leave the IRC window open and check back occasionally) and see if someone gets back to you. If they don't, try posting to the mailing list (it's possible all the developers are asleep!) If you're on a mailing list, you should give people around 24-48h to answer before worrying too much about it.

  2. Make sure you're asking in the best place. One common mistake students make is to contact individual developers rather than asking on a public mailing list or a public IRC channel. You want as many people as possible to see your questions, so try not to be shy! (and don't worry about looking too much like a newbie -- all of us were new once!) Sometimes projects have different lists/irc channels/forums/bug queues for different types of questions. If you're not sure, do feel free to follow up your question with something like "hey, I haven't gotten an answer on this... is there somewhere better I could post it or more information you need to help?"

  3. Try giving more information. If you've hit a bug, try to give the error message and information about your setup and information about what you've already tried. If you're trying to find a bit of documentation, indicate where you've already looked. And again "hey, I haven't got an answer... what other information could I provide to help debug this problem?" is a reasonable follow-up if you're not sure what people might need.

  4. If you're really having trouble getting in touch with your mentors, talk to the Python org admins by emailing gsoc-admins(at)python.org The Python org admins should have contact info for mentors with each project and can help connect you. (Note: please don't complain that you can't get in touch with us on the general google lists or #gsoc. They're just going to redirect you to TerriOda anyhow!)

How should I address my emails (or Why shouldn't I start my emails with "Dear Sir")?

If you want to make the best first impression, DO NOT start emails with "Dear Sir." Python has many mentors who are female and/or prefer other forms of address. We realize you're trying to be polite, but "Dear Sir" is often perceived in our communities as alienating, rude or simply too formal and off-putting.

Try "Dear developers" or "Dear mentors" if you're sending a general email. If you're addressing a specific person, use the name or nickname that they use on their emails. Culturally speaking, first names or chosen nicknames are fine for most open source projects.

Why does Meflin always say no?

He’s just like that! It's actually an incredibly important job: his job is to say no when things aren’t ready, so we can go back and make things more awesome. It's also his job to make sure that Terri's workload is reasonable, and that means saying NO pretty frequently. All those no’s make it possible to run this program every year!

What do I need to know to participate in Summer of Code with Python?

The answer to this depends a lot on the project you choose. We have a range of projects, from beginner to advanced. Each of the sub orgs expects different things from their students: maybe you'll need to know a bit about machine learning, or email, or image processing. The answer to this question is always ask your mentors what you will need to know for a specific project.

But a lot of people ask early on because they want to be sort of generically ready but they're not sure what they want to do yet, so that's not always super helpful.

So here's a list of a few things that are useful for most Python umbrella projects:

  • You need to have a bit of experience with Python. You can be a beginner, but practicing in advance is good! And there are a lot more projects available for students who are reasonably used to the language, so more practice means you'll have more project options.

  • You need to feel comfortable asking questions, because we're going to expect you to ask if you don't understand something.

  • You should be comfortable communicating your ideas to others in public. Most projects have public mailing lists and would prefer if you use them, and Python students will also be asked to blog about their work over the summer.

  • You probably want some experience with version control. We have a lot of projects that use different tools, such as git, mercurial, or bzr, and you can find out which one your project uses in advance and practice using it on your schoolwork or personal projects to get used to it.

  • You might like to take a bit of time to read the python style guide, PEP8. Not every project uses these rules, but they can give you a rough idea of what is considered "readable code" by most pythonistas. (And for fun, you might want to read the poetry of PEP20 "The Zen of Python")

How many slots does python get? How many does project $x get?

We don't know our slot allocation until Google announces them, and google bases their numbers on the number of students we tell them we want. The more great applications we have, the more slots we'll request. So rather than worrying about the number of slots, you should be aiming to be such a memorable and great prospective student that your sub-org will definitely request a slot with you in mind.

For sub-orgs, new groups working with us usually get 1-2 slots, experienced sub-orgs may be granted as many as they can comfortably mentor at the discretion of the org admins.

Google has been incredibly generous with letting us have slots in previous years, so we are usually more limited by the matching of mentors with truly excellent students.

What does it take to be a mentor?

  • We expect around a 0-10hr/week commitment, which sounds scary, but it's not actually that variable. You usually spend up to lots of time for the first few weeks, where you're fleshing out your ideas page, discussing projects with many students, and selecting students from their proposals. After students are selected, it becomes more like a 1hr commitment per week for a weekly meeting, and maybe a few more hours here and there for code review or questions. (That depends on your studen: experienced students may need very little supervision, inexperienced students may need more. It also depends on you: You and your co-mentor(s) select the student and project you mentor, so you can choose according to the time commitment you have.)
  • We want at least two mentors per projects, so hopefully no one ever gets overwhelmed and feels like they're always on call (Google does ask that we try to answer questions within 48h so students can't get stuck for too long), and no one mentor has to know all the answers.
  • I recommend at least one mentor has a weekly 1hr meeting with the student so they get to know each other, keep everyone on track, and give a chance to talk about other stuff (lots of students have questions about jobs, courses, architecture, open source, etc. and it's nice to have someone to talk to). Some weeks this meeting may be the only mentoring time needed.
  • Mentors don't have to be the Best At Everything. A lot of what mentors do is keep students on track and keep them from getting stuck for too long. Sometimes that means just knowing who to ask or where to look rather than knowing the answer yourself. In an ideal world, at least one mentor can answer at least basic architectural questions and knows how to get code accepted upstream, though.
  • Mentors do have to do two evaluations on the student, one mid-term and one at the end. (only one evaluation per student, though, so only one mentor needs to do this). There's a few questions about how the student is doing and then a pass/fail that determines if the student gets paid and continues in the program.

SummerOfCode/FrequentlyAskedQuestions (last edited 2016-10-13 07:20:26 by TerriOda)

Unable to edit the page? See the FrontPage for instructions.