2010 Contest Rules - Summary

What follows is a quick summary of Rails Rumble competition rules for contestants. Before entering, you’ll be asked to accept the full legal contest rules. You may also want to check out our fantastic event sponsors and the growing list of prizes.

If you have questions, feel free to email the organizers.

1. Ruby on Rails

All applications must be built using Ruby on Rails or other Rack-based Ruby web frameworks. No substitutes! No, you can’t use Python. Or lolcode. Or folding chairs from the audience. There are plenty other events like the MVC Melee, the Django Dash, and the Node.js Knockout, plus we’re planning to organize a more free-form technology-agnostic event later down the road.

2. 48 Hours

As a contestant, your team has exactly 48 hours to develop your web based application during the Rumble. The competition kicks off at 12:00am / 00:00 GMT on October 16th, 2010 and will end at 11:59PM / 23:59 GMT on October 17th, 2010.

You can, of course, work on the concept for your application before the competition starts, including paper and/or digital mockups of the user interface and database entity diagrams. However, no production assets of any kind can be created until the start of the official competition period illustrated above. This includes “ready to slice” graphic design assets, application code, and user stories / test cases. Please post any information of this sort publicly, and make sure to list these items on your team profile page in order to prevent any questioning. Plan, don’t create. And if you’re in doubt, send us an email to verify.

After the initial 48 hours are up, you’ll be judged on what you’ve completed. No additional features or bugfixes are allowed during this period, or you will be disqualified.

3. Teams of One to Four Humans

Teams should be comprised of between one and four individuals. No more than four people are allowed on a team. To be eligible, teams must register at least 1 week prior to the start of the competition (space subject to availability). No robots, aliens, or superheroes. However, team members should feel free to dress as robots, aliens, and superheroes.

4. Source Control by GitHub

We’ll provide your team with a free private Git repository courtesy of GitHub. As you develop your application, you should push your progress to the repository. You should push to the repository regularly (“commit early, commit often”) in order to demonstrate progress.

Note that organizers will be observing checkins to monitor validity and progress throughout both the development portion of the contest and the judging process. Don’t plana on doing anything tricky like developing your application in its entirety ahead of time, rebasing it and pushing it in at 9AM Saturday morning and relaxing with a Mimosa. That’s bad.

Before the contest ends, you must mark your entry as complete on the team profile and tag a release of your code with the word ‘rumble10’. This should be the version deployed on your VPS and will be validated by our automated qualifier system.

5. Deployment via Linode

A big part of running a successful web application is knowing how to deploy and maintain it. Thanks to the participation of our sponsors, every team gets their own private Linode VPS to use in deploying their applications. Yes, this means that you have to set it up from scratch, so be prepared and make sure that someone on your team has at least a passing knowledge of UNIX and Ruby deployment technologies. Remember, you are being judged on the overall user experience. If your app crashes or is generally unresponsive, your peer reviewers are likely to give you an, ahem, unpleasant score. VPS-hosted applications will remain online and hosted until the winners are announced – shortly after voting closes.

Competition organizers will also require access to your VPS during the judging period via supplied SSH keys. The deployed codebase may occasionally be compared to the final tagged version (as of the competition closing) to make sure that you haven’t introduced additional features or bugfixes during the judging period. You may access your VPS during the judging period to restart a stuck process or perform routine maintenance, however.

6. Leverage Others

Third party software, in the form of RubyGems or Plugins are allowed, even encouraged (if publicly available and allowed for the use of intended for this contest). Please make sure to update your team profile once the competition has started, and list any third party libraries, plugins, or other applications (ImageMagick, ffmpeg, etc) that you make use of. Third party Javascript libraries, Flash widgets, and other component libraries, are allowed. Same rules apply; you must update your profile to list any external libraries that are in use. Rezpect and give props where props are due!

Stock photography, icon sets, and publicly available templates are allowed. Teams are prohibited from commissioning or otherwise paying for any content that is created specifically for the application as opposed to being publicly available for everyone’s use. Developing a plugin or library before the competition that provides your application’s general functionality is considered cheating. Developing a plugin or library that is publicly available and provides a general purpose publicly usable function (such as accessing an API) can be done before the competition begins.

If you have a question about a particular piece of third party software, just ask the organizers.

7. Use Web Services

Your application can make use of any non-paid and publicly available third party web services. This means that mashups with established services such as Google, Yahoo, Flickr, Twitter, etc are all possible and allowable. As before, make sure to update your profile to list dependencies on third party services and give credit to those services accordingly.

8. Ownership and Open Source

Hey, we’re just running a competition here. What you do with your source once the competition is over is up to you. We encourage participants to open source the codebase of their applications for the benefit of the community. However, if you choose not to open source your application, well that’s up to you. There are no penalties for wanting to safeguard your secret sauce from the general populace. We hope that a number of participants use this opportunity to launch disruptive ideas, or maybe even the first version of a software startup, and understand that sometimes part of a viable business strategy is keeping your code close to your chest. It’s your decision!

Note that the competition organizers will have access to your code base throughout the competition, in order to make sure that no cheating occurs (as outlined previously). We won’t steal anything from you, promise! However, we do reserve the right to use your application’s likeness as a promotion for this or future contest. Please see the official legal rules for more details if you’re unsure about what this means.

9. User Privacy

Because your application will be awesome, lots of people will be reviewing it and playing around with it during the competition and review period. In the interest of protecting their information, we’re imposing a non-optional privacy policy for the duration of the event. You are not to reveal any user information to any third party, except when required by law. You are not to use account emails for any purpose other than the standard operation of your application. If you choose to continue developing your application after the Rumble has ended, you are required to notify users of any changes in your privacy policy, so they can remove the information if they so choose. For the duration of this competition you hereby agree to abide by the Privacy Policy of the Rails Rumble competition.

10. You Will Be Judged

Judging will occur in two phases. First, an expert panel of industry judges will review all qualifying (“finished”) applications and decide which belong in the top tier. The best overall applications will proceed to public voting, where any user that signs up to judge will be able to rate them and help determine contest winners.

All judging will occur from the perspective of ‘joe average web jockey’. That is, code quality will not be judged. We believe code quality to be a highly subjective affair, and thorough reviews are extremely time-intensive and not in the best interests of this competition. Your application will be judged based on it’s visible merits. In particular:

* completeness
* user interface
* originality
* usefulness

Each judge (both expert panel members as well as peer judges) will be able to rate each application on a scale of one to five (1-5) on these criteria and comment on recommendations / possible enhancements, errors, and other issues that they experienced. Other judges will be able to review these comments. We strongly encourage contestants to use development best practices but in the end judges are expected to rate applications based on their visible merits. So, just be aware of that!

Rails Rumble organizers reserve the right to disqualify any team that is believed to be cheating or not competing in the spirit of the Rails Rumble. Contest organizers also reserve the right to certify or normalize user ratings as they see fit to account for voting discrepancies and attempts to game the system.

11. You Don’t Need To Sling Code To Get Involved

You don’t need to hack Ruby or Rails to participate. In fact, we anticipate that only a small fraction of the people involved in this event will be on teams contributing applications. You can be a huge part of the process just by signing up for an account, and participating in the judging once the application development process is complete. Who knows, you might even discover a fun new web game, service, or time-saver that somehow makes your life better. Early adopters ftw.

We encourage judges (that’s you!) to dig into these apps and find any lions that may be hiding in the trees. Go find those bugs, and help determine who is awarded the Rumble Championship Belt!*

* It’s a real belt. We’re dead f**king serious.