There are many more participants in Darkness and Twilight, yet both these fall in the middle of the week. Either extend one of these phases, or shift the entire contest that at least one weekend day can be used for algorithm development.

The competition needs to strike a better balance between tweaking and algorithmic improvements. To encourage more of the latter, code for each submission could be hidden (during daylight) for an hour (or more) after submission. This would help on the Big Sunday Push. It would also mean that you could start testing new approaches an hour before a deadline without fear of being "tweak-bumped" (beaten by a tiny last minute tweak of your own code).

To avoid the problem of tweaking and over-fitting on the test set, every submission could be run on two different test stes - the first is used for all mid-contest competitions and scores are made known immediately, while the second is used for the Grand Prize, and scores are only made known after the queue closes. This would put more emphasis on making general improvements to the code.

The only way to win Daylight is to submit during the final half hour of the contest. For a large part of the world this falls in the dead of night. Others are constrained by the reliability of their connections and a power failure or connectivity issue at a critical time can ruin a contestants chances. Scheduled entries can be scored immediately (or whenever the queue is idle) but effectively be in darkness until their scheduled submission time arrives. This should be much fairer to all involved.

It would be more fair if everyone who clone somebody else's submission leaved some points of his/her score to the owner of the initial submission. Maybe an hierarchy should be applied about how points will be distributed vertically on the list of "parents" of each cloned code.

One way to do this would be through a minicontest where people could submit their different ideas with some identifying label, and the community could vote for most original/favorite method.

The blank canvas will allow collaboration and competition on short simple entries, improving accessibility and appeal for contest newcomers. Code will be relatively easy to follow in this period, in contrast with the end of twilight. If this period is short enough, ambitious players will not have time to develop a contest-winning algorithm, and will be motivated to hold back until darkness/twilight. This early daylight might be a friendly introduction to the contest for new players.

Would be nice for matlab contest team to offer to the winner of the prize the opportunity to work for mathworks in a related with the contest project. This would dramatically increased the numper of participants the contest

Entries in the queue that haven't be run yet should never have their code viewable by anyone. This is should have a similar result as a twilight/darkness period, without preventing people from viewing previously run code. It would probably help significantly with the 'tweak bombing' that usually occurs right around each prize deadline throughout the entire contest.

(Only necessary if the contest only processes one entry per contestant, and each contestant is limited to one account name.)

To get a more meaningful score value to find the winner of a contest phase, the top 10 entries (or all entries inside a certain time interval) could be evaluated again several times to minimize the impact of machine load variations on the runtime.

One way to do that is to pick the scoring coefficients more appropriately to 'de-value' minor timing variations. Another way would be to just round the
times to the nearest tenth second. This helps eliminate the 'luck of the draw' due to random load variations on the contest system.

It would be nice to see if any of your contibutions end in a leading entry. I think something similar was done in the past... i liked it!!

If the machinery only scored one entry per contestant on each pass through the queue, people who submit lots of entries will only slow down themselves.

If the scoring process took place across several machines, this would allow for the same consistency of timing, yet allow us to increase the test suite size and/or increase queue throughput.