Rules

Just a few rules. Read em. Rezpect em.

I. Ruby on Rails.

All applications must be built using Ruby on Rails. No substitutes! I mean, it’s in the name of the competition. No, you can’t use Python. Or lolcode. Or folding chairs from the audience. Yes, we considered alternative Ruby web stacks, including Merb, Camping and Sinatra. We’re hoping to organize a more free form event in addition to the Rumble in the near future. Stay tuned…

II. 48 Hours.

You’ve got exactly 48 hours to develop your web app during the Rumble. The competition kicks off at 12:00am / 00:00 GMT on October 18th, 2008 and will end at 11:59PM / 23:59 GMT on October 19th, 2008. You can, of course, work on the concept for your application before the competition starts, including paper mockups of the user interface and database entity diagrams. But no digital assets can be written until things officially get rolling. This includes digital mockups of any sort, graphic design assets, code, etc.

After those 48 hours are up, a jury of your peers (and if you’re lucky or good, your fans) will have 10 days to use your application and judge it against the competition. No additional features or bugfixes are allowed during this period, or you will be disqualified.

III. Teams.

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. No robots, zombies or aliens. However, team members should feel free to dress as robots, zombies or aliens.

IV. Source Control.

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”), at least twice a day. Note that competition organizers will be observing checkins, so don’t plan on doing anything tricky like developing your app in it’s entirely ahead of time, rebasing it and pushing it in at 9am Saturday morning and relaxing with a Mimosa. That’s bad so don’t do it. We’ll send you access information before the competition kicks off.

Before the contest ends, we expect you to tag a release of your code with the word ‘railsrumble’. This should be the version deployed on your VPS.

V. Deployment.

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 private1 VPS to use in deploying your application. 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 Capistrano!). Remember, you are being judged on the overall user experience. If your app crashes2 or is generally unresponsive, your peer reviewers are likely to give you an, ahem, unpleasant score. Access information for your VPS will be provided with source control information before the competition begins. VPS-hosted applications will remain online and hosted until the winners are announced — shortly after voting closes.

VI. Third Party Love.

Plugins are allowed, even encouraged. Ruby libraries, in the form of publicly available Gems or other libraries available openly (e.g. via Github), are also allowed. Please make sure to update your profile, and list any third party libraries, plugins, or other applications (ImageMagick, ffmpeg, etc) that you make use of. Rails Engines are not permissible. Third party javascript libraries, 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! Publicly available stock photography, icons, and templates are allowed. 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.

VII. Web Services.

Your application can make use of any existing third party web services. This means that mashups with Google, Yahoo, Flickr, Twitter, etc are all fair game. As before, make sure to update your profile to list dependencies on third party services.

VIII. 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 a startup service, 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! Well, unless you have an idea that we clearly identify as genius and extremely marketable, in which case… OK, fine! Fine! We promise.

IX. Judging.

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 * overall3

Each peer judge (that is, just about anyone) will be able to rate each application based on these criteria and comment on errors, issues, etc they experience for other judges to see. If you half-assed your login code and it blows up when it tries to email someone, that sucks. Someone is going to find out, and vote you down. If you didn’t write any tests, well that’s your call. But I bet it’s going to mean unexpected issues here or there. We encourage you to use development best practices but in the end your peers are going to judge you on the visible merits, like they would ANY OTHER PUBLIC WEB APPLICATION.

Please note 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.

X. Participation.

You don’t need to hack 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.

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 Belt4

OK, I think that’s it. Sorry for our long-windedness, but it’s important to set some ground rules before entering the dojo. Now, LET’S GET READY TO RUMBLE!!!

1 Note that during the judging period, competition organizers will also have access to your VPS. You should not attempt to change the account credentials for the railsrumble account. We’re merely watching to make sure you follow the rules of the competition. As part of this, the deployed codebase may occasionally be compared to the final git version (as of the competition closing) codebase to make sure that you haven’t introduced additional features or bugfixes during the judging period.

2 During the judging period you may access your VPS to restart a stuck process or perform routine maintenance. Code changes are explicitly forbidden, however.

3 A prize will also be awarded for best solo project :-).

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