| | 1 | = Instructions for Google Summer of Code applicants to Pidgin, Finch, and libpurple = |
| | 2 | |
| | 3 | 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. |
| | 4 | |
| | 5 | == Applicant credentials == |
| | 6 | |
| | 7 | The application should demonstrate (by reference to previous projects, completed coursework, job experience, description, etc.) that the applicant possesses the following skills: |
| | 8 | |
| | 9 | * Competence in programming in the applicable language for the task at hand. For Pidgin, finch, or libpurple themselves this means C. |
| | 10 | * An ability to effectively communicate, via written language, technical topics and precise thoughts. |
| | 11 | |
| | 12 | == Project description == |
| | 13 | |
| | 14 | 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: |
| | 15 | |
| | 16 | * A description of the general task to be completed |
| | 17 | * 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. |
| | 18 | * 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"). |
| | 19 | |
| | 20 | == External factors == |
| | 21 | |
| | 22 | 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: |
| | 23 | |
| | 24 | 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. |
| | 25 | |
| | 26 | 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. |
