In 2017 dgplug summer training will be happening for the 10th time. Let me tell you honestly, I had no clue that we will reach here when I started this back in 2008. The community gathered together, and we somehow managed to continue. In case, you do not know about this training, dgplug summer training is a 3 months long online IRC based course where we help people to become contributors to upstream projects. The sessions start around 6:30PM IST, and continues till 9PM (or sometimes till very late at night) for 3 months. You can read the logs of the sessions here.

The beginning

I remember looking at how people were trying to apply for Google Summer Code back in 2008, but many of them never had minimum experience with software development in Open Source world. dgplug started in 2004, and I think our motto “Learn yourself, teach others” is still as relevant now, as it was back in 2004. I was thinking about one online training where we can teach the basics of using Linux, and also basics of programming in Linux. How to create, and submit patches etc. I chose to use IRC as the place of the training because of bandwidth issue. Looking at how we conducted regular Fedora meetings on IRC, I was sure it would be doable. Of course there were many self doubts, too many open questions for which I never had any answer. When I shared this idea in different mailing lists, and asked for volunteers, Shakthi Kannan (irc: mbuf) also jumped in to mentor in the training. This gave me some hope. We had around 10+ participants in the first year of this training. Mailing lists guidelines, and how to communicate online were important from the beginning. Python was my primary language back then, and we choose to use that in the training too. With help from Prasad J. Pandit (irc: pjp) we had sessions on programming using C. But we found out that debugging segfaults over IRC was just not possible. We can try to do that if there were 2 or 3 people, but for a large group it was just not possible. As I mentioned earlier, contribution is the keyword for this training, we had other sessions than programming from the very first year. Máirín Duffy took a session on Fedora Arts, Paul Frields (then Fedora Project leader) took a session on Documentation. Debarshi took the sessions on shell scripting, and few of our sessions went up to 2AM (starting at 6pm).

Continuing & experimenting

Many participants from the 2008 session were regulars in the IRC channel. A few of them were already contributing in upstream projects. We decided to continue with the training. The number of participants grew from 10 to 170+ (in 2016). We did various kinds of experiments in between these years. Many of our ideas failed. Many ideas have gone through iterations until we found what works better. Below are few ideas we found difficult to implement in a training like this:

• Teaching C programming over IRC is not an easy task.
• We have to be regular in the sessions, start at the right hours every day. Changing session timings are bad.
• Do not give any longer break than 5 days. Participant rate will drop if there are no sessions for more than 5 days.
• Doing video session is difficult (even in 2016).

Lessons learned (the good points)

Start from scratch

Every year we start from scratch. There are always many participants who does not know much of command line tools, or how to reply inline to a mail in the mailing list. This is why we start from communication tools, basic shell commands, and using editors (we teach Vim). From there the sessions slowly start becoming more intense.

IRC works well on low bandwidth

IRC is still the best medium for a training where people are joining in from all over the world. It works in 2G connection too. Breaking the first entry barrier is difficult, but once we breach that, people generally stays back on the channels.

Stay in touch

Stay in touch with the participants even after the course is finished. Most of the regular participants in the #dgplug channel are actual ex-participants of the summer training. Some were trainees, some were trainers. Talking about other things in life is important to increase the participation in IRC.

Have documentation

We were slow in this point. Even though from the first year we had logs of each session, we never had one single place for the participants to learn from. Now we maintain a Sphinx docs. It is always nice to be able to point people to one link from where they can start.

Meet in real world

Every year we meet during PyCon India. This meeting is known as staircase meeting as we used to block most of the staircase at the venue in Bangalore. Meeting people face to face, talking to them in real life, sharing food & thoughts help to break many hidden barriers. It is true that not all of us can meet in one place, but we try to meet at least once every year. In 2017 we will be meeting during PyCon Pune in February in Pune, then once again in PyCon India in Delhi.

Give them hope, give them examples

Other than our regular sessions, we also get sessions from other known upstream contributors in various projects. They talk about how they have started their journey in Open Source world. Sometimes they sessions on their field. We had sessions from documentation, art work, experiences of past participants, Creative Commons licenses, leaders from various communities. This year Python creator Guido Van Rossum also joined in, and took a very interactive session.

Automate as much as possible

We now have a bot which helps the trainer during the sessions. This helps to reduce chaos during the sessions. As we all know the nature of IRC, it is very common that 10 people can try to talk at the same time. Stopping that was a big win for us. We still do not upload the logs automatically, as we go through the logs once manually before uploading.

Have a group of volunteers whom the community can trust

Most of the volunteers of dgplug are ex-participants of this summer training. They stayed back in the channel after their training is over. They help people almost 24/7 (depending their availability). There are the people whom we all trust. They become leaders by their own effort, no one comes and announces new leaders. Delegation of various work is important, getting fresh blood in the volunteer pool is very important. We constantly look for new volunteers. But at the same time you will need some people who can come in at the time of any emergency (with authority).

Enforce some rules

Rules are important for any community, call it Code of Conduct, or something else. But without these maintained rules, any community can get into chaos. Enforce these rules. We generally force people to write in full English words all the time (instead of sms language). The participants do pull legs of anyone who types u or r in the IRC channel. We also try to push people for inline reply than top posting in the mailing list.

Solve real life problem

Do not try to stay in only examples from books while teaching something. Always try to solve problems which are closer to the hearts of the participants. These solutions will give them much more encouragement than anything else. It can as small as finding photos in their computer, or building a full scale application to manage one’s video pool. We try to use Python to solve many of these issues, as we have experienced Python programmers in the channel . Python3 is our default language to do anything on the sessions.

Outcome of the training

I think we are the highest concentration of upstream contributors in one community in India. We had participants from Singapore, South Korea, to Afghanistan, Pakistan, to Nigeria (a big shoutout to Tosin), to many parts in US and Canada. We had school teachers, college students, lawyers, sys-admins, housewives, school students, music students, participants from various backgrounds in the last 10 years. We have companies personally inquiring about ex-participants before hiring them. Many of the participants are now my colleague in Red Hat. We have people in the channel who are willing to help anyone, everyone learns from everyone else. People are part many other communities, but #dgplug binds us all.