Difference between revisions of "Google Summer of Code Evaluation"

From BZFlagWiki
Jump to: navigation, search
(initial guidelines for evaluating submissions)
m (Protected "Google Summer of Code Evaluation": GSoC guidelines are only for mentors [edit=autoconfirmed:move=autoconfirmed])
(No difference)

Revision as of 00:39, 26 March 2007

The Google mentor evaluation form allows for three positive and two negative evaluation levels (in addition to unevaluated/zero): +4 +2 +1 -1 -2

In order to help set an initial sorting of applications, the following guidelines should be used for ranking evaluations.


  • Do not evaluate if you are ambivalent or have absoluately no intention or interest in interacting with the student on the task being proposed. That is, if you don't care, then don't evaluate.
  • If you do care, especially if you want to be listed as the mentor for a given idea (i.e. you'll willing to help with their final review and evaluation), say so in the comments and use the "I'm willing to mentor" button.
  • A negative evaluation implies that you don't want the proposal to go forward completely regardless of any other submissions. Negative means not even minimally desirable or insufficiently proposed to be known.
  • Base rankings on the assertion that there are unlimited slots. That is, rank completely independently without a consideration that ranking positively might somehow be "stealing" a slot from another proposal. Don't rank negative simply because you don't like an idea as much as others.
  • The numbers will go through a final sort evaluation before being submitted to match up with mentor interests.
  • Evaluations should take overall potential impact into (strong) account. How many people would the proposal prospectively benefit? Does it have academic/research merit outside of gaming? Academic applicability was one of our primary application acceptance criteria.

Evaluation Levels

  • +4 => EXCEPTIONAL: exceptionally interesting and/or very appropriate and/or very well thought out proposal with detail. Should show an understanding of BZFlag development constraints and/or have .
  • +2 => GOOD: interesting and/or appropriate and/or detailed. Should show an understanding and be well proposed.
  • +1 => MINIMAL: minimally interesting (i.e. "not undesireable")
  • -1 => POOR: mildly inappropriate or is very poorly defined. This
  • -2 => UNDESIRABLE: should not even be considered. This should mostly be the case for ideas that are unacceptible to the gameplay even with unlimited developer resources.