Numbers are not enough: Why I will only attend conferences with explicitly enforceable Codes of Conduct and a commitment to accessibility

I recently had a bad experience at a programming workshop where I was the only woman in attendance and eventually had to leave early out of concern for my safety.

Having to repeatedly explain the situation to a group of men who promised me that “they were working on fixing this community” was not only degrading, but also unnecessary. I was shuttled to three separate people, eventually receiving some of my money back approximately a month later (which was all I asked for) along with promises and placating statements about “improvement.”

What happened could have been prevented: each participant signed a “Code of Conduct” that was buried in the payment for the workshop, but there was no method of enforcement and nowhere to turn when issues arose.

At one point while I was attempting to resolve the issue, this community’s Project Manager told me, “Three other women signed up, but they dropped out at the last minute because they had to work. It was very strange and unexpected that you were the only woman.” I felt immediately silenced. The issue is not numbers, but instead inviting people to safe spaces and building supportive structures where people feel welcomed and not marginalized. Increasing the variety of people involved in an event is certainly a step, but it is only part of the picture. I realize now that the board members of this organization were largely embarrassed, but they could have handled my feelings in a way where I didn’t feel like their “future improvements” were silencing my very real current concerns.

Similarly, I’ve been thinking a lot about a conversation I had with some members of the German Python community a few months ago. Someone told me that Codes of Conduct are an American hegemonic device and that introducing the idea of abuse opens the community up for it, particularly in places that do not define “diversity” in the same way as Americans. This was my first exposure to this argument, and it definitely gave me a lot of food for thought, though I adamantly disagree.

In my opinion, the open-source tech community is a multicultural community and organizers and contributors have the responsibility to set their rules for participation. Mainstream Western society, which unfortunately dictates many of the social rules on the Internet, does a bad job teaching people how to interact with one another in a positive and genuine way, and going beyond “be excellent to one another, we’re all friends here!” argument helps us participate in a way in which people feel safe both on and off the Web.

At a session at the Open Knowledge Festival this week, we were discussing accessibility and realized that the Code of Conduct (called a “User Guide”) was not easily located and many participants were probably not aware of its existence. The User Guide is quite good: it points to other codes of conduct, provides clear enforcement, and emphasizes collaboration and diversity.

At the festival, accessibility was not addressed in any kind of cohesive manner: the one gender-neutral bathroom in the huge space was difficult to find, sessions were loud and noisy and often up stairs, making it impossible for anyone with any kind of hearing or mobility issue to participate, and finally, the conference organizers did not inform participants that food would not be free, causing the conference’s ticket price to increase dramatically in an expensive neighborhood in Berlin.

In many ways, I’m conflating two separate issues here (accessibility and behavior of participants at an event.) I would counter that creating a safe space is not only about behavior on the part of the participants, but also on the part of the conference organizers. Thinking about how participants interact at your event not only has to do with how people interact with one another, but also how people interact with the space. A commitment to accessibility and “diversity” hinges upon more than words and takes concerted and long term action. It may mean choosing a smaller venue or limiting the size of the conference, but it’s not impossible, and incredibly important. It also doesn’t have to be expensive!  A small hack that I appreciated at Ada Camp and Open Source Bridge was a quiet chill out room. Being able to escape from the hectic buzz was super appreciated.

Ashe Dryden writes compellingly about the need for better Codes of Conduct and the impetus to not only have events be a reflection of what a community looks like, but also where they want to see them go. As she writes,

I worry about the conferences that are adopting codes of conduct without understanding that their responsibility doesn’t end after copy/pasting it onto their site. Organizers and volunteers need to be trained about how to respond, need to educate themselves about the issues facing marginalized people attending their events, and need to more thoughtfully consider their actions when responding to reports.

Dryden’s  Code of Conduct 101 and FAQ should be required reading for all event organizers and Community Managers. Codes of Conduct remove the grey areas surrounding appropriate and inappropriate behavior and allow groups to set the boundaries for what they want to see happening in their communities. In my opinion, there should not only be a Code of Conduct, but also an accessibility statement that collaboratively outlines what the organizers are doing to make the space accessible and inclusive and addresses and invites concerns and edits.  In her talk at the OKFestival, Penny pointed out that accessibility and inclusion actually makes things better for everyone involved in an event. As she said, “No one wants to sit in a noisy room! For you, it may be annoying, but for me it’s impossible.”

Diversity is not only about getting more women in the room, it is about thinking intersectionally and educating oneself so that all people feel welcome regardless of class, race, physicality, or level of education. I’ve had the remarkable opportunity to go to conferences all over the world this year, and the spaces that have made an obvious effort to think beyond “We have 50% women speakers!” are almost immediately obvious. I felt safe and welcomed at Open Source Bridge and Ada Camp. From food I could actually eat to lanyards that indicated comfort with photography to accessibility lanes, the conference organizers were thoughtful, available, and also kind enough that I could approach them if I needed anything or wanted to talk.

From now on, unless I’m presented a Code of Conduct that is explicit in its enforcement, defines harassment in a comprehensive manner, makes accessibility a priority, and provides trained facilitators to respond to issues, you can count me out of your event.

We can do better in protecting our friends and communities, but change can only begin internally. I am a Community Manager because we get together to educate ourselves and each other as a collaborative community of people from around the world. We should feel safe in the communities of practice that we choose, whether that community is the international Python community, or a local soccer league, or a university. We have the power to change our surroundings and our by extension our future, but it will take a solid commitment from each of us.

Events will never be perfect, but I believe that at least in this respect, we can come damn close.


about:Mozilla: more than just a newsletter

“The about:Mozilla newsletter reaches 70,000 people?” I asked Larissa Shapiro incredulously in March when she suggested that our team assist in reviving the dormant newsletter. Indeed, with about:Mozilla, we have the opportunity to reach the inboxes of 70,000 potential contributors, all of whom have already expressed interest in learning more about our work. Though the newsletter is several years old, the revamp focuses on contribution and community. Its renewal has been a boon for our team and helped us continue working both cross-functionally and with our contributor base.

Spreading the Mozilla mission by connecting at scale is one of next quarter’s goals, and the about:Mozilla newsletter is a unique and dynamic way for us to do so. The about:Mozilla newsletter brings us back to our roots: We are seeking out the best in contribution activities and delighting a large community of motivated, excited people who love our products, projects and mission. As our Recognition Working Group asserts: “People contribute to Mozilla because they believe in our message.” The newsletter brings that message to new contributors and reminds casual contributors what they can do for Mozilla.

Reinvigorating the newsletter was a high priority for the Community Building team in Q2 and its success and consistency speaks to the continued collaboration between Community Building and Engagement to create a fantastic, contributor-led newsletter. We’ve released four newsletters since May, and found that with each issue we continue to find our voice, empower new contributions, and seek out relevant, highly engaged channels for new contributors to get involved at scale. The newsletter team, which consists of myself, Jan Bambach, Brian King, Jessilyn Davis, and Larissa Shapiro, seek to provide readers the best opportunities to volunteer across Mozilla.

The easy, digestible, and fun opportunities in the newsletter have been identified by a variety of teams, and every week we present more chances to connect. We’ve given contributors the tools to contribute in a variety of functional areas, from Maker Party to Security to Marketplace to Coding. We have yet to be sure of our return on investment: the newsletter is new and our tracking system is still limited in terms of how we identify new contributions across the organization, but we are excited to see this continue to scale in Q3. We hope to become a staple in the inboxes of contributors and potential contributors around the world.

Our click rates are stable and at industry average with approximately 25% of subscribers opening the newsletter, and our bounce rate is very low. We are working together to improve the quality and click rate for our community news and updates as well as featuring a diverse set of Mozilla contributors from a variety of different contribution areas. Though our current click rate is at 3%, we’re fighting for at least 6% and the numbers have been getting incrementally better.

Identifying bite-sized contribution activities across the organization continues to be a struggle from week to week. We keep our ears open for new opportunities, but would like more teams to submit through our channels in order to identify diverse opportunities. Though we put out a call for submissions at the bi-monthly Grow meeting, we find it difficult to track down teams with opportunities to engage new Mozillians. Submissions remain low despite repeated reminders and outreach.

My favorite part of the newsletter is definitely our “Featured Contributor” section. We’ve featured people from four countries (the United States, China, India, and the Phillipines,) and told their varied and inspirational stories. People are excited to be featured in the newsletter, and we are already getting thank you emails and reposts about this initiative. Thank you also to all the contributors who have volunteered to be interviewed!

I’d like to encourage all Mozillians to help, and here are some easy things that you can do to help us connect at scale:

Here is what I would like to see in the next quarter:

  • I’d like to see our click rate increase to 8%. I’ve been reading a lot about online newsletters, and we have email experts like Jessilyn Davis on our team, so I think that this can be done.

  • The name about:Mozilla is no longer descriptive, and we would like to discuss a name change to about:Community by the end of the year.

  • I will set up a system for teams to provide feedback on whether or not the newsletter brought in new contributors. Certain teams have done this well: the MoFo Net Neutrality petition from last week contained analytics that tracked if the signature came from the newsletter. (Security-minded folks: I can say honestly that it tracked nothing else!)

  • I would like to see the newsletter and other forms of Engagement become a pathway for new contributors. This newsletter cannot happen without the incredible work of Jan Bambach, a motivated and long-time volunteer from Germany, but I’d love to see others getting involved too. We have a link at the bottom of the page that encourages people to Get Involved, but I think we can do more. The newsletter provides a pathway that can help contributors practice writing for the web, learn about news and marketing cycles, and also learn to code in html. A few more hands would provide a variety of voices.

  • I will continue to reach out to a variety of teams in new and creative ways to encourage diverse submissions and opportunities. The form seems to be underutilized, and there are definitely other ways to do outreach to teams across the organization.
  • Eventually, I’d love to see the newsletter translated into other languages besides English!

While the newsletter is only a part of what we do, it has become a symbol for me of how a small group of motivated people can reboot a project to provide consistent quality to an increasingly large supporter base. The about:Mozilla newsletter is not only a success for the Community Building Team, it’s a success for the whole organization because it helps us get the word out about our wonderful work.


On working open in a closed world

At Mozilla, we talk a lot about how working in the open can benefit our communities. As Mozillians, we come from a lot of different backgrounds and experience levels in terms of “openness,” and have blogged and blogged and blogged about this subject, trying to fight “community debt” and keep people active and involved using open processes to collaboration. As David Boswell pointed out at a recent talk,  a lot of this is the expanding nature of our communities; while he was able to reach out to one or two people when he wanted to get involved fifteen years ago, now there are hundreds of listservs and tools and thousands of people to engage with.

At Ada Camp this weekend, I had a wonderful conversation with other feminists about hospitality and its absence in many communities. Working open is, for me, a form of hospitality. When we use phrases like “Designing for Participation,” we are actually inviting people into our work and then gifting it to them, asking them to share in our creativity, and using the power of the collective “hive” mind in order to create something beautiful, functional, and delightful. We should be continuing to embrace this gift economy, recognizing contributors in ways that they both want, and in perhaps less tangible ways.

There’s a section of the book The Ethical Slut (pardon the title) that I’ve always loved. The authors propose that love and affection in our society is engaged a mythical “starvation economy” and claim that many of us have been conditioned since childhood to “fight for whatever we get, often in cutthroat competition with our brothers and sisters.” They assert that people who believe in starvation economics are often possessive of their work, friends, and things, believing that anything they get has to come from “a small pool of not-enough” and has to be taken from someone else. Further, anything that they have can only be taken from them rather than shared.

I believe that creativity can be conceived of in a similar fashion. If there’s anything that working for Mozilla has taught me, it is that there are always enough (usually too many!) ideas to go around. Embracing creativity as a collaborative process is central to our ethos, and working “default open” should not just be about the final work, it should be also about the journey to get there. Inviting people to provide input into the story as well as the final product will not only make our events, projects, and products better, it will inspire a new kind of work and motivate our communities to find their impact because they have a say in the projects and products they love.

While making project pages public, inviting volunteers to meetings and workweeks, and using public forums rather than personal emails are a start to working in the open, there is still so much more that we can be doing to ensure that a multitude of voices are included in our process. We can learn a lot from other open source communities, but I would posit that we can also be learning from activist communities, non-profits, corporate trainings, and others. We’ve already begun with our speaker series “Learning from other non-profits,” but I look forward to seeing how much more we can do. Breaking down the silos can help us empower and grow our communities in ways we didn’t think possible.

As the community building team asserts,

Mozilla has reached the limits of unplanned, organic community growth.

For many people, one-on-one and personal interaction is the most important part of community, and until we create processes for creating and maintaining these connections as well as systems for mediating the inevitable conflicts that arise within communities working together toward a common goal, we have failed as advocates and community builders.

To that end, I am working with my colleagues to bring process-based solutions into conversation and indeed into the structure of the organization. From Mozilla “guides” who will help contributors find their way in an increasingly confusing contributor landscape to training in non-violent communication and consensus, we want to provide our communities open solutions that make them want to continue contributing and creatively collaborating together. We can do other things as well, like running exciting meetings with innovative structures, providing fun tasks to volunteers, and keeping personal connections vivid and electric with possibility.

On holidays, many Jews traditionally open the door and make a plate for any person who has no place to go. Reinterpreting that for our own creative processes, I would say that we should open the door and leave a place in our work for new people and new ideas because, as we have seen, there is enough. There is always enough.



my first week as a SUMO contributor

People across the Mozilla project point to SUMO (Support Mozilla) as a model of effective contribution.The forums are active, the contributors engaged, and they have systems like the Kitsune API and the Army of Awesome to make contribution simple and fun.

As a lead on the Community Building Pathways working group, I decided to try out a series of different pathways across the organization to see how easy it was to plug into the Mozilla contributor base from coding to SUMO to Webmaker. I’m still trying all of these pathways, but I’ll use this first post to talk about the experience of dedicating time to SUMO in particular.

The first step in becoming a SUMO volunteer is creating a profile. While at first I used the handle I always use (jennierose,) I became a bit concerned about my privacy and changed my name to bibliophile after answering a few questions. I similarly did not feel comfortable answering tweets from my personal twitter account through the Army of Awesome due to the possibility of opening myself up to spam or harassment.

It is definitely possible to contribute to SUMO anonymously, but many people do not. I personally set up my account some months before I started contributing, and I was surprised when my name and picture popped up next to my response. After changing my account to a more anonymous avatar and handle I felt much better about interacting with strangers.

The primary way in which SUMO contributors interact with one another is through the forums, which range in subject matter from Community Discussions to off-topic conversations on a variety of support subjects. There is also an IRC room, which I have not yet explored. SUMO’s tone is overwhelmingly positive, and contributors seem genuinely happy to help one another. I experienced no harassment or behavior in violation of the Code of Conduct, but I wonder how SUMO deals with problem questions or contributors.

I enjoyed the fact that the onus of contribution was entirely autonomous. For example, my post in the “Looking for a Buddy” forum read:

hey all! I’m a Mozilla contributor wanting to create documentation and improve the help forums. I’ve started to do a little alone, but I’d love to have a buddy to help me through the getting started process. I’m also doing a lot of work around mentoring at Mozilla, so I’m really interested in this system and excited to get started with all of you.

and the response:


I’m glad to hear that you want to help with articles! We have a number of tools and helpful documentation to get you started. Here is some helpful information on getting started with using the Knowledge Base (KB).

If you want to help make an article better and easier to understand, you can do that too! You can see what articles need updating by going to Articles:needchanges. Once you submit a change (revision), it’ll then be looked at by a reviewer and if it’s approved, it’ll be published to the site and made live! This link will help you out more. Just scroll down to the bottom until you see Complete list of article writing documentation That’s the go-to stop for editing the KB.

If you need any help, let me know!

What I like about the response is that it is now my responsibility to continue contributing. My buddy provided me the tools, and I know what they are looking for. It’s one step away from a canned response, but it feels personal, includes my handle, and addresses me as an equal. I can easily reach out to this person again and ask for more help, or chat with other people in the forum or work on articles.

In terms of barriers to entry, one has to accept that their first answers to questions or edits to articles may not be definitive or even the best. Since I began, I have provided 6 answers, and only one has been flagged as a solution. (And even then it wasn’t really a good solution!) I answered a few questions and people provided better answers than mine, or understood what the person was asking more concretely because they had more experience. I consider this a part of learning, and my fellow contributors were so gracious that it did not seem an affront.

Something that surprised me about SUMO was how quickly people answered each other and responded to help requests as well as corrected my answers to questions. What was similarly unique was that different people responded; though there is definitely a core group of SUMO contributors, at the same time, the core group is large enough that different people supported my work consistently. Similarly, I was surprised at how little I needed to know in order to answer questions! Every day there are quite a few “low hanging fruit” questions, either questions that you can answer via a Google search or minimal knowledge of the product. I learned a good deal answering support questions, and appreciate how you can choose which questions to answer and consistently find something new to do. There is a constant workflow for SUMO, and the interface makes it easy to find new contributions. Similarly, the contributions are tangible (participate in a forum, answer a question, write an article,) so recognition can be quantified as well.

In short, SUMO is an excellent and simple way to get involved with Mozilla. It is low barrier to entry, self-driven, and moderated extremely well by a large group of people. SUMO may not be for the very shy or the very proud, but for me, it was a great way to begin to grow my technical writing and support forum skills.

Next steps? Hilfe auf Deutsch, naturlich!


What Makes a Pathway Flowchart

I made this flowchart to better explain our “What Makes a Pathway” document to people. One of the things I’ve been doing at work is playing with documentation and metrics to make them more graphic, more exciting, and more engaged and active.

To this end, other wikis I’ve been organizing include the Contribute Lifecycle and Recognition (still in draft). Stay tuned for more graphics and more fun from Mozilla’s Community Building Team!

I’m proud of this one– it’s my first flowchart! Let me know if you see anything I should change.


code4lib wrapup

I had the unique pleasure last week of meeting many brilliant, innovative, and engaging libtech (library + tech) folks at the code4lib conference in Raleigh, NC last week.

Instead of writing all my feelings and thoughts, (and anyone who knows me knows that I have a lot!) I’m going to share my notes and impressions in bullet form below.

  • The pre-conference kicked off with a super workshop on project management called PM4Lib, taught by the amazing Rosalyn Metz and Becky Yoose. They spoiled us by baking incredibly delicious treats, so every other talk was definitely less sweet, though just as good. :) My notes are here
  • I cannot even begin to express my appreciation for the incredible keynote speakers! I am so admiring of the work of Sumana Harihareswara and Valerie Aurora, and to hear them speak was dreamy.  Also, it meant a lot to us to have both keynote speakers be around and open for conversations throughout the conference.Check out Sumana’s talk and Valerie’s interview
  • One awesome part of the conference was getting to hang out in the Hunt Library again.  This was my third time there, and it’s so cool and fun!
  • Similarly, the work of the NCSU librarians is incredible!  After meeting many of them a few weeks ago, I was impressed to hear about their innovative work
  • I gave a lightning talk on “How to be a part of an open source community.” My slides are here, and the actual (super enthusiastic!) talk is here (begin 1:04:50)
  • I still have so much Mozilla swag that I don’t know what to do with it!  Let me know if you want a sticker or a necklace or a pen!

There were quite a few talks at this conference that went way over my head, further solidifying for me that what’s important about conferences is the connections you make and the people you meet. People “threw up code” a lot, which was about as inscrutable as it sounds, though certain speakers did a good job making their code more friendly, in particular Jason Ronallo.

What stood out to me was the conference’s focus on social justice as a library and a tech issue, demonstrated by the choice of keynotes. I have become increasingly disillusioned with the academic library world and what I see as a mostly head down approach to many of the issues that concern us as librarians like access, feminism, and class struggle. To me, social justice and librarianship are deeply intertwined, and to hear librarians cross-functionally stand up and assert that there is a class differential in librarianship was extremely powerful.

Further than that, the safe space of the conference and the constant +1-ing was sweet! Supporting each others’ work made me so happy! One thing I’d like to see next year is a greater inclusion of public libraries in order to expand the scope to include folks who may be disenfranchised or disconnected from the larger community. Academic libraries may be the most prominent sources of technological innovation, but it doesn’t mean that they are the only source.

code4lib was inspiring, but also frustrating because the issues of gender, class, and race within my field were brought into even sharper relief for me. As Valerie Aurora said in her talk (paraphrasing), “Notice when you feel discomfort or guilt. That means you are learning something.” In this regard, I suppose that the my experience at the conference was a success.  We may not solve these problems overnight, and I am not sure that we’ll solve them with code, but I look forward to continue working for positive change in my field as a librarian, a coder, and a feminist.


on pathways, data, and (some of) what Mozilla’s taught me.

tl;dr: Drawing from research and data collection I did on the contribute page as well as a focus group, I am thinking about pathways workflows and how to increase participation within Mozilla and other communities. This post is a wrap-up of some of my internship work.

This post by Adam Lofting is great and everyone should read it, so I am going to begin this piece about onboarding contributors and Mozilla culture with a quote from it:

You’d be forgiven for thinking that working with data and metrics is a clean and scientific-like process of running queries against a database or two and generating a report. In many ways, I’m glad it’s not as simple as that.

Metrics are only as good as the things they enable us to improve. Which means while metrics need to be grounded in good clean data, they are primarily for people; and not just for people to read. In their best incarnation, metrics motivate people to change things for the better. At this scale, motivating people is definitely more art than science…

Over the past few weeks, I’ve analyzed the emails that have come into the “I want to volunteer in other ways not listed on this page” as well as the “I want to contribute Documentation and Writing” categories on the Contribute page at Mozilla.

Some highlights:”seafaring” “All bissnessman can achive a lot” “HIIIIIIIII and THANKSSSSSS” “easy and fast searching the webs” “learnining more about the computer and how it works.” “poker” “i am happy to see you” “firefox” “I want to help”

I read hundreds of examples, and I pulled out only some of the more entertaining above, but here is my data using the controlled vocabulary outlined below.

Emails Received December 1-15, 2013 from “other” category:

Total number of responses collected: 203 
Number of spam/porn-spam: 28 (14%)
Number of suggestions: 7 (3%)
Number of random: 67 (33%)
Number of complaints: 5 (3%)
Number of total lost: 48 (24%)
Number of general “I want to help”: 31 (15%)
Number of donation: 17 (8%)
Number of kudos: 6 (3%)
Number of lost: new pathways: 12 (6%)

(some of these categories overlap, so if the numbering seems off, that’s why)

Of the 203 people who chose to email from the “other” category, almost a quarter of them were lost and intended to contact another team, and a third of them were random. (IE “hello” “d” “yes”) Judging from this data, on the high end, about 43% of the people who write into the “other” category on the website are viable contributors. (I am being generous.)

According to a recent survey given to the people who answer these emails (called “Stewards,”) most categories (like “coding” or “education”) receive less spam or random comments than the “other” and “documentation and writing” category. (Over 50% of stewards said that this comprises 25% or less of the total emails they receive.) About 20% of stewards say that they onboard over 50% of their potential contributors, and approximately 33% claim that less than 10% of potential contributors become active contributors to the project.

So where’s the breakdown with the “other” category?  There are a few issues at play, as I see it:

1. The screenshot below shows what the Get Involved page looks like now:


The “other” category is hidden and difficult to see and all words in the dropdown are very small.

2. The actual descriptions of what you can do for Mozilla are after the fold and below the input box, which can be confusing. Feedback from Ake is to make a distinction between the MoFo opportunities (Education and Webmaker) and more support oriented opportunities (SUMO, Coding, etc).  He says that Education, a robust and viable form of participation, is difficult to see on the page. He suggested to prioritize local events on the page as well. Many local sites on the page are deeply under developed. (Like the poor US community!)

3. Some of our lost potential contributors wanted to make suggestions for other Mozilla projects like Thunderbird or Nightly, not just Firefox, and found this form limiting.

In the pathways working group, we put a lot of emphasis on this page to make it better and open the funnel. Automated emails are not enough, and the act of empowering someone means reaching out means personal connection. As one of my focus group participants put it, “Even if someone says they’re available by email, I assume they’re not.” Excitingly, these issues will largely be solved with a series of refreshes on the page in the next few months.

In order to begin to answer this question of making contact, I drew a loose flow chart that outlines how I see some workflow. (the thing at the end of the broken pathway is a pretty bad drawing of a bomb, signifying that we only have a limited amount of time before we lose someone…)

After going through workflow graphically, I came up with a few community building issues, many of which we’ve talked about in our working groups, meetups, etc.:

1. Where a contributor finds an opportunity is a relevant issue.

My focus group taught me that “hooking” people into contribution pathways is very often a product of face-to-face communication and “demystification” of the sign-up process. HIVEs, Maker Parties, workshops are all common ways to get involved. I personally would have felt far less connected had I not attended the CBT Meetup in December. Stewards make an effort to respond to every email they receive, but receiving an email, even from someone “on the inside” can still feel a bit impersonal. It can similarly feel strange to reach out in writing to a person, and often takes a lot more courage than connecting with someone locally for, say, a cup of coffee. How can we personalize and empower these interactions? What language are we using? How do we deliver on our promises?

As someone who lives in an area with a limited Mozilla presence, I am beginning to think about relative space and the imaginary community and empowerment through the local as a mode for increased participation to 10x contributors in the next year. I have to be the local community in order to create the local community.

2. Focus on the local, or IRL beats URL.

I’ve been reading Jono Bacon’s excellent book The Art of Community, and he talks a lot about “belonging” as a key tenet of building communities, particularly within open source. Belonging is deeply correlated with belief and social capital. This capital can be leveraged in order to create meaningful, scalable contributor flows. Though a community like Mozilla is widely dispersed, becoming a part of that community provides people a sense of belonging to something greater, but every community needs unicorns: that one person (or group of people) who wants to build Mozilla in their community.

Maryann pointed out last week that most people are willing to contribute tons of time to conferences, but when it comes to volunteering over the long term in their community, the response can be a bit lame. It’s the same reason why you may get 100 people to an event but only 2 to your meetings. People get a lot out of events, but they often don’t get much out of meetings. What if we can retool the meeting so that every meeting resembles an opportunity for growth beyond: “You can list this as a thing you do on your resume.” What if every meeting provided a growth opportunity? What if we can rethink meetings in a dynamic way? (I’m also thinking here of Dia Bondi’s storycraft videos)

2.  We can assist and collaborate with existing structures (universities, libraries, public schools, other non-profits) to develop a diverse contributor base without poaching.

After reading Lyre Calliope’s proposal to collaborate with Code for America, I was inspired to rethink my own proposals for larger library and academic contributor bases.  As they write:

There are limits to growth that come from motivated volunteers having to choose which organizations and causes they spend their time aligning with. And as a community organizer, building a local community is super hard when you’re starting from scratch.

When people put their trust and faith in organizations, they can become very motivated, very fast. Most students want to impress their professors or teachers. University or school or a well-run volunteer organization provides people a sense of belonging and a chance to increase their skills. Opening the pathways to contribution could be as simple as drawing on these contexts. Competition does not always have to foster growth; instead one can draw on the organic alignments that their potential community members already feel in the university or volunteer context. This is a missed opportunity within the community building team. Continuing to build Student Ambassadors and aligning with universities globally as well as presenting innovative programming to schools and libraries will bring in contributors, both one-off contributions and longer term communities of LLLs (life long learners.)

On a personal note, I feel like a lot of university technology work is outdated before it has begun, particularly in the humanities. A few years ago I managed a Digital Humanities project that was built on an outdated API that rendered it useless before it was released. Last year I learned PERL at university, the most rapidly shrinking programming language. Aligning with the university or school through innovative curricula or programming is one way to grab attention and provide NEWTs (new and exciting web technologies) to students and professors alike.

3. Never underestimate the power of free.

As most of us who work in education or libraries know, much of the world’s  knowledge is owned by a very small group of corporations. I did a recent research project on Open Access Journals, only to find that the majority of the most respected OAJ are owned by Springer and Elsevier. In my focus group, someone said “Librarians are trained by vendors.” An acronym I recently heard for OCLC (the integrated library system) is “Our Company Loves Cash.”

Similarly, most educational tools are prohibitively expensive and proprietary, which frustrates teachers, administrators, and lawmakers.  How did we get into this mess?

Mozilla can provide some free solutions to these issues, but we do ask for help in return. There are a lot of issues with this; on the badges research call today, we talked about the question of “equity vs access” and attempting to provide the same resources across the board to a group of students. However, resources go further than what a student is provided in a classroom.  Similarly, the computer classes I teach at the Cybrary in Carrboro, the students who are able to go home and practice the skills they learn (obviously) learn much faster than the students who cannot. We cannot expect all people to provide the same amount of time, energy, and resources to a project. We have to cast the net wider to include people and provide them belonging at various stages of contribution. We have to make contribution something you can do with freely available resources and a reasonable amount of time.

Technology has drawn the questions of availability, time economics, and capital into sharper relief than ever before. I don’t have the answers to these questions, but I think that Mozilla can do a better job thinking about conversion points (the point where someone becomes an active part of the community) for contributors and designing not only for participation but also inclusion.

4. No need to reinvent the reinvented wheel all the time (just some of the time.)

At Mozilla we tend to think in the abstract, floating nebulous of excitement. Someone told me recently that it appears to outsiders that we largely operate in a state of buzzing, controlled chaos at all times. (pretty accurate.) We tend to innovate all the time within community at Mozilla and do not always stick to our end goals or always lay out projects coherently from the beginning in order to ship what we want (but really, who does?) We have succeeded thus far through motivation, excitement, and the sweat of a few thousand brilliant people, but I’m beginning to wonder if we can sometimes do more to take into account what we already have, what works, what doesn’t.

This is why I am excited about documents like “What Makes a Pathway?” and our Pathways Roadmap; this is reflective, reflexive work that helps us take stock and be accountable for our actions, learning about what we do well before launching a new project or product that will solve a problem that is not a problem.

5. Communication is key across the organization.

About a month ago I checked my twitter and by chance saw a tweet from someone named Ake Nygren who calls himself a “Mozillarian.” “Huh!” I thought. Through Ake I discovered what I have been lovingly calling the “Mozillarian Sleeper Cell”: a group of librarians already working with innovative educational tools and contributing to the project in various ways.

I would love to see a chart of all the projects we have, both at MoFo and MoCo, to be able to contact someone at each stage, and to leverage the social media that we’re already using (I am particularly excited about our new social media tool Discourse because it’s open and searchable and in this way more graphically accessible than mailing lists.) We have so many modes of communication: IRC, email, facebook, twitter, and now discourse. We need to reach out to someone if we know that they are doing aligned work or know of a resource that will help them, not tomorrow, but right this moment. We need to create a little starter kit or MOOC that will provide people tools across Planet Mozilla through each stage of the Contributor Lifecycle. We need to open the communication, work in the open, and through that, open up communication pathways.

6. Internal education and community culture matters.

Last week a co-worker sat in on a meeting while on vacation. I often receive emails from Mozillians on Sundays, Saturdays, whenever. Mozilla has taught me that you receive what you give. Treat people well, and you will receive good work. Recognition is as much a part of the community as initiation.

Similarly, something that I like about Discourse is that it reminds users to comply with community norms and honor codes before they post, encouraging everyone to behave civilly to one another. I see these kinds of structures as a move to a more thoughtful Internet where trolling and attacking is not an issue because people simply don’t put up with it. I’m sitting in on the Education Working Group now, and I look forward to actively increasing the level of internal learning, communication, and kindness towards one another. I would love to see some of the learning that happens on the staff side (like Tribe) extend further out into the community. Another useful initiative could be to increase mediation through the organization, both on the staff side and the community side. These are the ways in which people learn and grow; as a global movement, we have to do this gingerly and sensitively, and I look forward to exploring these issues further. It is unfair to invite someone into a broken community. We have to be robust and considerate in our actions both with each other and the outside world.

I suppose that this post is as much a wrap-up of my internship as anything, and I am happy to share the news here that I’ll be continuing on in my work at Mozilla. It has been an incredible experience to become enmeshed in this community so quickly and has taught me about the nature of my own work dealing with organization of information, community development, project management, and data-driven opportunities in Open Source.

I still believe that the Mozilla community is self-aware, reflective, and open (and hopefully will for a long time.) I am motivated by the community to stay culturally sensitive and locally minded while working together for our common goal: achieving an open and free web.