SOC Selection Criteria
A number of people have submitted proposals for the Google Summer of Code project. This page summarizes the conditions that we will use to score the proposals and to arrive at the subset that deserve funding. There will probably be some subjective elements to it, but it's hoped that by trying to quantify the decision process, it'll help people understand why their application was or was not accepted.
- 1: Proposal is longer than a few sentences. We need some meat in the proposal in order to even consider it. [Scoring applied - Bryce]
- 1: Proposer has contacted us prior to the submission. This demonstrates a definite interest in Inkscape and proves an ability to communicate with us.
- 1: Proposer knows the appropriate programming language(s).
- 1: Proposer shows evidence of being able to create software. Our goal is to help programmers become good at Open Source, not to teach non-programmers how to program.
- 1: Proposer has at least a little experience participating in Open Source projects. We want to help people learn Open Source practices, but we'd like to not have to start from nothing. Also, proven participation in Open Source even just at newbie levels indicates the proposer is sincere about wanting to become an Open Source contributor well into the future.
- 1: Proposer already has experience with Inkscape codebase. Coming up to speed from scratch will be time consuming and increase the risk that they may not have time to complete the project.
- 1: Proposal is well written. While we don't expect perfect English, we do expect that the proposer took time to spell check, proofread it, organize it logically, and use comprehendable grammar.
- 1: Proposal demonstrates understanding of subject matter. We expect the proposer to do some research, ask questions, and gain some understanding of the project they're proposing. This gives us confidence that they'll be able to complete the project successfully.
- 1: Proposal shows creativity. We like to see someone thinking outside the box, including proposing ideas for projects we hadn't listed.
- 1: Proposal is the only submission for the given task. Many proposals focus on the same few tasks, so if you're the only person proposing to do a given project, that weighs in your favor.
- 1: Proposal shows implementation planning. If the author has broken the work out into a task list, it shows that they know what they'll be doing.
- 1: Proposal shows plan for integration into Inkscape. Getting the code included in Inkscape is non-trivial; any evidence of understanding how to do this will be well received.
- 1: Proposal scope is realistic. 2 months goes fast. Proposals that are promising too much are unlikely to be completed in a timely fashion.
The following are conditions that result in automatic rejection:
- Reject: Group project proposed. Google has specified that groups MAY NOT participate. Individuals only.
- Reject: Proposer is not a student. Requirement of the program.
- = -2: Proposal is for something not applicable to Inkscape. We will move it to the appropriate project when possible.
Note that these criteria are unique to inkscape; other projects in the SoC program may use entirely different means to decide who gets funding.