Big News, Rails Rumble is now Ruby Rampage!

2009 Contest Official Rules

Aug 01, 2008
Just a few rules. Read em. Rezpect em.
  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. We're planning to organize a more free-form technology-agnostic event in addition to the Rumble in the near future. Stay tuned...

  2. 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 August 22nd, 2009 and will end at 11:59PM / 23:59 GMT on August 23rd, 2009. 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 created until things officially get rolling. This includes digital mockups of any sort, graphic design assets, code, etc.

    After those 48 hours are up, an expert panel and a jury of your peers will be invited 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.

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

  4. 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 in order to demonstrate progress. Note that competition organizers will be observing checkins, so don't plan on doing anything tricky like developing your app in it's entirety 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 mark your entry as complete on the team profile and tag a release of your code with the word 'railsrumble09'. This should be the version deployed on your VPS and will be validated by our automated qualifier robots.

  5. 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 private* 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. 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.

    *Note that during the judging period, competition organizers will also require access to your VPS via supplied SSH keys. 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 tagged version (as of the competition closing) to make sure that you haven't introduced additional features or bugfixes during the judging period.

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

  6. 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 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. Paying for something that is created specifically for the application rather than just being generally available to anyone is prohibited, however. 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.

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

  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! Well, unless you have an idea that we clearly identify as genius and extremely marketable, in which case... No, but seriously. We promise.

  9. Judging.

    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
    • overall*

    Each judge (both expert panel members as well as peer judges) 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.

    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.

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

  10. Participation.

    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.

    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!!!