ORGANIZATION

Claim: Membership of the Scientific Committee must be broadened.
Goal: To ensure quality, continuity, and diversity of the competition.
Reason: We have had too many (partial) failures in the past.
Constraint: The GA and/or IC must keep control over how SC changes.
Proposal: Amend IOI Regulations concerning SC operation and membership.

TASK TYPES

Claim: The types of competition tasks must be broadened.
Goal: To ensure an attractive competition for young TOP-talent.
Reason: We currently have too many "routine" tasks.
Constraint: No other knowledge and skills from the competitor must be required compared to what they are expected to have now.
Proposal: The IOI SC gets the responsibility to make this happen.

COMPUTING ENVIRONMENT

Claim: The computing environment used in the competition must be broadened.
Goal: To ensure interest from youngsters.
Reason: We currently have a very limited machine model, for example, 640 KB RAM, 64 KB segments.
Constraints: Each task should be able to impose its own resource restrictions, and these must be enforceable (e.g. 100 bit of RAM, or three types of memory with given size/speed). The machine model must be widely available at little cost.
Proposal: Competitors submit program SOURCES (not executables) in some STANDARD language(s) (not vendor proprietary languages) as a representation of an ALGORITHM that can be executed by a machine. The evaluation software will carry the burden of making an executable (also see next point).

EVALUATION

Claim: Evalution of competitor submissions must be taken more seriously.
Goal: Thorough, speedy, objective, and fair evaluation.
Reason: We have had too many (partial) failures in the past. The current practice of "testing" with a few test cases presents an unacceptable image of Computing SCIENCE.
Constraints: Avoid language barrier by AUTOMATED evaluation. Evaluation software must be FREELY available in source form ("open source" product). During competition, competitors will be able to get some feedback from evaluation software to help avoid silly mistakes (the ones that we are not interested in, such as "wrong file name"). Evaluation is based on SOURCE code submissions (also see previous point).
Proposal: Establish an IOI Software Team (via IOI SC) that develops evaluation software and integrates it with compilers etc. The IOI SC provides high quality evaluation facilities (input files, input validators, output checkers, and solutions, for each task).

In some competitions, there is already wide spread experience with source code evaluation. Please, do understand that source code evaluation does NOT mean that judges are going to read source code and quibble over source code with competitors. All that it means, is that the translation from source to executable is done by the evaluation system. This takes away the burden from the competitors to know about the target hardware. It is a much more level playing field if you are supposed to reason in terms of source code and not in terms of executables, because all kinds of compiler directives and hardware features (such as caches) influence the speed/size/memory usage of an executable. Source code evaluation of programs written in some standardized language also makes the competition much less platform dependent.