pidgin/nest

Add the gsoc instructions page and remove draft from gsoc/_index.md

2019-01-14, Gary Kramlich
73d9b0c2b530
Parents 7445e4e1b921
Children 888744ed2501
Add the gsoc instructions page and remove draft from gsoc/_index.md
2 files changed, 47 insertions(+), 2 deletions(-)
  • +11 -2
    content/gsoc/_index.md
  • +36 -0
    content/gsoc/instructions.md
    • --- a/content/gsoc/_index.md Mon Jan 14 22:04:57 2019 -0600
    +++ b/content/gsoc/_index.md Mon Jan 14 22:24:21 2019 -0600
    @@ -2,7 +2,6 @@
    title: "Google Summer of Code"
    date: 2019-01-10T22:32:00-06:00
    anchor: "gsoc"
    -draft: true
    ---
    Pidgin has been involved in the
    @@ -10,7 +9,17 @@
    since it was started. This section contains a running list of project ideas as
    well as some documentation on our participation for the years we participated.
    - * [Ideas](/gsoc/ideas)
    +## Project Ideas
    +
    +You can find our current list of ideas on the [Ideas](/gsoc/ideas) page. If
    +you have any ideas, feel free to email the mailing list or open a pull request.
    +
    +## Instructions for Applications
    +
    +We have some detailed directions on how to make yourself stand out from the
    +crowd on the [instructions](/gsoc/instructions) page.
    +
    +## Previous Years
    {{< gsoc year="2015" >}}
    {{< gsoc year="2013" >}}
    --- /dev/null Thu Jan 01 00:00:00 1970 +0000
    +++ b/content/gsoc/instructions.md Mon Jan 14 22:24:21 2019 -0600
    @@ -0,0 +1,36 @@
    +---
    +title: "GSoC Instructions"
    +date: 2019-01-10T22:32:00-06:00
    +anchor: "gsoc-instructions"
    +---
    +
    +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 ideaspage**. 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 IRC (irc.freenode.net #pidgin) or XMPP MUC (devel@conference.pidgin.im) 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.