Organizing Hackathons: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "If you're organizing a hackathon, you may want to go through this page for tips on preparation == Basic do's and don'ts == * Don't rely on stable WiFi. Bring a router, and...")
 
Line 12: Line 12:
* Bring flash drives with a mozilla-central clone (or whichever repo you intend to work with)
* Bring flash drives with a mozilla-central clone (or whichever repo you intend to work with)
* Don't assume that everyone has Linux. Prepare for Windows users by having a local copy of all the dependencies.
* Don't assume that everyone has Linux. Prepare for Windows users by having a local copy of all the dependencies.
* Try to identify some easy, open bugs beforehand.
* Try to identify some easy, open bugs beforehand. Have plans for how to solve them, files to look at, etc.
* The first build is long. You might want to plan things accordingly, maybe having users set up a build before the bug-hunting starts.
* The first build is long. You might want to plan things accordingly, maybe having users set up a build before the bug-hunting starts.
 
* Consider having attendees choose tasks/start investigating solutions while waiting for build environment setup. You can still use tools like MXR/DXR while the code is being copied, for example.
* Consider pairing up attendees if one person's build environment will take significantly longer to set up than the other.


== For appathons ==
== For appathons ==

Revision as of 19:12, 15 February 2014

If you're organizing a hackathon, you may want to go through this page for tips on preparation


Basic do's and don'ts

  • Don't rely on stable WiFi. Bring a router, and get to know the Internet infrastructure beforehand from the venue
  • Do check the intended status of essential services like Bugzilla or mxr beforehand. You don't want them to go down during the event.

For bug-squashing events

  • Bring flash drives with a mozilla-central clone (or whichever repo you intend to work with)
  • Don't assume that everyone has Linux. Prepare for Windows users by having a local copy of all the dependencies.
  • Try to identify some easy, open bugs beforehand. Have plans for how to solve them, files to look at, etc.
  • The first build is long. You might want to plan things accordingly, maybe having users set up a build before the bug-hunting starts.
  • Consider having attendees choose tasks/start investigating solutions while waiting for build environment setup. You can still use tools like MXR/DXR while the code is being copied, for example.
  • Consider pairing up attendees if one person's build environment will take significantly longer to set up than the other.

For appathons