Open Source isn’t just about code – other ways in which you can contribute!

Talking to developers and reading about open source I often get the feeling that the general notion is that open source is just about code and commits. Put another way, “If you don’t make commits for a project you are not contributing to it”. Or so they say. That notion is far from the truth in my eyes. Let me tell you why.

Sure, code is what ultimately ships and has a direct impact on the users of an open source project, so yes commits and code are important. But it’s by no means the only way you may contribute to a project. Projects mostly are a whole eco system, which is about more than just code. Here are a couple of other ways you may contribute to a project.

Report issues

If maintainers don’t know about issues they can not fix them. Therefore, it is crucial that you report issues you encounter and not just abandon using the project or only build a workaround. Most projects are happy to receive issue reports. Don’t take reporting issues lightly either, often a substantial amount of time goes into writing a good issue report. Ideally an issue report contains code to reproduce the issue, information about the expected outcome and the actual outcome, system information, version information and maybe a stack trace or similar artifacts. I also like to include a little note of appreciation for the maintainers, but that’s optional. Keep in mind that issues don’t have to be about bugs – they may also be about possible improvements or desired features. Github even acknowledges the importance of issues by giving you contribution points for opened issues – yay!

Write Documentation

Documentation is extremely important but often lacking, as a lot of people really don’t enjoy writing it. It’s a great way to help a project out by making it easier for other people to get into. Also if you found it hard to get into a project, try improving the documentation so the next person will have it easier than you did. I actually have commits on ruby – they are all documentation commits 🙂

Improve the website

Many open source projects have their own websites. Sometimes the information is outdated and sometimes it’s just plain ugly. I remember the old shoes website – it was really ugly and looked dead (at least that were my thoughts when I first saw it). But look at it now! It looks nice and presentable. And most of it is thanks to wpp – he has never pushed a commit to shoes (that I am aware of), but this certainly was a great contribution for shoes.

Offer to help with art/design

A lot of projects would love to have their logo updated, get some illustrations for their website or similar thing. So if design or illustration is your thing, maybe go to your favorite project and ask them if they want some help with that? I know I’d be more than happy about that!

Trying out preview versions

Developers need feedback if their software works. Therefore, alpha, preview or release candidate releases are made often. Go grab one of those and try it out. If everything works – great, you just made sure it works on your system! If you find a bug – report it! That’s a great help for the project.

Weigh in on Discussions

Sometimes there are discussions about API changes or ways an implementation could be improved (among other things). Comments are very welcome there, maintainers want the input of their users. I once spent a whole day discussing some architectural issues I identified in a project. It was fun. Other work might be setting up a road map – Eric Watson did that for Shoes 4 one day. He’s a great coder, but that road map helped the project more than any code he could have written in a similar time frame. His road map went on to be a very helpful guidance and reference point.

Answer Questions

Questions about a project pop up all around the place. Be it stackoverflow or just the project’s issue tracker. By answering them you help other people to get a better experience with the project overall. Also don’t forget that a question might hint at a problem with the project. Maybe the documentation for this part could be improved or there is a common task that might be automated or deserves a better API? Maybe you could jump in to do this?

Give a presentation about a project

There are many great projects out there, but developers may only adopt them if they know about them! If you really like a project, consider giving a talk about it at a local user group or handing in a talk for a conference. This way the adoption of the project may be increased, bringing more people to the project making it a better and more stable product overall – benefiting everyone.

Closing

If you already have done any of the above: thank you! You contributed to open source. Keep doing that if you like, if not give it a shot. If you want to get started on contributing to open source, this post of mine might come in handy. Personally contributing to open source has been an amazing journey for me so far. I enjoy it very much and have made quite some friends that way :).

How to get started with contributing to open source

I often see people who really want to contribute to open source projects. And that’s great! But often it’s not easy to get started. “What project should I contribute to?”, “What can I do on that project?” and “How does contributing work?” are common questions. It can be scary. I found myself in the same place around 3 years ago. Since then I contributed to a variety of open source projects and am heavily involved in a few (including my own projects). This post is here to answer these questions, give you some help, guidance and share experience.

Step 1 – Find a project

“Where to start?” “Which project can I contribute to?” These are usual questions. The most important principle here is “Scratch your own itch!” – work on a project that you use and that matters to you. There is no point in investing energy into something you don’t care about. Even better if you have a specific issue with a project: some odd behavior, a bug that you work around, a sub optimal API, lack of documentation… you name it. If you use some projects you’ll find a couple of those. I guarantee it – nothing is perfect.

Also try to see if the project isn’t too far off your comfort zone – e.g. if you are a ruby programmer and don’t know much C then contributing to a gem which is primarily a C-extension is probably not the best idea.

Have a look at how active the project is. You’ll want to contribute to a project that is still actively developed and where the maintainers react to issues and pull requests. For this you can look at a couple of things: When was the latest commit made? Look at the recent pull requests and issues: Did anyone comment on them? Is there a crazy amount of open pull requests, some of them like half a year old without activity?

Another advice: Try not to contribute code to a really big project (think: rails) straight away, especially if you are a beginner. Those projects are… well… big. It’s often hard to find the right place where a fix should occur. Familiarizing yourself with the code base unfortunately takes a lot longer as well. Also due to their nature, they often have a lot more issues and pull requests that the maintainers have to take care of. Often that results in longer feedback cycles, somebody else trying to fix the same problem and it diminishes the chance of making “a real impact”. It’s not the ideal scenario for first time contributors in my opinion. With small to medium-sized projects I often experienced that maintainers are a lot happier to get contributions and faster to respond.

Step 2 – What to work on?

If you’ve got an itch you want to scratch you are already mostly ready to go. But first make sure that the problem persists even in the latest release of the software (even better on master). Then search the issue tracker of the project to check if the fault has already been reported. If not, report an issue (or feature request) to see if this actually is a problem/a wanted feature. In the best case you provide a small sample script demonstrating the error along with an expected behavior from your side. You can already mention that you’d like to work on this.

If you don’t have an itch to scratch but a project you’d love to help out: have a look at the issue tracker. Some projects feature tags/categories for newcomer friendly issues – check those out first. Otherwise look for something that seems appealing to you and not too complex.

I want to stress that contributions aren’t limited to fixing bugs and implementing new features. Helping out with documentation is very valuable, that’s how quite some contributors get started. Also writing tests to increase test coverage or refactoring code (hint: some projects use Code Climate – you can check out code smells there) to remove duplication/make it more readable is often very welcome. I especially recommend the latter two as to do this you have to understand the code and therefore get a good first view of the code base without having to add anything.

Make sure to have a look at the README of the project. It often highlights how to figure out what to work on and which kinds of contribution are welcome.

Step 3 – Get your changes in!

Mostly you should make sure that there is an issue for what you want to work on (exceptions include small refactorings). In that issue comment that you would like to work on the problem, maybe outline a strategy to solve it if you already have one and ask for pointers and advice how to go about that issue.

Also look at the README – a lot of projects mention how they’d like contributions to be handled. Also they might have references to style guides or guidelines such as “provide test cases that fail”. A lot of them will also have instructions like these (at least on the most popular platform these days, github):

  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request

Forking is basically creating your own copy of the repository which you can write to. Creating a Pull Request is like saying: “Hey, I made these changes do you want to have them?” In a Pull Request the changes are discussed, commented  and it’s basically the way to get your changes in. I recommend opening pull requests early – as soon as the basing building blocks are standing. The feature doesn’t need to work yet. This way you can get valuable feedback about whether this is the right approach as well as hints and tips leading to the right solution.

Closing Notes

Have fun contributing to open source! There are a lot of nice people out there happy to get contributions of any form. And I can tell you – it’s a great feeling to know you made something better for a lot of people (including yourself!). You might have seen an occasional story about big discussions or fights in pull requests/issues. Please don’t let that scare you. I can tell you that from my experience these are the exception not the rule. Most people in open source are really nice and work together for a common goal. Two and a half years ago I started contributing to the Shoes project. To this day this is the nicest online community I ever met with a lot of really helpful and polite people around! I stayed with the project ever since – gradually increasing my contributions.

I hope this post helps you to get started on your journey into the open source world. If there is something missing or you got more questions please feel free to add a comment.

2n edition of HU course – with blog and material

Hi everyone,

today was a great day! Today was the first day of the second edition of the course about the basics of web development I’m teaching at Humboldt University Berlin. I had a great deal of fun and am already looking forward to next week.

Anyhow, the course now has its own blog where I share presentations, homework etc. The course is held in German only, so the material is only German as well. The course is aimed at total beginners (e.g. minimum requirement: “You should know how to use a computer.”).  When looking through the material please keep in mind that it is not made for self-study – it is made to be presented. Also it is for real beginners and therefore sometimes makes abstractions/simplifications for the sake of productivity.

So without further ado, enjoy the blog: webanwendungsentwicklung.wordpress.com

Cheers,

Tobi

8 ways to enable workshop attendees to keep learning

Workshopping
A Rails Girls workshop (Photo credit: Kerstin Kollmann (CC) NC-ND-BY)

There are many great movements out there teaching people how to code: Rails Girls and RailsBridge among the most prominent. Those movements host free workshops with a superb coach/student ratio to get more people into coding. However there is one problem: How to keep on coding? After the workshop the attendees are mostly on their own again, but we want them to continue! How can we do that? Here are methods we use in Berlin, that I hope can help other movements, subgroups and organizations to keep students engaged.

1. Project Groups

At Rails Girls Berlin we have project groups. These groups are usually formed after the workshop on the mailing list. Someone can suggest a project to work on or just join a project group. Project groups usually are supported by one or two coaches and have 4 to 8 students. Of course there are bigger and smaller groups. You then meet (usually) every week for a couple of hours to work on the project or talk about concepts. As once a week is not a lot there often is some kind of homework.

This concept has been very successful for us. I know of 8 project groups running right now, but I’m told there are ~12 of them which is amazing. Our first project group, the RubyMonsters, have been working as a group for roughly a year now. They already finished their first app and help coach at Rails Girls Berlin events now 🙂

I also heard of similar groups spontaneously forming in Poland after workshops, which made me really happy!

2. Advanced Workshops

At Rails Girls Berlin we often also let advanced applicants join the workshops (we have a workshop about every one to two months). Advanced meaning that they already visited a workshop or have other programming experience. They get their own groups and don’t follow the normal curriculum but rather work on something of their own (with the help of a coach).

We also sometimes host workshops solely for more advanced learners. I spent one such workshop with an experienced Java developer from Brazil talking about differences between the Rails and the Java world. It was a lot of fun!

3. User Groups

We try to encourage the attendees to attend user groups. Here it helps if they already know someone at the user group, e.g. a coach or an organizer. With us I organize the Ruby User Group Berlin and many coaches go there regularly too. Sadly we didn’t have too much success attracting learners to join us, but those that did, always told me that they liked it a lot 🙂

However there is something more suitable for learners: A user group for beginners! Our friends from Open Tech School have just the thing: The Learners Meetup. This happens once every month and there are learners and coaches present. The coaches may introduce themselves and the technologies they are familiar with.  Then there is a talk about a basic programming topic suitable for beginners.  After that there is a break and people can write down topics they are interested in on cards. Then the different topics are clustered and groups for discussions about those topics are formed. I really love this format and the event.

4. Informal Meetings

Project Groups are great, but they have a drawback: A couple of hours per week at a specific time isn’t really flexible and too much for some. Some also prefer to learn on their own, but how to get help when things aren’t going that well? Well that’s what informal meetings are for. Those are meetings where anyone might drop by and work on something or ask questions. You are mostly not guaranteed to have a coach around but learners can help other learners. And mostly you can check beforehand who is there and then see if someone may help with the problem you’re having. Open Tech School has the Learners Hangout every Saturday, which is a brilliant place to go. And in the future I want to try to establish a regular schedule where you can be certain that a coach is present.

5. Show them resources

During the workshop present some good resources to deepen the knowledge of whatever you taught in the workshop. That might be websites, books or user groups to go to. I think this is most fitting at the end of the workshop. Also make sure to publish that list online so attendees can refer back to it later and don’t have to write everything down. I have such a list on this blog myself.

This might be pointing out the obvious, but it’s important nonetheless.

6. A Summer of Code

You might have already heard of Rails Girls Summer of Code – it’s a worldwide program started in Berlin. The idea is to get more woman into coding – or rather further into coding when you continued after your workshop. It’s 3 months, full-time, paid, work on open source and students get supported by coaches and mentors. It’s an amazing program. And we’re still looking for some sponsors – so if you’re willing to help and want to allow us to accept more students please donate. And thanks a ton to all our sponsors so far!!!

7. Have former attendees coach at a workshop

When a former attendee of the workshop continued to code (which we hope!) then it is a brilliant opportunity to let them coach at a workshop. This works beautifully in three ways:

  1. Motivation for attendees: Attendees love to meet someone who has been down the same path before. When we had our lovely Ruby Monsters project group coach with us for the first time a record-breaking number of 3 project groups were founded afterwards. For me that’s the primary measure of success – the people we convince to keep on coding.
  2. Affirmation for former attendees/new coaches: They see all the things that they have learned, up to the point where they can help others learn which is an awesome feeling. Moreover teaching is the ultimate learning (a topic deserving of a blog post of its own…) – explaining something forces you to really understand something and often times leads to looking at things from a different angle which greatly benefits your own learning.
  3. Better coaching: Former attendees remember pretty well, what it was like as a beginner as this hasn’t been too long ago for them. Therefore their explanations often work very well.

See – everyone wins!

I at least know that in Poland they did the same, where former attendees are now coaches which is amazing. At Rails Girls Berlin when we did this for the first time we paired our new coaches up with an experienced coach in order to have a good mix of experience levels for coaching.

8. Share your learning story at the workshop

It is extremely cool to have someone at a workshop who taught themselves how to program. They can share all their insights and tips. Attendees can really relate to a talk like this as well as the person. You might also tell them, that sometimes learning to code is hard, sometimes it’s fun but in the end it’s worth it and a lot of fun. Tell them that it’s ok to make mistakes and that even the most experienced developers resort to search engines more often than you’d think.

Our Ruby Monsters often give a lightning talk about their story of learning in a project group at our workshops. And regularly Joan Wolkerstorfer also tells her story and gives tips. You can watch her talk about this and read about it.

When talking to attendees weeks after the workshop and asking them why they kept on coding meeting someone who has done it and hearing their story is almost always mentioned first.

A lightning talk is also an ideal time to introduce git or github, as these tools enable you to cooperate with others on your project! And we all know that working together with others, building something together, is a great motivation!

Conclusion

There are lots of ways to motivate workshops attendees to keep on learning. These are ways that worked for us or that I think work. Do you have other ideas how we can help people to keep on coding? Have you tried something? I would love to get some input! As a result of initial comments this blog post already grew from 6 to 8 ways 🙂

A Rails Beginner Cheat Sheet

Hi everyone,

during the last week I spent a large amount of time creating a Cheat Sheet for Rails beginners! So, here it is: http://pragtob.github.io/rails-beginner-cheatsheet/

I originally started creating this cheat sheet for my awesome Rails Girls Berlin project group. But I figured and hoped that a lot more people would be interested in this 🙂

So far this cheat sheet covers the following aspects:

  • Command line basics
  • Ruby basics including (Numbers, Strings, Arrays, Hashes)
  • Rails basics including a description of the folders and commonly used commands (like starting the server)
  • Tips about using an editor
  • Information about where to get help

So also feel free to check out the repository and especially the open issues – I would love feedback on many of them! And contributions are also very welcome!

Cheers, hope it helps you + keep on learning,

Tobi

Teaching a course about web development at Humboldt University

Hello everyone,

just a quick note but I’m extremely excited to finally announce that I will be teaching a course about the basics of web development at Humboldt University Berlin. The course is meant for bachelor students who don’t study computer science. It’s a total basics course, no prior knowledge required. The course will start with basic HTML and CSS, then we’ll get into some Ruby and then some Ruby on Rails. So in short, it could be perfect to be the start of your journey into Programming. And a useful skill to have, in the spirit of this awesome video.

The course will be every week on Wednesday for 9 weeks (starting in May) for ~5 hours + breaks. The course will be held in German. The course is limited to ~14 students.

Link to the full course description (German)

If you are a student interested in the course, feel free to get in touch with me for questions etc!

In the end, a big thanks to everyone who helped making this happen! Especially Dajana 🙂

Cheers,

Tobi

Slides from the Febuary 2013 Rails Girls Berlin workshop

Hi there,

So here are the slides from my talks from the Rails Girls Berlin workshop on Saturday, in their chronological order:

Introduction to web applications (the one with the map)

I love programming

The slides are Creative Commons Attribution license – so feel free to share and modify them but say where you got them from 😉

And as a little bonus I was allowed to post the beautiful Rails Model View Controller comic drawn by Anja of our Ruby Monsters project group – the comic is Crative Commons as well if I understood her right!

mvc1

mvc2

Cheers,

(green) Tobi

By popular demand: recipe for the cookies from the Rails Girls Berlin workshop

Hello everyone,

for my talk on Saturday I prepared cookies. Apparently people really liked them (yay!) and I got quite some requests for the recipe. It’s kind of a family recipe but I guess my grandpa is ok with me sharing it 🙂

So I translated the recipe to English – as good as I can – it follows in German afterwards. And at the end of this post there are some photos of me making those cookies this march (back in Sweden) – maybe it helps you.

The recipe (English) – short crust cookies

Spoiler:  My baking English isn’t really good.

Basic ingredients

  • 500g flour
  • 250g butter
  • 150g sugar
  • 2 eggs
  • a pinch of salt
  • 4 packets vanilla sugar
  • bitter almond aroma (Bittermandel Aroma) for 500g flour (I usually use a bit more 😉 )

additional ingredients (for the dark part)

  • 40g cocoa
  • 50g butter

general instructions

Use the basic ingredients to make the dough. Knead the dough thoroughly. Then halve it and add the additional ingredients to one of the halves – knead this one extra thoroughly. Leave the dough to chill for approximately 30 minutes. Roll both doughs out to roughly equal size (and ideally shaped like a rectangle). Then put one dough on top of the other (I usually put the lighter one on top of the dark one) – here you may roll them out a bit more. Then coil them up. Keep rolling and halving until the rolls have the size you like. My grandpa goes for a diameter of 7cm – I take less. When the rolls are done you should leave them to chill (e.g. fridge) for about an hour. Afterwards you should make approximately 1cm thick slices and put them on the baking sheet.

My grandpa gave me these rough guidelines for baking them:

  • temperature: 225°C
  • time: 12 mins

or for air circulation:

  • temperature: 165°C
  • time: 25 mins.

The most important rule though is the following: COOKIES SHOULD NOT GET BROWN! which often is quite hard to accomplish. Sticking to the guidelines never worked for me – frequently checking them did.

Pro-tip: I always use at least 4 times the ingredients of this recipe. If you do so it’s much easier to make 2 separate doughs (light and dark one) from the very beginning. And the roll them out and put them on top of each other part also gets so much more fun!

Rezept (Deutsch) – Mürbeteigplätzchen

Grundzutaten

  • 500g Mehl
  • 250g Butter
  • 150g Zucker
  • 2 Eier
  • 1 Prise Salz
  • 4 Päckchen Vanillezucker
  • Bittermandel-Aroma für 500g Mehl

Teig schnell und gründlich kneten. Dann halbieren und eine Hälfte mit 40g Kakao verkneten (etwa 50g Butter sollte zusätzlich noch mit geknetet werden). Beide Teige ca. 30 Minuten kalt stellen. Danach beide Teige ausrollen, übereinander legen, leicht andrücken und zusammenrollen. Teig weiterrollen und dabei lang ziehen, sodass eine Rolle von ca. 7 cm Durchmesser entsteht. Die fertigen Rollen ca. 1h im Kühlschrank kühlen und dann in ca. 1 cm dicke Scheiben schneiden und mit entsprechendem Abstand auf ein Blech legen und backen. (PLÄTZCHEN DÜRFEN NICHT BRÄUNEN)

Fürs Backen gibt es diese ungefähren Zeitangaben, bei mir weichen diese aber leider teilst drastisch ab. Deswegen empfehle ich oft nach den Keksen zu gucken.

  • Backtemperatur. 225 Grad Celsius
  • Zeit: ca. 12 min

 für Umluft:

  • Temperatur: 165 Grad Celsius
  • Zeit: 25 min

Protip: Ich mache meistens die 4-fache Menge an Keksen, da macht es sich dann auch besser wenn man den hellen und den dunklen Teig von Anfang an getrennt macht. Das übereinander legen macht so auch gleich noch ein mal viel mehr Spaß 😉

Photos

Here some photos from my kitchen back in Sweden this march of me making those cookies – enjoy. And before you ask what the beer bottle does there – it excels at behaving like a rolling pin. One of the first things my grandpa taught me. Yeah, poor students.

This slideshow requires JavaScript.