Authors: The authors listed in this post were the editors of the experiences shared from about 12 participants of the Sharing Journeys unconference session – Wikimedia Hackathon 2026
Facilitators: Silvia Gutiérrez (Wikimedia Foundation), Carla Toro (Wikimedia Chile), Giovanna Fontenelle (Wikimedia Foundation)
This guide is based on what women+ participants in Wikimedia technical spaces actually named as barriers and enablers – from lived experience, not assumptions.
We share it so future hackathon organizers, technical communities, and mentors can act on diversity with the clarity, learning from women+ in this space 😊
If you want to help us further, please consider answering this survey until July 20, that will help us prepare for future activities: Understanding technical contributions by women on Wikimedia.
1. Introduction
Technical spaces in Wikimedia remain unevenly accessible. In the 2025 Developer Survey, 74% of respondents identified as men, 7% as women, and another 7% as nonbinary, genderqueer, and/or transgender. The survey had 152 men, 15 nonbinary, genderqueer, and/or transgender individuals, and 14 women.

During the 2026 Wikimedia Hackathon in Milan, Carla, Giovanna, and Silvia thought it would be a great idea to map the sometimes-invisible barriers for women+ in more technical Wikimedia spaces. With this guide, we invite organizers, allies, and institutions to change what they build, how they communicate, and who they include to become more inclusive.
The recommendations below were developed through a live, facilitated process using an EasyRetro board during a 60‑minute unconference session at the Wikimedia Hackathon 2026: ‘Sharing Journeys: What Welcomes & What Blocks the Path of Women+ into Wikimedia Tech.’

During the session, participants answered three prompts:
- Their area of interest or passion (e.g., SRE, data tools, technopolitics, curiosity)
- One barrier they have faced
- One thing that lowered that barrier
Those items were merged with consent, voted on, and prioritized. This guide reflects what the room said mattered most. For each suggestion, we present the problem, some recommendations, and people who can act on the problem.
2. The three most significant barriers (voted + merged)
2.1 Never being allowed to be “average”
“We don’t expose the learning process – only final products. You’re accepted if you’re a genius, but the learning stage is not.”
Problem:
Women+ described a constant performance burden: not being able to appear uncertain, ask “basic” questions, or share work-in-progress without being judged more harshly than peers.
Recommendations:
- Intentionally showcase learning journeys in tech spaces (draft patches, rough scripts, “what I tried that failed”).
- Cultivate a learning environment in teams, meetings, and gatherings.
- In hackathon sessions:
- Explicitly say: “You do not need to be an expert. Struggling is normal.”
- Explore creating a mid-way session on things that you’re struggling with, rather than just presenting what you achieved
- Use pair programming or mob programming formats that normalize not knowing.
Who can help solve the problem:
- Hackathon session leads
- Wikimedia technical community moderators
- Training designers (Community Development team)
- Leads, managers, and other leadership in tech teams
2.2 The brutal environment of “demonstration”
“You are there to demonstrate, not to collaborate. The confrontation is brutal.”
Problem:
Technical spaces can feel adversarial and territorial. Participants describe a climate where you must constantly prove competence to belong in the space, where questions are interpreted as weakness, and where the tone is sharp rather than curious. Demonstration is the opposite of collaboration and the antithesis of Wikimedia projects and the open space.
Recommendations:
- Adopt a collaboration-first code of conduct for technical spaces, not just social spaces.
- Train tech leads on non-violent communication and feedback without shaming.
- Create more spaces in which it is welcomed to be a newcomer, learning skills and developing them together.
- Create more spaces where the shared understanding is that everyone, independently of level and years of experience, is still learning.
Who can help solve the problem:
- Tech leads and second timers
- Wikimedia Foundation Technical Engagement team
- Affiliate technical coordinators
2.3 Dismissing problems with “that’s super easy.”
Problem:
Well-meaning helpers often dismiss difficulties or deny the complexity of a problem when supporting women+. When someone says “oh that’s easy”, the subtext (whether intended or not) can feel like: you should not be struggling, this is supposed to be easy. This shuts down questions and reinforces the idea that only final products matter, not the messy, normal process of learning, and that the person asking is unfit or not enough to understand a “simple” task.
Recommendations:
- Replace “that’s easy” with something like: “oh, I’ve had that problem [or I’ve heard about this] and here’s where I/others usually get stuck”. Normalize publicly being in the learning stage.
- Understand that different people have different experiences and that something might be easy for you, but not be easy for others, and that doesn’t mean the task is easy or that the person who can do it without difficulties is above average.
Who can help solve the problem:
- Code reviewers and administrators
- Mentors or leads
- Technical forum responders (Stack Overflow-like spaces, Telegram/Signal groups)
3. The three most powerful enablers (voted + merged)
3.1 Women+ only spaces (with a feminist perspective)
“The male gaze has an unintended effect. Having a space dedicated to women+ is important.”
What works:
RLadies, an organization that promotes diversity in programming, has one goal: to disappear. They hope for a world in which women-only spaces are not necessary. However, while that moment doesn’t come, we’ve seen how feminist‑aligned tech spaces lower the activation energy for asking questions, sharing struggles, and celebrating small wins.
Recommendations:
- Fund and protect women+ only events, spaces, and projects.
- Plan and schedule women+ spaces during core hours or core programming. Provide a dedicated space for them.
- Make sure to have facilitators who identify as women.
- Ensure facilitators have feminist and intersectional awareness.
3.2 Evidence over impostor syndrome
“Evidence – seeing how I have developed tools, trainings, talks – helps me see I belong.”
What works:
Impostor syndrome is not solved by “you’re great”, but by visible proof of impact or by getting recognized. When women+ see their own contributions listed, merged, or cited, the barrier lowers and they feel more confident. Representation in the Wikimedia movement is even more important, as an open-access/source space, where references and credit matter a lot.
Recommendations:
- In hackathon demos, explicitly name who contributed what (not just the final tool).
- Explore creating personal contribution dashboards for technical contributors.
- Some inspiration could come from Growth’s Impact Module
- Encourage mentors to say: “Look at what you have already done!” not “you can do it!”.
3.3 Multiple, low‑threshold entry points + shared language
“Creating different entry points. Creating a common language – minimal levels of understanding.”
What works:
Outreachy, RLadies, Wikimedia community, and “step in anyway with less than half the experience” all share one pattern: you do not need to already belong in order to begin.
Recommendations:
- Publish glossaries for every technical space (e.g., “What is a Gerrit? What is a backport?”)
- Offer non‑code entry points (documentation, testing, design, mentoring)
- Explicitly invite people before they have a full experience.
- Avoid acronyms or abbreviations and add links to resources, to allow navigation and learning more.
Who can help solve the problem:
- Hackathon organizing teams
- Documentation supporters
- Wikimedia technical onboarding groups
- Affiliates running local tech events
4. A reusable process for other communities
You do not need to guess what barriers your community faces. This session used:
- Story of Self Circles (name, passion, one barrier, one enabler – timed, safe)
- A live retroboard (EasyRetro) with projected notes
- Voting (hand‑raise or digital) on most resonant items
- Merging with the consent of the original sharers
- Prioritization into a public guide
This process takes ≤60 minutes and works for 10–40 people.
5. Call to action
Do not wait for women+ to become “ready” for tech spaces. Lower the barriers you control:
- Stop saying “it’s easy”
- Protect learning stages
- Fund women+ only spaces
- Show evidence, not just encouragement
- Publish glossaries and multiple entry points
- Mention and reference your women+ colleagues
Wikimedia Hackathon 2027: We aim to return and report what changed.
Appendix: Full merged + voted list (from EasyRetro)
Top barriers (voted)
- Impostor syndrome (4 votes)
- “It’s super easy” – prevents follow‑up questions (3 votes + comment)
- Not being allowed to be “average” / learning stage invisible (1 vote)
- Brutal “demonstration” environment (1 vote)
- Stereotypes / not being able to be your authentic self
- Lack of energy to engage
Top enablers (voted)
- Women+ only spaces like RLadies and/or women‑led groups
- Evidence of one’s own work
- Community willing to help (Wikimedia, Open Source)
- Outreachy / similar internships
- Step in anyways (< half experience + curiosity)
- Multiple entry points + common language
Let’s build technical spaces where women+ do not have to be exceptional to belong!
Can you help us translate this article?
In order for this article to reach as many people as possible we would like your help. Can you translate this article to get the message out?
Start translation