Page MenuHomePhabricator

Actions to grow the diversity of our technical community
Closed, ResolvedPublic

Description

Type of activity: Unconference session
Main topic: How to grow our technical community

The session will be structured as an ideation style workshop to give some context and format to our discussion and have outcomes, that we can transfer to sustainable actions right away.
The main questions we will work on are:

  • What can be done on a technical level to increase diversity?
  • What behaviour is unacceptable to our community and how to deal with it?
  • How can we raise awareness about the lack of diversity in our technical community and its causes?
  • What are best practice recommendations to increase diversity?

The problem

The goal is to discuss ways to make our community more diverse.

Expected outcome

Possible strategies to improve the existing processes/events, find and gather new ideas and solutions to the problem, exchange on the existing one.

Current status of the discussion

At Wikimedia Deutschland we are currently organizing an event for Women to participate in Open Source projects, happening on 29th of October 2016. MediaWiki and Wikibase are two of the projects involved. I would like to exchange about how the event was set up, what feedback we received, and learnings from it.
It would also nice if someone involved with Outreachy (mentors as well as organizers) participate and talk about their experiences.

Links

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Qgil subscribed.

Good one! Just a quick note: Google Summer of Code also contributes to grow the diversity of our technical community. (There is no GSoC umbrella project yet, and this is the only reason why I haven't added it).

Right! IIRC @01tonythomas is involved with Outreachy (and might be at the summit, too?), would be great to have someone participating who's involved (as mentor or organizer) with GSoC. In general, would be great if someone could ping the people, who mentored in the recent years to share what worked and didn't work.

I only know of @hoo, whom I subscribed already and who's a mentor in our event this month, too, as well as @Mattflaschen-WMF

Wow. this looks nice. If I get chance to be there, I would attend. Related: https://phabricator.wikimedia.org/T148557

I can certainly talk about GSoC and my experiences; I've been a mentor seven times.

So, our event (Ladies That FOSS in Berlin) happened ~ two weeks ago for the first time ever. It was great, and even though we don't have any evaluation (yet), there are some things, that I can certainly summarize, that has been at least for me true.

We had a mentor meeting before where we just causally discussed some of the issues we think the different open source projects have on getting more women to contribute and in general, issues on involving new people. One of the main things was to show people, that anything in open source is actually adjustable by them and get them away from a consumers perspective, which is kind of a switch in the mindset.
One of the more practical things we realized talking about it but also with the participants, is that documentation is a key factor in getting people to work on things. Our documentation tends to be by and for people, that are already involved. We had at least one project struggling with someone using Windows, which would not let them any of their documentation. After these events, participants should be encouraged to work on the documentation and mentors should adjust anything the participants don't do. That's obviously more a general thing for involving new people but occurred to be important while our event, too, so I thought it would be good to summarize it somewhere.

When preparing Ladies That FOSS I struggled to find good material on how to mentor especially in a context of diversity. While I could summarize things that deemed important to me due to previous experience, that was rather on a level of guessing what could be important. It would be nice to come up with some form of guidelines or at least suggestions for mentors in these kind of events.

Since we set our focus on meeting open source projects in real life, I thought it would have been nice to recommend the participants some kind of meetup, they could come and ask their questions at. It would be nice to have meetups for the technical community more regularly than the Hackathon once a year, at least in areas with enough interested people.

I am happy to share more structured feedback on the event as soon as we have any.

I think that T150417 would fall into the way to leverage technical barrier and grow our technical community. See also 2016 Community Wishlist Survey for more feedback on this point.

@Psychoslave can you point to any source out there proving a relationship between localized programming languages and better developer outreach? I can see a clear connection between localized developer documentation and better outreach, but not with the localization of the programming language itself. I am not even sure that such move would lower any technical barrier, since documentation and collaboration around code would become a lot more complex.

As a non-native English speaker, I am not even sure that those concepts in English are seen as "English". You learn them as you learn to program.

Thank you for the suggestion of searching for related sources. Finding documentation on the subject is in fact, to my mind, very interesting and funny. Here are a few more or less relevant links:

Well, there might be more relevant papers out there, but it's already a bit of material to read.

I agree that it might not make much technical difference, but the idea is more to make it less scary for non-English speakers to edit modules on their localized wikis, so that's more a psychological barrier lowering. Of course I have no crystal ball which provide accurate metrics on how great or useless this would be to create a friendly learning path in more advanced technical contributions for people which otherwise wouldn't make the first step.

It might be interesting to already have some metrics of how much non-English comments and variable names there is in the current non-English templates and modules. Could we have that easily, even a rough approximation?

Most of those links basically refer to teaching programming languages, which is an area that we are not aiming to address directly. Also, offering localized Lua (PHP, Python, JavaScript...) would be such a humongous task that someone else (not those of us focusing on developer outreach) should complete first. I think this Summit discussion should focus on actions that we could start here and now.

Most of those links basically refer to teaching programming languages

Indeed, that's a direct result of keywords I used in my research.

which is an area that we are not aiming to address directly

Well, ok, if that is not a relevant place to progress on this topic, that sort of close the point. :) Now, the idea is not really about producing teaching material about programming (for that Wikibooks/Wikiversity would be good places) but to lower the barrier to module development, which feed or not a desire to learn more about programming. To my mind, it sounds like empowering end users and opening path to technical community growth through it. Now, once again, I admit that you are right when you emphasize that I have no solid metrics to back my intuition.

Also, offering localized Lua (PHP, Python, JavaScript...) would be such a humongous task that someone else (not those of us focusing on developer outreach) should complete first.

Ok, then I will continue with my Lupa project, focusing more on an internationalization target, rather than a mere Esperantist version of Lua. Any other suggestions that might be useful to consider in an integration perspective within WM environment, will be warmly welcome, but surely they should go on an other ticket, like T150933. For example, currently I target Lua 5.3 because it's the last Lua version, but I heard it does include backward incompatible feature, and according to https://www.mediawiki.org/wiki/Special:Version WM is using 5.1.5. So if there are problems I may avoid due to version incompatibly, I would for sure welcome caveats.

For Javascript, we already have babylscript. So should we go on some "next steps" for integration enquiry? Again, T150933 will be a better place to answer.

For Python, sure it should be also funny to internationalize and localize, but with it's battery included philosophy, it will be a far bigger task on the localization side. The minimalist approach of Lua ease the work here. ^^

For PHP, well, hmm, if more consistency in the API might be brought in the localization process, you might even want a EN_RATIONAL one. ;)

So far I mainly thought of the parts of this including people. Even though I agree with Quim, that we are not directly aiming at teaching programming languages, I think there is an important question we can draw from that: What technologies can be used and how in order to make our community more accessible for a bigger group of people? Is there any technologies we should improve, new ones to use or old ones to use less to engage more people?

@Juscwmde is working on the evaluation of the event at them moment btw. I will try to wrap up some of the things we got as a feedback for the summit if it fits in this context or any other.

Personally, my interest in this discussion focuses on specific changes we can make in the next months and we can plan for the next fiscal year (July 2017- - June 2018). If at the end of the session we have a list of actions to be taken in the short and mid-term, great. If we have an interesting yet vague discussion without clear actions for anybody at the end... then I think we would have missed an opportunity.

We have the Wikimedia Hackathon, the next GSoC/Outreachy round, the next Community Wishlist results, the Code of Conduct for technical spaces, mediawiki.org, grants... How can we improve our work in these areas (and others you want to bring in) in order to grow the diversity of our technical community?

@Qgil I fully agree. It might be worth to prepare a proper workshop with questions to solve then rather than just having a discussion round? I did something similar with @Juscwmde and @Incabell at viewsource, but the scope was too big (multiple people from various projects), it could be worth to prepare a similar workshop focusing on growing the diversity of the MediaWiki community.

Workshop with questions, how would that work during the session? Also, maybe can we start this work beforehand? Why not sending questions before the session?

The workshop should be focussed on prototyping in my oppinion so that the people actually are able to do something.
Beforehand we could focussed on the different target group and collecting some input what we already have from our communities. Than we could use the workshop for a brainwalk through How might we - Questions (e.g. How might we increase the number of women in media wiki development) for collecting ideas or connecting old ideas with new ones. Then we choose one idea per question and building a prototype on that?

In terms of room capacity and configuration, what would be your preference?

  • The biggest room in theater configuration (up to 200 people, only chairs, no tables) and required video recording (meaning also that people have to wait for the mic to speak etc).
  • A big room in classroom configuration (up to 70-80 people, chairs and tables) and required video recording (meaning also that people have to wait for the mic to speak etc).
  • A big room in classroom configuration (up to 70-80 people, chairs and tables) and optional video recording (i.e. only recording the initial introduction but then relaxing things during the discussion, or no recording at all).
  • A smaller room, flexible configuration, optional video recording...

A room where everyone can speak freely, we have chairs and tables we can arrange in groups for people to work together would be good I. We will probably only have a short intro and presentation of ideas, so no need for a theater style room.

Thanks! Then, this sounds like a good Unconference session.

In fact, the Program committee liked this proposal very much and has proposed to pre-=schedule it. Currently it is set to Tuesday, January 10 at 4pm in Room 2. The session will be video recorded.

We are aware that this session has a tough "competitor", T153022: First Tech Debt Bash. However, we think that both session may stand next to each other better than other candidates. People will have to choose between a strong social session and a strong technical session.

What do you think? Are you happy with these changes?

@Qgil, I guess your questions are for @Lucie, aren't they?

@Qgil, sorry for the delay. I am planning the workshop at the moment. Since I don't want it to be top down, I would like to have space for people to walk around and exchange, so it would be good if the room could provide that.
I am not sure if the filming will make sense, since it will be a lot of working in groups and discussing. However, since I want to conclude with a presentation of the findings and the actions that will be taken as a following step, there might be a chance to film that part. It will be pretty hard to properly contribute remotely since it's mainly face to face discussions.
I need a few materials for the workshop: post-its, enough sharpies for everyone to write on the post-its, a big timer, dot stickers, and multiple (depending on number of attendees) flip charts. I assume it would make more sense if you could provide those rather than bringing that from Germany.

Thank you very much for the interest! I am very much looking forward to the session!

I'm interested in the discussion of localized programming languages that @Psychoslave brought up.

I think there are interesting conversations to have about the impact of programming languages on diversity even within the group of "English programming languages". For example, while I was working at One Laptop per Child, most of our operating system and pedagogic materials were written in Python, which we liked because it was beginner-friendly and we hoped this would increase the diversity of our contributor base.

In many case it had the opposite effect, however. In Central and South Amercian deployments, there was a strong institutional bias towards teaching for a "certificate" that would demonstrate mastery of some technical task, and computer science as vocational education. Commerical organizations offered certificates in various commercial products: Microsoft, Red Hat Linux, etc. However, Python was a "hobbyist" language without a strong commercial backer. No one offered a "certificate" demonstrating mastery of Python programming, and it was seen as worthless/a waste of time. No schools offered courses in python programming.

So in the end our developer participation in latin america was far less than if we had chosen a "harder" but more "commercial" language, which would have been supported by the education system. JavaScript would probably have been a reasonable alternative, for example. It is widely seen as a worthwhile commercial language, and there are plenty of educational materials and courses available.

So there is more to increasing diversity than simply translating your content.

Thank you @cscott for your feedback. I fail to see what you might be suggesting, if anything, with "there is more to increasing diversity than simply translating your content", however. Are specific things you have in mind for this "more"?

To the owner of this session: Here is the link to the session guidelines page: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Session_Guidelines. We encourage you to recruit Note-taker(s) 2(min) and 3(max), Remote Moderator, and Advocate (optional) on the spot before the beginning of your session. Instructions about each role player's task are outlined in the guidelines. The physical version of the role cards will be made available in all the session rooms. Good luck prepping, see you at the summit! :)

Note-taker(s) of this session: Follow the instructions here: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Session_Guidelines#NOTE-TAKER.28S.29 After the session, DO NOT FORGET to copy the relevant notes and summary into a new wiki page following the template here: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Your_Session and also link this from the All Session Notes page: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/All_Session_Notes. The EtherPad links are also now linked from the Schedule page (https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Schedule) for you!

Since we didn't take notes, I will do a write-up of the session next week and add it here or in an etherpad to keep the discussion going.

Qgil triaged this task as Medium priority.Jan 15 2017, 5:47 PM

The results from the group works are in the etherpad here: https://etherpad.wikimedia.org/p/devsummit17-diversity
Feel free to add things

Mvolz edited projects, added Outreachy (Round-14); removed Outreachy.

What specific actions can we take from this task in order to increase diversity of newcomers? I ask for two reasons:

  1. Mathematically speaking, increasing the diversity of our community starts with increasing the diversity of newcomers. There is a lot more to do to retain those newcomers and get that fresh diversity permeate all the corners of our community, but diversity of newcomers is a necessary start.
  2. Developer-Advocacy wants to focus on onboarding new developers, and we want to do this taking diversity as a fundamental factor.

If there are specific actions in this direction, we will see how they can be integrated and spelled out in our annual plan.

Related

onboarding newcomers:

  • T73357 Add a welcome bot to Gerrit for first time contributors

Wikibase

  • T99530 [Task] improve documentation of wikiba.se infrastructure
  • T159218 [Hackathon doc sprint] Wikibase installation

Since gadgets and JS are likely to be a typical starting point:

  • T155473 Improve documentation of OOjs UI
  • T155554 VE support for skins should be done by adding appropriate anchors/ids/styles to the skins, and not by editing VE itself
  • T155567 Make OOjs UI easier to use for gadgets

I am hesitant about resolving this task without specific actions spelled out and filed.

I agree. Since there's no active discussion here, it might be appropriate to find another medium for a discussion- maybe there's interest to do a follow up based on our conclusion from last time to file specific actions?
The next event would probably be Wikimania?

Thank you @cscott for your feedback. I fail to see what you might be suggesting, if anything, with "there is more to increasing diversity than simply translating your content", however. Are specific things you have in mind for this "more"?

Belated response, sorry. By "more" I meant, "take local culture and practices into account". In my example, we had failed to understand the importance of the "certificate" in the local educational system, and so we ended up hamstringing our local communities by choosing a programming language for which it was impossible to get a "certificate". In another example (and a different country) from my OLPC days, fluency in English was seen as an important commercial/vocational skill, so having materials available in English (counter-intuitively) created added incentives to join the community. I'm not saying either of these specific examples apply blindly to Wikipedia. In fact, my point is exactly the opposite: you shouldn't take *any* general rules for granted (even "the most important localization problem to solve is translating programming language keywords"), but instead (if possible) build your priorities around a specific community or educational context.

It may be that switching from Lua to (standard "English") JavaScript might actually yield more diversity than localizing Lua keywords, because of the larger ecosystem issues. But again, that is dependent on context. If there is a large Lua community in underrepresented country X, then the opposite would be true.

As a Wikimedia-Developer-Summit (2017) session, it looks like the purpose of this task has been exhausted. Further actions should be reflected in new tasks. Thank you @Lucie and contributors!

PS: If you disagree, just reopen.