Difference between revisions of "Summer of Code Selection Criteria"
Jon Phillips (talk | contribs) |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | |||
[[Category:Developer]] | [[Category:Developer]] | ||
[[Category:Summerofcode]] | [[Category:Summerofcode]] | ||
| − | |||
| − | This page is originally from the [http://inkscape.org/wiki/index.php/SOC_Selection_Criteria Inkscape Wiki | + | This page is originally from the [http://inkscape.org/wiki/index.php/SOC_Selection_Criteria Inkscape Wiki]. |
This page summarizes the conditions that we will use to score the proposals and to arrive at the subset that deserve funding. | This page summarizes the conditions that we will use to score the proposals and to arrive at the subset that deserve funding. | ||
| Line 20: | Line 18: | ||
* '''+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 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 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 scope is realistic.''' 2 months goes fast. Proposals that are promising too much are unlikely to be completed in a timely fashion. | * '''+1: Proposal scope is realistic.''' 2 months goes fast. Proposals that are promising too much are unlikely to be completed in a timely fashion. | ||
| Line 27: | Line 24: | ||
* '''Reject: Group project proposed.''' Google has specified that groups MAY NOT participate. Individuals only. | * '''Reject: Group project proposed.''' Google has specified that groups MAY NOT participate. Individuals only. | ||
* '''Reject: Proposer is not a student.''' Requirement of the program. | * '''Reject: Proposer is not a student.''' Requirement of the program. | ||
| − | * ''' | + | * '''-2: Proposal is for something not applicable to Creative Commons.''' |
Note that these criteria are unique to Creative Commons; other projects in the [http://code.google.com/soc/ Summer of Code] program may use entirely different means to decide who gets funding. | Note that these criteria are unique to Creative Commons; other projects in the [http://code.google.com/soc/ Summer of Code] program may use entirely different means to decide who gets funding. | ||
Latest revision as of 15:42, 4 March 2008
This page is originally from the Inkscape Wiki.
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.
- +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 Creative Commons cctools 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 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 Creative Commons.
Note that these criteria are unique to Creative Commons; other projects in the Summer of Code program may use entirely different means to decide who gets funding.
