Welcome to Etherpad!

This pad text is synchronized as you type, so that everyone viewing this page sees the same text. This allows you to collaborate seamlessly on documents!

Get involved with Etherpad at http://etherpad.org
% Lines starting with % are comments and will be ignored
% comments may be treated as commands/actions/functions

% http://blogs.lgru.net/ft/conversations/just-ask-and-that-will-be-that

% FS = Femke Snelting
% AL A = Asheesh Laroia

% USED FOR NAME INDEXING
% HIDDENKEYWORDS: Laroia, Asheesh


% TITLE: Just Ask and That Will Be That


% SCALEFONT: 1.32

This conversation took place in Montreal at the last day of the ** Libre Graphics Meeting 2011 ** . In the panel _ How to keep and make productive libre graphics projects? _ , Asheesh had responded rather sharply to a remark from the audience that only a very small number of women w ere present at LGM: _ Bringing the problem back to gender is avoiding the general problem that F/LOSS has with social inclusion. _
Another good reason to talk to him we re the intriguing 'Interactive training missions' that he ha d been developing as part of the OpenHatch.org  project. I wanted to know more about the tutorials he develops; why he decided to work on 'story manuals' that explain how to report a bug or  how to work with version control.
Asheesh Laroia is someone who realizes that most of the work  that makes projects successful is hidden underneath the surface. He volunteered his technical skills for the UN in Uganda, the EFF, and Students for Free Culture, and is a d eveloper o n the Debian team . Today, he lives in Somerville, MA. He speaks about his ideas to audiences at international F/LOSS conferences.

% RESETFONT:
% BIGSKIP:


% SLOGAN: Bending culture


% NOWSPEAKING: AL A
% ---------------
The i nteractive training missions are really linked to the background of the OpenHatch project itself. I started working on it because to my mind, one of the biggest reasons that people do not participate in F ree S oftware projects, is that they either don't know how or don't feel included.
There is a lot you have to know to be a meaningful contributor to F ree S oftware and I think that one of the major obstacle for getting that knowledge, and I am being a bit sloppy with the use of the term maybe, is how to understand a conversation on a bug-tracker for example. This is not something you run into in college, learning computer science or any other discipline. In fact, it is an almost anti-academic type of knowledge. Bug tracker conversations are 'just people talking', a combination of a comment thread on a blog and actual planning documents. There's also tools like version control, where close to no one learns about in college. There is something like the culture of participating in mailing lists and chatting on IRC... what people will expect to hear and what people are expecting from you.

For people like me that have been doing all these things for years, it feels very natural and it is very easy to forget all the advantages I have in this regard. But a lot of the ways people get to the point where I am now involves having friends that help out, like _Hey, I asked what I thought was a reasonable question on this mailing list and I did not get any answer_ or _what they said wasn't very helpful_ . At this stage, if you are lucky, you have a friend that helps you stay in the community. If you don't, you fall away and think _I'm not going to deal with this, I don't understand_ .
So, the training missions are designed to give you the cultural experience and the tool familiarity
in an automated way. You can stay in the community even when you don't have a friend, because the robot will explain you what is going on.


% NOWSPEAKING: FS
% ---------------
So how do you 'harvest' this cultural information? And how do you bring it into your tool?


% NOWSPEAKING: AL A
% ---------------
There is some creative process in what I call 'writing the plot'; this is very linear. Each training mission is usually between three and fifteen minutes long so it is OK to have them be linear. In writing the plot, you just imagine what would it take a new contributor to understand not only what to do, but also what a 'normal community member' would know to do. The different training missions get this right to different extents.


% NOWSPEAKING: FS
% ---------------
How does this type of knowledge form, you think? Did you need to become a kind of anthropologist of F ree S oftware? How do you know you teach the right thing?

% NOWSPEAKING: AL A
% ---------------
I spend a lot of time both working with and thinking about new contributions to F ree S oftware. Last September I organized a workshop to teach computer science students how to get involved in Open Source. And I have also been teaching interpersonally, in small groups, for ten or eleven years. So I use the workshops to test the missions and than I simply ask what works. But it is tough to evaluate the training missions through workshops because the workshops are intended to be more interpersonal. I definitely had positive feedback, but we need more, especially from people that have been two or three years involved in the F ree S oftware community, because they understand what it feels like to be part of a community but they may still feel somewhat unsure about whether they have everything and still remember what was confusing to learn.

% NOWSPEAKING: FS
% ---------------
I wasn't actually asking about how successful the missions are in teaching the culture F ree S oftware ... I wanted to know how the missions learn from this culture?


% NOWSPEAKING: AL A
% ---------------
So far , the plots are really written by me, in collaboration with others. We had one more recent contribution on G it written by someone called Mark Freeman who is involved in the OpenHatch project. It did not have so much community discussion but it was also pretty good from the start. So I basically try to dump what is in my head?


% NOWSPEAKING: FS
% ---------------
I am asking you about this, thinking about a session we once organized at Samedies, a woman-and- F ree- S oftware group from Brussels. We had invited someone to come talk to us about using IRC on the command-line and she was discussing etiquette. She said: _ On IRC you should never ask permission before asking a question _ . This was the kind of cultural knowledge she was teaching us and I was a bit puzzled ... you could also say that this lack of social interfacing on IRC is a problem. So why replicate that?


% NOWSPEAKING: AL A
% ---------------
In Debian we have a big effort to check the quality of packages and maintaining that quality, even if the developer goes away. It is called the 'Debian QA project' and there's an IRC channel linked to that called #debian-qa. Some of the people on that channel like to say hello to each other and pay attention when other people are speaking, and others said _ stop with all the noise _ . So finally, the people that liked saying hello moved to another channel: #debian-sayhi.

% NOWSPEAKING: FS
% ---------------
Meaning the community has made explicit how it wants to be spoken to?


% NOWSPEAKING: AL A
% ---------------
The point I am trying to make here, is that I am agreeing to part of what you are saying, that these norms are actually flexible. But what I am further saying, is that these norms are actually being bent.


% SLOGAN: Things that could be reasonable


% NOWSPEAKING: FS
% ---------------
I would like to talk about the new mission on bug reporting you said you were working on, and how that is going. I find bug reports interesting because if they're good, they mix observation and narration, which asks a lot from the imagination of both the writer and the reader of the report; they need to think themselves in each others place: What did I expect that would happen? What should have happened? What could have gone wrong? Would you say your interactive training missions are a continuation of this collective imaginary work?


% NOWSPEAKING: AL A
% ---------------
A big part of that sort of imagination is understanding the kinds of things that could be reasonable. So this is where cultural knowledge comes in. If you program in C or even if you just read about C, you understand that there is something called 'pointers' and something called 'segfaults' and if your program ends in that way, that is not a good thing and you should report a bug. This requires an imagination on the side of the person filing the bug.
The training missions give people practice in seeing these sorts of things and understand how they could work. To build a mental model, even if it is fuzzy, that has enough of the right components so they can enter in discussion and imagine what happened.
%
% SLOGAN: Mixed feelings
%
% N ! OWSPEAKING: AL A
% ---------------
I have mixed feelings about using 'gender' as an important characteristic when considering how to grow our communities. It is not a bad idea maybe, and I am working on projects that are related to this as well, but I think it permits a misunderstanding of the problem and puts things in an awkward space, especially when the issue is addressed in a room primarily filled by men and only a few woman. Is what the men say sort of judge-able by the few women in the room? Are they speaking to the women that are not in the room? It becomes all very tenuous and confusing what you can or should say or do. We can skip this by understanding the real issue, which is community inclusiveness.

Of course when there are real issues such as groping at conferences, or making people feel unwelcome because they are shown slides of half-naked people that look like them ... that is actually a gender issue and that needs to be addressed. But the example I gave was: _ Where are the Indians, where are the Asians in our community? _ This is still a confusing question, but not awkward.


% NOWSPEAKING: FS
% ---------------
Why is it not awkward?


% NOWSPEAKING: AL A
% ---------------
(_ laughs _ ) As I am an Indian person ... you might not be able to tell from the transcription?

It is an easy thing to do, to make generalizations of categories of people based on visible characteristics. Even worse, is to make generalizations about all individual people in that class. It is really easy for people in the F ree S oftware community to subconsciously think there are no women in the room ' because women don't like to program ' , while we know that is really not true. I like to bring up the Indian people as an example because there are obviously a bunch of programmers in India ... the impression that they can't program, can't be the reason they are excluded.


% NOWSPEAKING: FS
% ---------------
But in a way that is even more awkward?


% NOWSPEAKING: AL A
% ---------------
Well, maybe I don't feel it is that awkward because I see how to fix it, and I even see how to fix both problems at the same time.


% NOWSPEAKING: AL A
% ---------------
In F ree S oftware we are not hungry for people in the same way that corporate hiring departments are. We limp along and sometimes one or two or three people join our project per year as if by magic and we don't know how and we don't try to understand how. Sometimes external entities such as Google Summer of Code cause many many more show up at the doorstep of our projects, but because they are so many they don't get any skills for how to grow.
When I co-ran this workshop at the computer science department at the University of Pennsylvania on how to get involved in O pen S ource, we were flooded with applicants. They were basically all feeling enthusiastically about O pen S ource but confused about how to get involved. 35% of the attendees were women, and if you look at the photos you'll see that it wasn't just women we were diverse on, there were lots of types of people.
That's a kind of diversity-neutral outreach we need. It is a self-empowerment outreach: 'you will be cooler after this, we teach you how to do stuff' and not 'we need you to do what we want you to do', which is the hiring-kind of outreach.


% NOWSPEAKING: FS
% ---------------
And why do you think F ree S oftware doesn't usually reach out in this way? Why does the F/LOSS community have such a hard time becoming more diverse?


% NOWSPEAKING: AL A
% ---------------
The F/LOSS community has problems getting more people **and** being more diverse. To me, those are the same problems. If we would hand out flyers to people with a clear message saying for example: here is this nice vector drawings program called Inkscape. Try it out and if you want to make it even better, come to this session and we'll show you how. If you send out this invitation to lots of people, you'll reach more of them and you'll reach more diverse people. But the way we do things right now, is that we leave notes on bug trackers saying: _help wanted_ . The people that read bug trackers, also know how to read mailing lists. To get to that point, they most likely had help from their friends. Their friends probably looked like them, and there you have a second or third degree diversity reinforcement problem.
But leaving gender diversity and race diversity aside, it is such a small number of people!


% SLOGAN: The How-To-Contribute page


% NOWSPEAKING: FS
% ---------------
So, to break that cycle you say there is a need to externalize knowledge … like you are doing with the OpenHatch project and with your project ' Debian for Shy People ' ? To not only explain how things technically work, but also how they function socially?


% NOWSPEAKING: AL A
% ---------------
I don't know about externalizing ... I think I just want to grow our community. But when I feel more radical, I'd say we should just not write 'How to contribute' pages anymore. Put a giant banner there instead saying: _This is such a fun project, come hang out with us on IRC ... every Sunday at 3PM_ . Five or ten people might show up, and you will be able to have an individual conversation. Quickly you'll cross a boundary … where you are no longer externalizing knowledge, but simply treat them as part of your group.

The Fedora Design Bounties are a big shining example for me. Maírín Duffy has been writing blog posts about three times a year: _ We want you to join our community and here is something specific we want you to do. If you get it right, the prize is that you are part of our community. _ The person that you get this way will stick around because he or she came to join the community.


% NOWSPEAKING: FS
% ---------------
And not because you sent a chocolate cake?


% NOWSPEAKING: AL A
% ---------------
Not for the chocolate cake, and also not for the 5000$ that you get over the course of a Google summer of code project. So, I question whether it is worth spending any time on a wiki-page explaining ' How to contribute ' when instead you could attract people one by one, with a 100% success-rate.


% NOWSPEAKING: FS
% ---------------
Writing a ' How to contribute ' page does force teams to reflect on what it takes to become part of their community?


% NOWSPEAKING: AL A
% ---------------
Of course that is true. But compared to standing at a job-fair talking to people about their resume, 'H ow to contribute ' pages are like anonymous, impersonal walls of text that are not meant to create communication necessarily. If we keep focusing on communicating at this scale, we miss out on the opportunity to make the situation better for individual people that are likely to help us.


% SLOGAN: Patience is valuable


% NOWSPEAKING: FS
% ---------------
I feel that the F ree S oftware community is quite busy with efficiency. When you emphasize the importance of individual dialogue, it sounds like you propose a different angle, even when this in the end has the desired effect of attracting more loyal and reliable contributors.


% NOWSPEAKING: AL A
% ---------------
It is amazing how valuable patience is.


% NOWSPEAKING: FS
% ---------------
You talked about Paul, the guy that stuck around on the IRC channel saying hi to people and than only later started contributing patches after having seen two or three people going through the process. You said: _If we had implied that this person would only be welcome when he was useful ... we would have lost someone that would be useful in the future._


% NOWSPEAKING: AL A
% ---------------
The obsession with usefulness is a kind of elitism. The Debian project leader once made this sort of half-joke where he said: _Debian developers expect new Debian contributors to appear as fully formed, completely capable Debian developers._ That is the same kind of elitism that speaks from _You can't be here until you are useful._ By the way, the fact that this guy was some kind of cheerleader was awesome. The number of patches we got because he was standing there being friendly, was meaningful to other contributors, I am sure of it. The truth is ... he was always useful, even before he started submitting patches. Borrowing the word 'useful' from the most extreme code-only definition, in the end he was even useful by that definition. He had always been useful.


% NOWSPEAKING: FS
% ---------------
So it is an obsession with a certain kind of usefulness?


% NOWSPEAKING: AL A
% ---------------
Yes.


% NOWSPEAKING: FS
% ---------------
It is nice to hear you bring up the value of patience. OSP uses the image of a frog as their logo, a reference to the frog from the fairy tale 'The frog and the princess'. Engaging with F ree S oftware is a bit like kissing a frog; you never know whether it will turn into a prince before you have dared to love it! To OSP it is important not to expect that things will go the way you are used to ... A suspension of disbelief?

% NOWSPEAKING: ALA
% ---------------
Or hopefulness! I had a couple of magic moments ... one of the biggest magic moments for me was when I as a high school student e-mailed the Linux kernel list and than I got a response! My file system was broken, and fsck-tools were crashing. So I was at the end of what I could do and I thought: let's ask these amazing people. I ended up in a discussion with a maintainer who told me to submit this bug-report, and use these dump tools ... I did all these things and compiled the latest version from version control because we just submitted a patch to it. By the end of the process I had a working file system again. From that moment on I thought: these magic moments will definitely happen again.


% SLOGAN: Just ask and that will be that


% NOWSPEAKING: FS
% ---------------
If you want magic moments, than streamlining the communication with your community might not be your best approach?

% NOWSPEAKING : AL A
% ---------------
What do you mean by that?


% NOWSPEAKING: FS
% ---------------
I was happy to find a panel on the program of LGM that addressed how this community could grow. But than I felt a bit frustrated by the way people were talking about it. I think the user and developer communities around Libre Graphics are relatively small, and all people actually ask for, is dialogue. There seems to be lots of concern about how to connect, and what tools to use for that. The discussion easily drifts into self-deprecating statements such as ' our website is not up-to-date ' or ' we should have a better logo ' or ' if only our documentation would be better ' . But all of this seems more about putting off or even avoiding the conversation.


% NOWSPEAKING: AL A
% ---------------
Yes, in a way it is. I think that 'conversations' are the best, biggest thing that F/LOSS has to offer its users, in comparison with proprietary software. But a lot of the behavioral habits we have within F/LOSS and also as people living in North America, is derived from what we see corporations doing. We accept this as our personal strategies because we do not know any alternatives. The more I say about this, the more I sound like a hippie but I think I'll have to take the risk ( _ laughs _ ).

If you go to the Flash website, it tells you the important things you need to know about Flash, and than you click download. Maybe there is a link to a complex survey that tries to gather data en masse of untold millions of users. I think that any randomly chosen website of a Libre Graphics project will look similar. But instead it could say when you click download or run the software ... _ we're a bunch of people ... why don't you come talk to us on IRC? _

There are a lot people that are not in the conversation because nobody ever invited them. This is why I think about diversity in terms of outreach, not in terms of criticizing existing figures. If in some alternate reality we would want to build a F/LOSS community that exists out of 90% women and 10% men, I bet we could do it. You just start with finding a college student at a school that has a good Computer Science program ... she develops a program with a bunch of her friends ... she puts up flyers in other colleges ... You could do this because there are relatively so little programmers in the world busy with developing F/LOSS that you can almost handpick the diversity content of your community. Between one and a thousand ... you could do that. There are 6 million thousand people on this planet and the amount of people **not** doing F/LOSS is enormous. Don't wring your hands about ' where are the women ' .
Just ask them to join and that will be that!