date: 2019-01-15T04:24:21.000Z
anchor: gsoc-instructions
- developer.pidgin.im/wiki/SoCApplicationInstructions
lastmod: 2019-08-21T04:05:48.000Z Our project has historically allowed a wide variety of applications on topics
both solicited and unsolicited, and we do not intend to change this policy.
However, every application must meet some criteria, which we have set out here,
The application should demonstrate (by reference to previous projects, completed
coursework, job experience, description, etc.) that the applicant possesses the
* Competence in programming in the applicable language for the task at hand.
For Pidgin, Finch, or libpurple themselves this means C.
* An ability to effectively communicate, via written language, technical topics
Every application must describe the project the applicant intends to pursue.
While this may
*contain* information from our ideas page or other online
sources, it must
*primarily* consist of the applicant's own words and plans. It
* A description of the general task to be completed
* The applicant's estimate of the skills required to complete the task,
particularly noting those skills that will need to be developed during the
course of the project. Note that
*it is absolutely fine* if the applicant,
for example, is unfamiliar with a library or protocol necessary to complete
the project, if they can demonstrate that they understand what needs to be
learned and how that learning will be approached.
* A general timeline of the project as envisioned, with a breakdown including
major milestones (e.g., "necessary UI infrastructure", "supporting changes to
protocol X", "draft specification for Y").
Note that project applications
**need not be for projects from our ideas page**.
If you have a great idea for a project, that's fine, propose it! Just be sure
to describe what it is, why you can do it, and how you plan to accomplish it
If a project or applicant has any external factors that the project should be
aware of, those must be spelled out explicitly along with an explanation of how
the project will be affected if those factors fail to come through or otherwise
interfere. For example, if a project depends on a third-party library that is
known to have limitations that may affect the success of the project, the
application should describe those limitations and how they will be mitigated if
they get in the way. Something like this would be appropriate:
> I plan to use libfoo 3.1 to implement a foo protocol plugin, but it doesn't yet support a pluggable main loop, which libpurple requires. The libfoo
developers intend to address that, but if they do not address it by midsummer, I
will implement it myself and submit a patch upstream. If this happens, I
probably will not be able to complete the extended frobnicator API in libpurple,
but the project will still successfully speak the foo protocol by the end of the
Any potential major demands on the student's time MUST be included, such as:
finals (we know that not all school schedules line up with SoC precisely, and
this will absolutely not disqualify an application!), scheduled vacations or
holidays, existing summer commitments for work or school, potentially
conflicting job applications, etc.
## Improving your chances After submitting a great proposal, PLEASE join us on in one of our
[
chat rooms](
{{< ref "contact#chatrooms" >}}) and discuss
your ideas with the community. Experience has shown that students who are
involved before the Summer of Code starts are more likely to stick with it and
make good progress during the summer. In addition, this provides us more and
better information about how you work with other developers and what your skill
set is. You can greatly improve your chances of selection by engaging with the
