hugo/content/development/gsoc/instructions.md

Fri, 30 Aug 2024 19:33:36 -0500

author
Gary Kramlich <grim@reaperworld.com>
date
Fri, 30 Aug 2024 19:33:36 -0500
changeset 543
4ab2b8637540
parent 444
f19b90df2d5f
permissions
-rw-r--r--

Update the plugins page for the new process

This includes defining the process and providing a template for a new issue to
add new plugins. I did go through and audit `No IRC /WHO` so we had at least
one validated entry.

Testing Done:
Ran `npm run hugo:server` locally and verified the page worked and checked the new links.

Bugs closed: NEST-53

Reviewed at https://reviews.imfreedom.org/r/3450/

---
title: GSoC Instructions
date: 2019-01-15T04:24:21.000Z
anchor: gsoc-instructions
replaces:
  - 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,
to be considered.

## Applicant credentials

The application should demonstrate (by reference to previous projects, completed
coursework, job experience, description, etc.) that the applicant possesses the
following skills:

 * 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
   and precise thoughts.

## Project description

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
should include:

 * 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
within the summer.

## External factors

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
summer.

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
community early.

mercurial