Wikimedia Hackathon for Newcomers
Thoughts on the mentoring program at last year’s Wikimedia Hackathon in Vienna
Last year the Wikimedia Hackathon took place from May 19 to 21 in Vienna, Austria. Angela, Renate and Jackie took part in it, all of them as some sort of newcomers with very different backgrounds. We had a great time, and somewhere along the way we started discussing our experiences with the mentoring program and the hackathon. We talked about how much it helped us to become part of the event. How it really did make us feel welcome and cared for in the movement – thanks to the community, the organizers and coordinators Claudia Garád and Sonja Fischbauer and the other newcomers.
This text talks about our ideas on continuing the program and maybe adapting it for future events. Throughout the hackathon we sat together to reflect on this, and afterwards we took some time to distill our thoughts into this article. It went through several long-phased iterations of reflection and rewriting, so all in all it took us nearly half a year to come forth with it. Nevertheless we think these thoughts are important. So we want to share them because supporting newcomers is not only a good thing on its own, but it adds to the diversity and innovative nature of the whole project. And we could not write this without all the great people and processes already in place to welcome newcomers into the community – because this encouraged us to add our first-hand experiences and try to improve these processes.
In the first section we will reflect on different kinds of newcomers and how they could be encouraged. Following that we will make a few suggestions what we could do to improve and add to the existing measures to support newcomers. In our conclusions you can find a compilation of useful steps we came up with.
What’s the new in newcomers?
When we try to encourage newcomers to join our cause(s), we usually have an image in our minds already – We have an idea about who they are, and what they need to be encouraged to. This then shapes our actions when we try to engage with them. Based on those assumptions, a great many tools, processes and initiatives have been set up to help newcomers get started with MediaWiki and all the other things in the Wikimedia ecosystem. Yet, we feel that we are often really good at addressing certain groups of newcomers but not so good at reaching out to others. So what is this all about? What differences are there anyway?
There seems to be a tacit little assumption that newcomers are coders already. At least they can code, or are developers even before participating in Wikimedia projects. They just might not have coded anything within the Wikiverse. So they are new to Wikimedia and the different projects in this ecosystem, but not new to coding and working in FLOSS projects. At least this was the impression we got from the first session for newcomers at the Wikimedia Hackathon 2017 in Vienna. In this session all mentors presented what they (usually) do and what they can offer their mentees. A few of those mentors said they could help with the basics to get their mentees started on actual projects. But as a newcomer in this session, you mostly heard a lot about many different small or big coding projects and stuff that sounds interesting – but you also might have felt that you would basically have to “be fluent” at least in PHP or Python. And this seemed to work out great for many newcomers – for those where all the assumptions explained above were true. Only for some it did not do the trick yet of encouraging them to start at any particular point.
So, maybe our assumptions about established coding abilities of newcomers are true for (e.g.) 60% of the newcomers. Then there are still maybe 20-30% who might want to learn concepts of coding, code review and (code) project management – before hacking around on stuff. And then there might be 10% of the newcomers who do not want to learn to code at all – at least at this specific event. Maybe they want to bring in their not-coding-related skills (that could be designers, social scientists, activists, project managers and a lot of other people with skills needed for developing software projects that are not hands on programming). Maybe they are planning on contributing code and just want to get the atmosphere and listen to talks and talk to people first. Some people need social interaction before they spend time on a project. The concrete percentages here are assumptions too of course, but the purpose of this is more to make a point than to map demographics. The question is: Do we want to encourage those who do not fit our initial set of assumptions? And if so, what can we do to successfully include them like we do with those newcomers who already know how to code and work on FLOSS projects?
Just imagine you were new to the Wikimedia ecosystem, but you basically know how to code (or at least how to learn it) and you already have seen tools like Git, Gerrit and the like. In this case the whole mentoring thing might have worked super fine, because you could choose an area you want to go into and then really get good support and hints where to start and what to do. But in this case you already know the questions you need to ask.
On the other side, imagine you know coding is a cool thing but you never really tried it. You also don‘t have any experience with (free) software project management and maybe you already heard that Git and Gerrit and the like are the coolest tools of the trade. But you have no clue how this might actually all work out. And then you also just learned or only know that MediaWiki is the great software behind Wikipedia – which you regularly use and where you have maybe already tried to edit some articles. But that’s all at the point where you go to the hackathon. You don’t know about the huuuge amount of other projects in the whole Wikimedia ecosystem, or how this enormous network of project really works. Nor you do have any idea about how communications, hierarchies and helping structures in this ecosystem work. In this case it is quite hard to even get what it is all those mentors work on and what they can provide you. You don’t even know where to start and what to ask to get started, because this already is a little bit overwhelming. And then – on top of that – you see a lot of other newcomers quickly adapt and start coding on some project and finally you feel a little bit stupid and not quite in the right place. So you hang around and talk to people, but never really get into doing some “real” stuff with code, or documentation or project work – although this was your primary aim when you decided to go to the hackathon – especially because it was announced that there will be a special program for newcomers. So maybe, despite all the efforts, there are some things missing for you to feel welcome as an absolute beginner. Who or what could help you through this jungle of informal information, your own uncertainty and questions of how to balance life, coding and work or studies? Wow, that’s a lot of stuff we didn’t think ourselves before we went to this hackathon. So we don’t see this as a failure, but more of a missed opportunity to support “high potentials” who we are missing out so far.
In the following chapters we want to make some suggestions how to improve or add on the otherwise already great initiatives to encourage newcomers.
Dedicated newcomers area and newcomer advisors
Feeling lost is never helpful (or should we say powerful): Maybe a huge event offering mentoring for newcomers should provide a dedicated newcomers area. One that’s always there, besides the session where mentors present their ideas and some (or even most of the newcomers) match themselves to one or another mentoring group. So the newcomers area would be independent of the mentoring program – a place in the lobby maybe, where you always can find other people who are maybe as clueless as you and some people who really know how to get you started with whatever you might be interested in doing. Also some newcomers might not be looking for mentors, but more for a place to hang out. Of course in the newcomers area, mentors should be present too, offering at least small talk opportunities – but in this area the task of the mentors is not to present and work on their projects but to help newcomers find out what they want to do and what the next steps in that could be. You might want to think of it as guidance rather than specific instructions.
Newcomers (you might remember your own first steps at anything that initially seemed complicated to you) also sometimes just need encouragement to talk to “experts” or to just join an existing group sitting somewhere. And this too could be a task for those mentors who are currently in the newcomers area. Or maybe there are dedicated newcomer advisors. You could of course ask now if this isn’t what the mentors are doing anyway. In our experience from the hackathon in Vienna the mentors do really good work, but they are of course tied to specific goals and projects, because they too only have limited resources for so many good things we could do here. And that is what is good for many newcomers – getting in contact with real coders in this project. But others need a more general guidance. And to do that a mentor has necessarily to set aside ones own interests and areas of expertise. This is not tied to specific people and what they do, but it is a decision on which role and function I want to take for the course of this specific hackathon. We think this would be one nice thing to try out at a future hackathon.
Or maybe, this area (and more generally mentors who are there to connect and engage rather than introducing specific projects) could even be used for another sort of exchange: Coders and non-coders alike, everyone attending such a hackathon does that because they have something they can contribute. And we noticed that a lot of teams are looking for help that doesn’t require coding once in a while: A pair of fresh eyes, feedback for their new interface, design help, and so many other things. Assuming that all the newcomers have something to contribute, why not ask them to help out? Trying out a new app could be a great way for a newcomer to get in touch with people who are more involved already. And those who don’t have a project of their own (yet) usually have plenty of time to spare for impromptu consultation or testing. The hackathon in Vienna had a board where people could look for skills or help – maybe this concept could be extended in a way that connects newcomers to projects in a more explicit way?
Presentation and Getting in Touch – The First Meeting with the Newcomers
The mentoring project for the Wikimedia Hackathon in Vienna had an introductory meeting. On the first day of the hackathon, mentors introduced themselves, presented their projects, and everyone got to know each other. This was a great start because everyone could see who was involved in the mentoring project and get a feeling for the group. This meeting took away a lot of the awkwardness of ending up at an event as a newbie all by oneself, and we have compiled a few tips that seem helpful to make starting a conversation as easy as possible:
Every mentor at the introductory mentoring meeting had a poster where they wrote down their name, project and contact info. This was really helpful.
When people are presenting an idea/project, they should have some visual contact infos (The posters at the mentors/newcomers meeting are a great example, but having contact information readily available can be helpful on many occasions such as the opening session)
E-mail as universal medium: It’s cool if people use IRC nicks or Telegram contacts or Twitter handles on their posters/slides, but they always should put their e-mail address up there as well. Everyone has an e-mail address, and it helps to be able to use a familiar medium for communication. IRC isn’t a very welcoming medium for newcomers especially when they might not be familiar with/intimidated by the specific communication tools that are traditionally used within the community.
Now that we have offered some thoughts on the execution of the mentoring program during the event, we want to discuss the (mostly invisible) efforts to prepare the mentoring program in the months leading up to the actual hackathon.
Pre-Hackathons and other Events before the Main Hackathon
The organizers included two pre-hackathon events for newcomers, about one month before the actual hackathon. These events were aimed at people who would like to engage with MediaWiki or other technical parts of the Wikimedia ecosystem. The initial invitation was for people who wanted to “learn to code with MediaWiki”. In the end we had two fully booked workshops where people started together by setting up their own MediaWikis and then venturing into code or other tech-y stuff. They were guided by some mentors whose job it was to have an eye on what people needed, and help them to get started. At the end of these workshops some people where happy to just have installed their own MediaWiki, while others played around with extensions or had started coding bots.
These pre-hackathon events were great and also encouraged some people to participate in the hackathon. They worked as an introductory newcomers event which prepares for the participation in the hackathon. While we would keep this for further hackathons, it might make sense to (additionally) have a newcomers intro event in the evening before the hackathon starts. The goal for this event would be a general overview for newcomers: What are the projects? How are they organized? What skills do I need to participate?
A short programming crash course would, of course, be interesting as well. But this is definitely too much for a single evening event. Maybe we could have an afternoon of coding and the evening as an overview and intro to the Wikimedia ecosystem.
Preparation for the mentors
So far, we have discussed a few points for the event, and how to accommodate for newcomers in a conference space. But in order for things to go smoothly, the mentors need some attention too. After all, making the mentors feel confident about the project might be the most important first step for a successful mentoring program. We think that the first mentor meeting should be scheduled before the hackathon starts. In Vienna, there was a meeting where all the mentors met and prepared for the hackathon at the day before – which was a great idea, but had a few scheduling issues. This first meeting should be scheduled way in advance, so that the mentors can consider it early on when planning their travels – it would be perfect if all the mentors could participate. Again, required skills (skill levels) to participate are an important thing for mentors to discuss and reflect on when planning their projects (e.g. “I have tasks that involve no coding”, “I have tasks where you should have written a few lines of code before”, …). This should be made visible to hackathon participants later on, but it is important to discuss it at the mentors meeting beforehand. That way the implicit assumptions about newcomers become visible, and we can ask ourselves: Are we able to provide projects/input for all sorts of different participants? And in case we have a strong coding-focus, it could help us to figure out if some mentors could find into a more general support role. And this could be also a chance for mentors to improve their knowledge on tools and methods for how to be good learning coaches.
The mentoring program is an effort to be more inclusive as a community, and attract new participants. A lot of the points we raised above are very specific to a hackathon/tech conference. In the following paragraphs, we want to offer some more general thoughts on communication and inclusion:
Men (in fact, everyone) should be made aware that “mansplaining” is a common issue, something that makes a lot of people uncomfortable. While the term mansplaining connotes a gender imbalance, it’s essentially about behavior – not about gender. Nevertheless, in tech circles this is something that happens a lot. And it happens a lot more frequently to the few women who dare to venture into a male-dominated culture of expertise. It might be more helpful to think about it in terms of geeksplaining, as the geekfeminism wiki suggests: “a geeksplain is when person A explains something to person B from first principles despite A not knowing B’s expertise level, or even if A knows that B is an expert.”
It is basically about the assumptions we make when we engage with others, especially when we talk about technical stuff and try to explain things. For instance when you think the person you are talking to is utterly clueless. You just assume that they lack even basic tech knowledge and subsequently ignore everything they might already know. At the same time you are somehow the “expert” because you are inside the hackathon community already – while the other person just tries to find out how to fit in with the knowledge they already have. In this case – no matter which gender either of you associate with – it is extremely discouraging for the newcomer to try to ask more or to open up to others. Because you denied their claim to have valuable input they can bring in to the hackathon right away. Statistically women are the major target of this behavior usually displayed by men, which is the reason for the term “mansplaining” that’s most commonly used.
So we should create awareness about types of behavior that could be experienced as geeksplaining/mansplaning that exist, and how to avoid it. For some it might be a personal challenge – but it´s worth it! Empower those who don’t believe it yet, and know that this is a skill that can be learned just like everything else.
This could be fostered in the same casual way mentors in tech contexts are often instructed to not ever touch their mentee’s keyboards. The pre-hackathon mentors meeting, as suggested above, could be a good place to discuss this too. Mentors also have a kind of agency when it comes to the culture of the whole hackathon. But of course, all participants in general should be made aware of such issues beforehand.
You guys are not alone, dude!
Being welcoming to the widest possible group of individuals sometimes starts with language: don’t address everyone with “guys” and sensitize participants for this topic. It might seem like a small thing, but putting in the effort shows clearly that the organizers care. While this was not a super huge issue at the hackathon, we encountered it regularly and often enough to realize most people haven’t thought about it yet. So this is a point where it might be easy to further improve on inclusiveness of Wikimedia Hackathons. An excellent read on the “how” and “why” of this issue is this short article at the Subfictional Studios Blog: https://subfictional.com/language-matters-stop-using-guys-to-address-mix-gender-groups/.
In the two months before the Wikimedia Hackathon, we also had the PyDays Vienna, and DjangoGirls Vienna here in town. For those events, information material about being inclusive was sent out to all participants in advance (with all the other info they got anyways). Some speakers even started to correct themselves and address people as people and not as guys, which made for a more inclusive atmosphere. Of course tackling this problem is especially tricky in male-dominated tech contexts – but that makes it all the more relevant.
This year’s Wikimedia Hackathon was a great opportunity to encounter and partake in the experimental newcomer program (either as mentors or as participants, one of us was both). We thought, and still do, that this was an amazing idea. The hackathon organizing team in Vienna and elsewhere put a lot of thought and planning into making the event welcoming as well as accessible for new participants. This has encouraged us to put even more efforts into encouraging newcomers to join the Wikimedia community and to start hacking things themselves. And it also encouraged us to put more effort into encouraging everyone to support newcomers. Inclusion first! There are several good measures in place already: doing pre-hackathon events, having a mentoring program and a lot of supportive mentors, giving the mentoring program a lot of visibility, and generally working towards a relaxed atmosphere. We want to close with a short compilation of what we think are useful tools to encourage newcomers to become an active part of the community and feel accepted here.
This list includes a lot of the great ideas from the hackathon in Vienna and some ideas we came up with during the hackathon:
Have a dedicated newcomers area and some newcomer advisors – Feeling lost and out-of-place is often the biggest fear for newbies.
Be aware of and reconsider your expectations: not all new participants come with the skill-set we might (subconsciously) expect to find in them. This is not a bad thing, but keeping different background and abilities in mind helps to be inclusive.
Organize pre-hackathon events and other events before the main hackathon where newcomers can get to know the community and potentially each other.
Organize the mentoring program in advance and have a pre-hackathon mentoring meeting scheduled early on.
Provide guidance for presenters and mentors to provide good cues so newcomers and other people can join in easily.
Make people aware of geeksplaining and its effects.
Foster inclusive language and encourage participants to use phrases like “people”, “folks”, “y’all”, etc. instead of “guys”.
We hope that these thoughts resonate with other “newcomers” as well as “oldies”, “experts” and people caring for an inclusive atmosphere. We also would be delighted if others would come up with critical feedback on our ideas … or even better ideas on how to improve on our efforts to include newcomers. We are excited to participate in future community events!
About the authors:
Angela (@krrrhx) is a Graphic Designer and Anthropologist entangled in the field of Science and Technology Studies. DIY-person living on the internet. Cares about accessibility and openness.
Renate (@ws_renu) is a Coach and Next Media enthusiast, engaged founder of Wikipedia projects like “Film Frauen”. Always interested in supportive leadership, kitchens, recipes and free style.
Jackie (@jackie_a_k) is a dedicated part-timer. Part educator and trainer, part sys- & network admin, part developer. Has backgrounds in Computer Science and Science & Technology Studies. Loves the “free” in software, culture and knowledge.