Open Source/Mozilla hackathon

(Errietta Kostala) #1


As outlined in my participation leader goals, I’m planning to run an Open Source Mozilla hacking session at my University (the University of Huddersfield).

Since these are University students with variable experience, I want to make it easy to contribute - not scare them away :wink: I’ll try to pick js-based bugs from things like Webmaker and find good first bugs. I’ll make sure to provide step-by-step instructions for these bugs too, making it easier.

I wanted to ask if Mozilla can give any funding for the event? It’s okay if not, I just spoke to the Computing Society in Uni and they said it’d be nice to be able to give say free Pizza to lure students.

I also wanted to ask for any feedback/bug suggestions you can give for the session. Any ideas at all of how to make it better, let me know!


(Spike) #2

A great idea and a great initiative Errietta!
Are there any Mozilla Reps in your area that are able to help with a budget/swag request?

(Errietta Kostala) #3

All i can see from the participation leaders map is @alex_lakatos in the UK (hi alex! do you think you can help?)
Dunno how else to find reps :S

(Dinesh) #4

@errietta Mozilla Reps - Follow this to find reps near by you :smile:

(Emma Irwin) #5

Awesome Errietta!!

Two things that might help

The comments on funding - Reps yes :slight_smile:

Keep us up to date on how to help!

(Dinesh) #6

Very helpful guide :slight_smile: A small exception in open hatch is a broken link.
Here is the link:

(Andre Alves Garzia) #7


Congratulations and best of luck in your hackathon initiative, they are always a lot of fun. I have a couple bits of tips & tricks for you, feel free to remix them to your own context since what I will talk here is just my personal experience and these things vary a lot.

In my experience, the hardest thing for new developers in a Mozilla-oriented hackathon is finding documentation about a project. With our resources spread all over the wiki, bugzilla, MDN and Github, finding what they need in terms of docs and practices is usually harder than fixing the js bug. I will advise you to create a wiki or github page with links to all the documentation relevant to your hackathon. For example, when running a Firefox OS hackathon, we tend to place a page up with links to the MDN zone for Firefox OS, the Web API page, github samples and free books about the system.

Regarding documentation and other unique Mozilla things, its very good to have a group of facilitators there to help the competitors. Not to help them with their solution but to help them navigate all the mozillaverse and find what they need. More like tour guides. If you don’t have local community members that that can help, then you can try to arrange with our larger community to have people on IRC or other channel that can help your hackathon from remote. This is also a good first contact with the Mozilla community for the hackathon participants and if this goes well, they may want to join the community later.

Besides docs and facilitation, my last bit of advise is something you already know and plan to do, pre-selecting bugs before the event. You don’t want to spend time fishing for bugs during the hackathon, mostly because the attendees will be bored while you select something appropriate. Arrive at your event with a list of bugs from bugzilla or github and if you have the time, try to pair bugs with reference links for the documentation. For example, if a bug is related to touch, then link it with the touch event documentation.

A good hackathon in my opinion is not about the final products and prizes. It is about a group of people feeling empowered by completing a task from start to finish in a short amount of time. Its about the bonding between participants and a very good opportunity for presenting the mozilla mission to a larger audience.

This is an awesome goal and I think you are in a great path! :smiley:

(Alex Lakatos) #8

@errietta I’m in London and happy to help!

(Avik Pal) #9

Hi @errietta,

Best of luck with your initiative, just a few pointers I’d like to mention.

If you are targeting a specific product area you may ask couple of developers familiar with that project to help you out (remotely if otherwise not possible)- this increases throughput and impact a lot.

Hackathons are always a fun event to organise/conduct and seldom properly documented, so it would be great if you can document the whole proceeding (read bug metadata-assignee, mentor etc.).

Another important aspect is to give people the proper nudge to fix those incomplete/in-progress “ASSIGNED” bugs after a hackathon is over so as to have a continuous in-flow of new regular/steady contributors.

On other hand I once sorted several small/trivial js bugs for this very purpose [bug squashing]- If you need few let me know.

(Leo McArdle) #11