The Singularity Institute for Artificial Intelligence (SIAI) is a non-profit organization founded in 2000 to develop safe artificial intelligence software, and to raise awareness of both the dangers and potential benefits of artificial general intelligence technologies. The SIAI sponsors numerous research projects, both theoretical and applied, and structures applied research under the umbrella of The Open Cognition Project (OpenCog). OpenCog is software for the collaborative development of safe and beneficial Artificial General Intelligence, and aims to provide research scientists and software developers with a common platform to build and share artificial intelligence programs.

Many thanks to the GNU Hurd project for the template for this template!

Before we get to the actual application form, some important remarks about the application process -- please read them carefully.

Submitting the application form is only part of the deal: we expect a few other things on top of that. Following the recommendations below will make your application much stronger, and help it to stand out from the other applications submitted.

Naming your application

First of all, please give your application a useful title. In many cases, you can simply copy it from the project ideas list. Some ideas -- like language bindings for example -- are rather broad, and require an additional specifier. (e.g. "Python Bindings").

If you are proposing a project not on the ideas list, you have to find a useful title yourself of course -- but surely this isn't hard, if you were able to come up with your own project idea.

Communication

One of the things we expect is that you contact us directly as soon as possible (preferably even before you send the application form), on our OpenCog-SoC mailing list and IRC channel, details of which are on the Discussion page (please join any lists before posting). Don't be afraid -- we won't bite. IRC in particular allows for very informal conversations.

(Note though that we are not all in the same time zone, and people generally don't stare at the IRC screen all the time -- it can take quite a long time until somebody replies: even several hours. Don't get discouraged by that: Just be patient and hang on, or try again later. Also, if you address someone directly by typing their nickname then most IRC clients cause some kind of notification for that user that they are being spoken to. ferrouswheel, dhart, linas, and JaredW are often around and maybe able to give your feedback to questions.)

Contacting us as soon as possible is crucial, as regular communication is the single most important factor for a successful GSoC project. We need to see that you are able and willing to talk to us regularily. Also it allows us getting to know you much better than the application form alone could.

You shouldn't be at a loss for reason to contact us. You ought to discuss your project and application with us. For example: You will gain a much better idea about the project, our expectations etc. -- in short, you will be able to submit a better application right from the beginnig, saving both yourself and us some tedious round-trips.

Also, if you really want to get involved with the OpenCog project, there are surely many things you will want to know. All in all, you should have ample causes to get in touch during the application period. Bonus points if you also participate in discussions not directly related to your project.

Contribution

The other thing that will strongly support your application is making a change to some part of the OpenCog code (OpenCog Framework, RelEx, MOSES, PLN, OpenBioMind, or other part of OpenCog), and submitting a patch with the change. (If you are not sure what that means, ask us!). Patches should be submitted no later than April 14 00:00 PDT / 07:00 UTC but, of course, submitting and discussing patches earlier than this date is encouraged!

This is important, as it shows that you have everything set up to start hacking on the project (source code, tool chain, testing environment etc.), and that you have all kinds of qualifications necessary to successfully finish the project: general programming abilities; working in the OpenCog environment; submitting patches and reacting to feedback; finding and/or asking for any information you need; and so on.

Don't get us wrong: We absolutely do not demand that you have and know all this up front. After all, the idea of GSoC is to introduce you to free software development in general, and to our project specifically. We are willing to help you with anything you will need to create the patch -- you just need to ask!

We actively encourage you to contact us whenever you have any doubts. Don't be afraid that we will think worse of you when you ask too much. On the contrary: this is an occasion for you to show us that whenever there is something you don't know yet, you are able to learn quickly, and know how to ask for help.

As for the kind of change we want: Ideally, it would be some real improvement (bug fix or new feature) in a part of OpenCog (e.g. in code for the OpenCog Framework, RelEx, MOSES, PLN, OpenBioMind, etc.) related to the specific project you want to work on. (This is not always possible though -- in that case, a useful change to some other part of OpenCog would also do, or perhaps some not strictly useful change to the part you will be working on.)

The project ideas page has more information on this. In either case, please contact us, so we can discuss it, and together come up with something suitable.

Note that we do not place any demands on the size of the change. Even a very simple modification suffices to meet the minimum requirements -- after all, the amount of time available for working on this before the end of the student selection process is quite short; and you are not obliged to do a substantial amount of work before you get accepted. (But if you feel more ambitious, that's fine of course!)

Now to the actual questions in the application form. Please answer all questions -- we are asking them for a reason. (Whether you answer them one by one, or all in a larger piece of prose, is up to you.)

If some of these questions look strange to you and/or you don't quite know what to answer, don't despair. This is not some kind of exam -- we do not expect you to have good answers for all of them up front. (In fact, we would be very surprised if anyone did...) The idea is more that you learn the answers before the end of the application process -- with our help. Please talk to us whenever you are unsure about something.

And now that you are prepared to face the enemy, here we go!

Outline

• Please describe the task of the project you want to work on, in your own words. Be as specific as possible. It's not sufficient to rephrase the description from the project ideas page; show us that you actually understand what this task involves! Read the available documentation (and possibly code) if necessary. And don't hesitate to ask us if you have any doubts!

• Give a preliminary schedule for your work. The exact dates will obviously be only guesses; but try to be specific about all the individual steps you will have to do to complete the task.

Note: By the end of the summer session, the code is expected to be in a state ready to be merged to mainline. Experience shows that adding the "final touches" necessary for that, tends to take up quite a lot of time -- there are always some bugs here and there, some misunderstandings about how things are supposed to work, build system issues, missing documentation, forgotten bits, and so on. Thus, the schedule should suppose that a larger part of the main implementation work will be done by midterm!

Also note that by the beginning of the summer session, you need to be able to work on the task at more or less full speed -- meaning that you need to get familiar with the code, think through the design (and discuss it with us) etc. already in the interim period before the summer session.

• What things will you have to learn to be able to complete the project? What do you already know?

In case you wonder what this question is getting at: Again, we want you to show us that you really understand what kind of work the task involves. As always, we encourage you to ask us for pointers if you are not sure how to go about this.

• Why did you choose this project idea? What do you consider most appealing about it?

• Please describe your previous programming experience in detail. What languages do you use? How long have you been programming, and how much? What kind of programs have you written? What kind of programming (and related) work are you enjoying most?

• Have you been involved in any free software ("Open Source") projects yet? Which projects, how long, and in what way have you been involved? Have you been active in OpenCog project/OpenCog community before?

• Please briefly describe OpenCog, including the goals, architecture etc. Also, what makes you interested in OpenCog? Why do you want to work on it? What is your vision of it's future development?

We ask this because we want to make sure that people working on OpenCog do understand what it is all about. You will probably need to read some documentation -- as always, you are encouraged to ask for pointers, and generally to talk to us about it.

• Do you have a permanent internet connection, especially during the time of the summer session? Are you able and willing to hang out on the OpenCog IRC channel regularily? (As in: Running the IRC client more or less permanently and checking for activity now and then.) If it turns out that your mentor lives in a different time zone, could you shift your day/night rhythm to better match that of your mentor and other OpenCog developers? What is the IRC nick you will use throughout the summer session?

Hint: Hanging out on the channel regularily during the application process would be a good start :-)

• When does your university term end, when are your exams, and when does the next term begin?

We need to know up front whether there are any overlaps with the GSoC time frame (especially the summer session), so we can make a plan how to deal with it properly.

• How much time do you intend to spend on your GSoC project per day/week during the summer months?

Note that according to the GSoC FAQ, the project is meant to be "your major occupation during the summer". In other words, you should treat it more or less as a normal full-time job.

• What other major activities will you engage in during the summer? (Moving apartments, longer vacations, other obligations, etc.) If any, how do you intend to make sure you will be able to dedicate sufficient time to your project nevertheless?

Please be open about this, and also mention things you are not yet sure about. We can be flexible about time arrangements; but we need to know about any possible obstacles up front.

• Are you able and willing to execute the SIAI IndividualContributorLicenseAgreement?

Note, this agreement is based on the Apache 2.0 ICLA

• How do you plan to share and document your progress?

For example, where will you post your accepted application and regular updates? (just a few bullet points each week on a wiki page or blog is a good minimum)

• How do you intend to make sure that your code will keep on being maintained and supported properly after the end of the GSoC program?

• Anything else you want to add to your application?