Code Cop: About Hackergarten

This page is not part of my Code Cop work. It is about the Hackergarten initiative started by Hamlet D'Arcy and Andres Almiray in 2010. As the Hackergarten wiki shut down recently, I decided to repost the content of the Hackergarten FAQ (Frequently Asked Questions) here.

What is Hackergarten?
Hackergarten is a Computer Programming Contributor Group. It is a craftsman's workshop, a classroom, a laboratory, a social circle, a writing group, a playground and an artist's studio. Our goal is to create something that others can use; whether it be working software, improved documentation, or better educational materials. Our intent is to end each meeting with a patch or similar contribution submitted to an open and public project. Membership is open to anyone willing to contribute their time.

Hackergarten (El Santo)

How to get in touch?

Official Mailing List
@Hackergarten and #hackergarten on Twitter.

How do the meeting looks like (for example do you have any standardised agenda)?
Not really, and maybe we need one. We start when everyone is ready and leave when done. Sometimes it is nine PM and sometimes it is one in the morning. Read more about What to Expect at Hackergarten.

What we will not do is give a presentation or tell you what to do. No one will be given an assignment or a role. If you feel like programming Java then join a small group doing that. If you feel like working on CSS and design, then do that. If you feel like becoming a leader, taking the white board and markers, and organising the group so that we work together better then I encourage you to do so! It is a time to come together, meet some new people, and try to create something for the joy of it.

How often do you meet?
Once a month. Also there have been Hackergarten during or after developer conferences.

What is the best number of people to keep on the productive level with one leading person?
Small groups. I would say minimum two (a pair) maximum 6. But at GR8 we had 50 people, which resulted in seven groups, and it worked fairly well. If two people show up then it is awesome - you make a friend, have fun, and make the world a better place. All groups should work on entirely different problems. Synchronising between groups is just too hard.

What are general rules for a Hackergarten?

Andres' Rule (first rule of Hackergarten): You make your own rules.
Hamlet's Rule: All work is done in pairs.
Hackergarten Vienna Rule: Talk is cheap. Coding is started within 30 minutes of the event whatever happens ;-)
No language is left behind as long as there is interest.
The goal is to submit something at the end of the evening.

What are best practises (for example mandatory prerequisites)?

Starting off with a 15 minute demo of the technology topic.
Project leads present their open topics in the beginning.
Picking a topic early.
Groups should work on entirely different problems.
Having the tools installed early.

Read also about best practises at this Hackergarten Follow-Up.

Is it reasonable to expect any viable outputs from the first meeting?
Yes. No task is too small. Try to do something very, very small. Fix Javadoc or do some small refactorings. If you are confident then write a small plugin. The point is to release not to just "work on some code". As your confidence grows (after one or two sessions) then you can work on larger things. Also, release something real. If you are only confident to write sample code then write really good sample code and make a blog post. That is real! I would love to see Hackergarten move to screen-casts, reference cards, and educational evangelism.

Is it a long-distant race - with all attendees needing to get into a target technology first?
It is whatever you want it to be, but I think the Basel Hackergarten has made Gradle a long distance race. Each week at least one group works on Gradle and this is good for the product and their skills. And at this point, some of the people are working on the project outside Hackergarten as well. But I still think the idea must come from the group, to fix/correct a small task and commit the code, all in one night. We want to walk away from the meeting saying "I am a contributor to GPars".

What should we avoid?
Here are some of the things that go wrong:

Spending too much time setting up IDEs. Having a pre-made .ipr file helps a lot.
Spending too much time messing with Version Control. For a four hour development project, emailing .java files back and forth is sometimes the best thing to do. Also Dropbox works well for sharing pieces of code.
Spending too much time talking about what we can do. I think you need to give the night a theme. "GPars", or "Gradle". Just "Meetup" is not enough. For the themed nights "special guests" who know the projects and have commit access are a plus.
Starting a too-large project.
Tasks not clearly defined, only vague ideas and then spending half of the time figuring out what to do.