Crowdsourcing is a review of the academic research focused on the (seemingly) new phenomenon by the same name. This book is part of the Essential Knowledge series from MIT Press, which consists of other high-level reviews of prominent topics like Machine Learning, Artificial Intelligence, and others. It is an excellent primer for those looking to gain conversational knowledge of the practice and leads to further reading on the subject.
Brabham regularly discusses open source as a distinct model from crowdsourcing. In fact, he dispels the idea of three types of participation culture as crowdsourcing: open source, marketing voting contests, and (even) Wikipedia-like movements (which I don’t know that I wholly agree with). Despite his repeatedly made distinction, I’ve seen many of the elements of “true“ crowdsourcing within the open source participation culture. At Mozilla, in particular, what was once a more bottom-up organization (the defining distinction, according to Brabham) has become increasingly top-down. Some areas of Mozilla have retained the bottom-up practices (e.g., Rust, MoCo Advocacy), but many have been gradually shifting upward.
What I liked most about this book was that it validated many of the questions that I regularly ask about community and notes that there have been no definitive answers to such questions. In fact, he notes that while many have been researched, many lack significant research. Motivations of the community, for example, has been researched extensively, however, recruitment and retention of community members has virtually no research. Brabham also dispels some of the myths that I’ve worked to dispel throughout most of my career, such as:
[MYTH] Communities consist only of amateurs,
[MYTH] Extrinsic motivators are stronger than intrinsic motivators,
[MYTH] Quality of the amateur community is lacking, especially when the community is untrained in the field they’re participating in,
[MYTH] Crowdsourcing is a cheap and efficient way for organizations to accomplish most tasks.
I recommend this book to anyone who has heard the term, “crowdsourcing.” It provides an essential framework for discussing the practice in professional and social settings.
Localization workshop with Mozilla LATAM community in Lima, Peru, 2015. Look at that beard, yikes!
I’ve planned a lot of community localization (l10n) workshops all over the world. Let’s just say that after six years at Mozilla, it’s approximating 50 at least. They’ve all taken different shapes over the years and as I begin working with local community members and the Mozilla l10n-drivers to plan the last three community l10n workshops for year, there are a number of questions I’m asking myself about these workshops and beyond.
Why do we organize these workshops?
Organizing these things are hard work. Often it’s a lot of fun, but it’s time-consuming and full of variables. Here are some of the reasons we do these:
In an open source community, where the people involved are generally self-organized and the expectation of a bottom-up style of management, it’s crucial for paid staff to travel and meet with volunteer staff (Stormy Peters has some good thoughts on this). This humanizes the people involved, it unifies them all under the organization’s common goals, and gives them the opportunity to voice their ideas, concerns, and opinions to a real person.
To train and give mentorship to community and give community to train and give mentorship to one another.
To dedicate time to projects that support the community but wouldn’t be a typical part of their contributions (e.g., creating translation style guides).
Are these workshops relevant to those attending?
I’m afraid the format of our workshops has grown stale and static. There are so many variables to consider when planning the format of a workshop. The community’s level of maturity, personality differences, cultural differences, varied skill sets, and tenure in the project. The more communities you bring together for a workshop, the more complex it can become. With all these variables, a static workshop format is doomed to failure. But what does a dynamic format look like and how do we know what to adapt to the needs of the communities present?
I’m mulling over several ideas about format that we may try for our last three workshops in 2017.
Mozilla localization unconference — everyone comes with topics they want to discuss or lead a discussion on, the agenda is defined together in the morning and the rest of the weekend is spent moving down the list. This facilitates the need for a dynamic format, as no two workshops would look alike and would largely be planned by those present.
Problem solving — the weekend is spent brainstorming and offering solutions to a problem that either a high number of community’s are facing or a problem that one community is facing.
Rotating topic — rather than organizing workshops to cover all of the regions of the world, workshops would be organized around specific topics or deliverables. The members of the global community that can most successfully contribute to those would be invited. No two workshops would be the same.
Work week with l10n-drivers — with some advanced planning, all l10n-drivers attend the workshop and go about treating the workshop as a team work week. Community will have their pick of contributing to the different projects the l10n-drivers are working on and would see localization from a number of different angles.
What is the right size for a community workshop?
I’ve been in and organized workshops involving one community (around 5 people) and workshops involving fifteen communities (~60 people). I can’t definitively say that one is better than another. The great thing about large workshops is that everyone is introduced to a significant amount of diversity and expands their worldview as a result. It’s hard for the l10n-drivers to have significant personal interactions with each localizer present though. In smaller workshops, you miss the diversity and potential for learning, but the l10n-drivers get more personal time with the localizers and there’s more freedom to dig deep into specific issues that uniquely affect that community.
This year we’ve been organizing large workshops. I’m estimating that we’ll send about seventy invitations to our Berlin workshop. One piece of feedback we’ve gotten consistently is that the Mozilla community wants to see more diversity at these workshops. Organizing larger (but fewer) workshops could help meet that need. But at what point does the workshop become a conference?
How do we determine if our workshops over the course of the year were successful?
We hold ourselves accountable for making sure that the time, effort, and money spent on these workshops yields specific results to measure whether or not the events were successful. This success criteria changes from year to year. It started out being number of strings translated at the event (which was a really bad metric) and has evolved into whether the event has helped communities to meet their own goals. If the format becomes more dynamic, how does this change our success criteria? I don’t have an answer for that yet.
Are workshops the right tool for accomplishing our purpose?
I started this by asking why we organize these, and on paper it seems that, yes, workshops are a great tool for accomplishing those purposes. I suppose this question is better stated as, “are workshops the only right tool for accomplishing our purposes?” I don’t have an answer for this yet. The Web breaks down geographic barriers for collaborating, and while I see the value in moving away from our computers and interacting face-to-face, we’re getting closer to a world where the idea of being face-to-face doesn’t have to mean traveling across land and sea. I’m not sure that we’re really taking advantage of what the Web has to offer to break those geographic barriers.
I’m going to keep asking these questions and I think they’re general enough that the answers will be as dynamic as I hope our workshops become. Get in touch with me if you have thoughts on how to answer any of these questions.
For remote, globally distributed teams like the Mozilla l10n-drivers, time where we can be together in person is precious. For a couple of years, those opportunities have been restricted to the bi-annual Mozilla All Hands, but there was a noticeable gap in our team’s work and unity that meeting twice per year wasn’t filling. Last week marked the first of our revived team retreats (aka work weeks, off-sites, etc.) in Reykjavík, Iceland!
My goals for this retreat were two-fold:
Create an environment of radical participation from each member of the team.
Create an environment that made sharing and collaboration the modus operandi among members of the team.
I wasn’t too concerned about producing something during the work week, mostly because we’ve been highly goal-oriented and decisive since April, 2016. My biggest concern was that this retreat would be the same as past retreats: separated groups working on their own projects, individuals performing their day-to-day tasks, and three individuals attempting to have conversations and make decisions that impact the whole team without their attention. I wanted this practice to remain a relic of the past and to find a format for this retreat that would accomplish my two goals.
This week I returned from Lima, Peru, where we held a localization hackathon and invited active members of the Mozilla localization community in Latin America to attend. Being in Lima with these Mozillians was like getting together with a group of old friends, even though I was meeting some of them in person for the first time. We laughed, we joked, we had deep discussions, and best of all, we worked. We translated strings, reorganized community translation workflows, tested localized versions of Firefox, and planned for upcoming releases of new localizations. It was maravilloso!
Latin America holds a very special place in my heart, as with other regions of the world that I’m regularly involved in. Being a Spanish-speaker, the more I’ve learned about the cultures of Latin America, the more endeared the region is to me. I do whatever I can to help and mentor the localization communities within the region. I visit whenever possible, translate projects when needed for both Mozilla and other open source projects (sorry Fuser, I’m part of the reason there’s never anything to translate for the es-MX iOS project ;-) ). I also recruit new volunteers for Mozilla l10n communities in LATAM and work to improve my cultural understanding of the region as a whole and as individual areas by maintaining my Spanish, learning Brazilian Portuguese, and reading A LOT.
My career is non-traditional. By non-traditional I mean that stating my job title does not give anyone the faintest idea of what I actually do (e.g., you say, “Engineer,” everyone gets it). As you can imagine, this has caused me some problems whenever people ask me what I do for a living. I’ve had to practice many 30-second explanations of what I do. Want some examples? Maybe some of you have heard one or two of these at one point:
“I help make Firefox available to people all over the world.”
“I help global volunteers produce a regionally appropriate version of Firefox for users in their countries.”
“Have you heard of localization? It’s the process of taking a product and adapting it to meet the needs of consumers in a particular region of the world. I do that for Firefox.”
“I drive a variety of projects that allow Firefox and other Mozilla products to be available in over 90 languages around the world.”
“It’s my responsibility to make it easy for global volunteers to adapt Firefox to meet their local needs.”
