Participation Lab Notes: The Sweet Spot Between Constraint and Freedom

Lucy Harris

1 response

Over the past few months you might have heard about a growing community called the Community Design Group. What sets this group apart from many of the other communities at Mozilla is that it does not exist in a region, club, or wiki page. It has only the loosest “membership” and you can come, participate, and leave without ever sharing your name.

The Community Design Group is a sort of transactional marketplace that lives primarily on GitHub. Requests for design can be made by contributors and staff, likewise anyone can tackle or contribute to any design problem that emerges into the Repo.

As Elio Qoshi, the community-side driver of the Community Design Group writes in his blog post:

This allows for a quick contribution path for new contributors in a decentralized manner.  Different labels determine what kind of context issues have, neatly sorted in UX, IX, UI and general Graphic Design, to allow contributors from various backgrounds to jump in.

Since it’s inception in mid-January 25 design problems have been closed ranging from the design of full websites, logos, and style guides. In the past 30 days alone the Repo has received over 2,000 views and 1,000 unique visitors and it exists and flourishes with only minimal staff and community-leader involvement.

MozillaSecurityLogo

CC-BY-SA Elio Qoshi

Despite this early success there is still a great deal to be learned about this model. One of the early realizations about the Community Design Group was the tendency of the community to focus on the creation of logos. These fun and creative projects are excellent opportunities for designers to show their skills and learn from each other, but could potentially dilute the already somewhat crowded logo-sphere of Mozilla.

CC-BY-SA Jenn Sanford

CC-BY-SA Jenn Sanford

Rather than put any stop-energy into the community, we are experimenting with sharing more high-impact opportunities for contribution, initially in the form of a challenge related to the re-branding of Mozilla. In this challenge we’re asking the design community to suggest a new iconic symbol for Mozilla that will shape the thinking of the Creative Team.

In contrast to the well-defined, quick victory, of logos this challenge is ill-defined and complex.
This challenge will close at the end of April and we will have the opportunity to see not only what emerges from the creative pool, but how this work is integrated into the work of the staff team.

CC-BY-SA Sashoto Seeam

CC-BY-SA Sashoto Seeam

The basis of the Community Design Group project was to see what would come of a simple place with minimal rules, where a decentralized community could come to share and create. It is a testament to the power of minimal restriction and functional tools. Over the next quarter I look forward to seeing how far it will grow, and what amazing contributions will emerge from this new community.

Help Firefox Go Faster

mhoye

A wave of new contributors have been asking how they can help Firefox without (necessarily) having strong coding skills, and just at the right time. I’m writing this because Firefox engineering needs exactly that kind of help, right now.

There are a lot of ways you can help Firefox and the Mozilla project, and most of them don’t involve writing code at all. Living in our nightly builds of Firefox is a big deal, and using the Beta release of Firefox on Android, if you happen to be an Android user, helps improve the mobile experience as well.

There’s a lot that needs doing. But one thing we’re really looking for – that Firefox engineering could use your help with today – is bug triage and component ownership.

Developing Firefox in the open with a user base of our size means we get a lot of bug reports. A lot. Hundreds every day, and they come in all shapes and sizes. Some of them are clear, tightly-scoped reports that come with clear steps to reproduce, and those are great. Others are a vaguely-described, hard-to-interpret mess. Most of them are somewhere in between, real problems that are difficult to act on.

Whatever condition these bugs arrive in there’s always a passionate Firefox user behind them with a real problem they care about solving. We know that Bugzilla is not an easy mountain to climb; to respect those users’ efforts we want to give all our incoming bugs enough care and attention to get them from “a user has a problem with our product” to “an engineer has the information they need to make the right decision.”

This is where you come in.

We know what makes a bug a capital-G, capital-B Good Bug from an engineering standpoint – It’s assigned to the right component, it’s steps to reproduce or a regression range if it needs them, and its clear what the next steps are and who needs to take them. For the most part getting bugs from “new” to “good” doesn’t mean writing code – it’s all about organization, asking questions, following up and making sure things don’t get lost.

This kind of work – de-duplicating, cleaning up and clarifying where these bugs are and what’s next for them – is incredibly valuable. We’ve had a handful of people take up this work in the past, often growing into critical leadership roles at Mozilla in the process, and its hard to overstate how much their work has mattered to Mozilla and driven forward the Open Web.

We need people – we need you – to help us keep an eye on the bugs coming to different components, sort them out and ask the right questions to get them into actionable shape. This may seem like a big job, but it’s mostly about organization and persistence.

In the beginning just setting the right flags and ask some questions will help. As you gain experience you’ll learn how to turn unclear, ambiguous bug reports into something an engineer will be excited fix. In the long term someone who really knows their component, who can flag high-priority issues, clean them up and get them to the right engineers, will have an dramatic impact on the product, helping Mozilla make Firefox and the Web better for hundreds of millions of users.

You don’t need much more than a bugzilla.mozilla.org account and a computer than can run Firefox Nightly to get started. If you’ve got that, and you’re interested in taking this up, please email me so that we can match you up to one of the components that needs your help.

Thank you; I’m looking forward to hearing from you.

—Mike Hoye

All Aboard

mhoye

In 1968, Martin Conway noted that “organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.”

Today that’s called Conway’s Law, and to quote Wikipedia:

“The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interfaces structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult.”

Like any metaphorically double-edged sword, Conway’s Law is either a dangerous hazard or a powerful tool; it all depends on which end you grab.

Over the last few months the Firefox Desktop Engineering team has been refining a two-week onboarding program for engineers who’ve recently joined Mozilla. Firefox is a big project with a long history and like Mozilla (and like the Web we’ve made) the codebase and the processes around it can be as clean, streamlined and brilliant in some places as they are confusing and weirdly baroque in others.

One upshot of that is that even for full-time employees it can be hard to know where to start.

So for the last few months we’ve planned and run a series of training sessions. The’re aimed at new Firefox Desktop engineers, to help get them from New-To-Mozilla to Awesome-At-Mozilla as quickly as possible. And they’ve been very successful, not just for new hires, but for veterans and people who work with engineers as well.

But we pride ourselves on working in the open, and we’d like you to be Awesome At Mozilla too. So we’ve put them on Air Mozilla.

Here’s Nick Alexander, taking people through their first Firefox build and bugfix in the Build And Go session:

(Video compression is incredibly unforgiving, when it comes to text. We’re working on that for our next round.)

Other sessions include an introduction to Bugzilla, JS and the DOM, C++ and Gecko, Architecture & Product and more. They’re available on Air Mozilla, in the Onboarding channel, and more will be added as we record them.

If you’re interested in learning about the nuts and bolts of how Firefox is built, structured and shipped, take a look.

– mhoye

Firefox 45 new contributors

Josh Matthews

2 responses

With the release of Firefox 45, we are pleased to welcome the 38 developers who contributed their first code change to Firefox in this release, 30 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:

Firefox 44 new contributors

Josh Matthews

4 responses

With the release of Firefox 44, we are pleased to welcome the 28 developers who contributed their first code change to Firefox in this release, 23 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:

This Month at Mozilla

Lucy Harris

A lot of exciting things are happening with Participation at Mozilla this month. Here’s a quick round-up of some of the things that are going on!

Mozillians Profiles Got a Facelift:

Since the start of this year, the Participation Infrastructure team has had a renewed focus on making mozillians.org a modern community directory to meet Mozilla’s growing needs.

Their first target for 2016 was to improve the UX on the profile edit interface.

new-profile-768x548
”We chose it due to relatively self-contained nature of it, and cause many people were not happy with the current UX. After research of existing tools and applying latest best practices, we designed, coded and deployed a new profile edit interface (which by the way is renamed to Settings now) that we are happy to deliver to all Mozillians.”

Read the full blog here!

There are New Ways to Bring Your Design Skills to Mozilla:

Are you a passionate designer looking to contribute to Mozilla? You’ll be happy to hear there is a new way to contribute to the many design projects around Mozilla! Submit issues, find collaborators, and work on open source projects by getting involved!

  • You can check out the projects looking for help, or submit your own on the GitHub Repo.
  • Sign-up to the mailing list to be added as a contributor to the Repo, added to the regular meeting list, and to get emails about GitHub trainings and more!
  • And read a blogpost about the project and its first meeting.

Learn more here.

136 Volunteers Are Going to Singapore:

This weekend 136 participation leaders from all over the world are heading to Singapore to undergo two days of leadership training to develop the skills, knowledge and attitude to lead Participation in 2016.

Photo credit @thephoenixbird on Twitter

Photo credit @thephoenixbird on Twitter

If you know someone attending don’t forget to share your questions and goals with them, and follow along over the weekend by watching the hashtag #MozSummit.

Stay tuned after the event for a debrief of the weekend!

Friday’s Plenary from Mozlando is now public on Air Mozilla:

If you’re interested in learning more about all the exciting new features, projects, and plans that were presented at Mozlando look no further! You can now watch the final plenary sessions on Air Mozilla (it’s a lot of fun so I highly recommend it!) here.

Share your questions and comments on discourse here.

Look forward to more updates like these in the coming months!

32C3 Report – Chaos Time Zone

Brian King

Written by Valentin Schmitt.

Entering the CCH (Congress Center Hamburg) between Christmas and new year brings you somewhere else than Hamburg on Central European Time.

Most people you’ll meet will say they are from Internet (or the Internets, if they are funny), and for a few days you’ll live in -what a friend of mine called- Chaos Time Zone: a blurry mix of everyone’s time difference. Days are pretty shorts anyway and you’ll probably spend a lot of time under artificial light, so it won’t help your internal clock keeping on track. The organizers will gently remind you the 6,2,1 rule: 6 hours of sleep, 2 meals and 1 shower per day, that should keep you safe. You’ll probably meet a lot of great people, and will often have a hard time to decide which talk or workshop to go to.
This is the 32nd Chaos Communication Congress. Welcome, and have fun!

32C3 Chaos Communication Congress

32C3 Chaos Communication Congress – Photo: Mario Behling

FxOS is not dead.

I looked for a screen printer, or anything to do myself a t-shirt with the message “Firefox OS is not dead!” on it, but very surprisingly regarding the variety of machines there, I couldn’t find any on site. I really wanted to do that, because most of the people I talked to about
Firefox OS answered me “But isn’t Firefox OS dead?”. I bet it won’t come as a surprise for you, as there was a lot of feedback from the community regarding what some might call “a PR disaster”. It just made it very clear to me that we (still) have to communicate a lot on this topic, and very loudly, because the tech news websites will be less likely to spread the word this time.

Once this detail (*cough*) was clarified, almost everybody I had the chance to talk to showed a lot of interested for the project, the only ones who didn’t were the hardcore Free Software enthusiasts, whom have been disappointed by Mozilla recent policy choices (like the tiles with
advertisement, or the DRM support in Firefox desktop), or the people who care less about software freedom and prefer an iPhone to a free (as in freedom) mobile OS.

Mozilla and Firefox at 32C3 with friends

Mozilla and Firefox at 32C3 with friends – Photo: Mario Behling

“Well, it’s Mozilla.”

Mozilla has a pretty good image in the Free Software community, and the main reason why people never tried a Firefox OS device is only because they never had the chance to do so (not many devices marketed in Europe or the US, not many ports on mainstream phones). Fortunately enough, I had some foxfooding devices to hand out. The foxfooding program had a very positive reception, most people were happy to have the chance to try the OS, participate in sending data to Mozilla, file bugs, some were eager to develop apps, and try port the OS on their favorite phone or device (the RasPi got a bunch of them very excited).

More importantly, they really asked me how to flash a device, where to find the documentation to get started, how to file a bug. The people I handed a device to planned to show it to their colleagues, friends and fellow hacktivists, and were very excited to have phone with a hardware good enough to provide a responsive experience.

Questions?

“Is there a Signal app or any secure messaging app?”
“Can I use Tor?”
“Can I keep OSM maps in cache?”
“Is there an app for WhatsApp?”
These were the questions I was asked the most. It’s pretty expected that the hackers community is looking for reliable privacy tools, but I was a bit surprised by the last question that still came up several times. 🙂

Mozillians, assemble!

An assembly is the name the Chaos Communication Congress gives to the physical place (typically a bunch of tables with a power outlet) within the CCH where people can gather to hack, share ideas and have self organized-sessions on a particular topic, or around a particular project, there were 277 registered this year.

Assembling Under The Lights

Assembling Under The Lights – Photo: Hong Phuc FOSSASIA

With the Mozilla Assembly, we had several sessions (directly at the Assembly or in dedicated rooms) over these 4 days:

  • Several Nightly Firefox OS workshops, combining more than 50 participants;
  • The Mozilla community meetup that gathered 20 participants;
  • a Thunderbird session with 42 participants;
  • an IoT and Firefox OS workshop, in a dedicated room that was packed with 90 participants;

On average, there were around 15 Mozillians at the Assembly and a continuous flow of people from different community.

Other projects where Mozilla is involved were represented, like Let’s Encrypt, with a talk so successful that the conference room was full, and New Palmyra, for which Mozillians organized a session for 25 participants.

The hackers and makers communities have a real ethical and practical interest in a mobile or embedded OS that’s trustworthy and hackable, we bear similar values and Firefox OS is a great opportunity to strengthen the ties between us.

Mozilla’s Strategic Narrative for 2016 and Beyond

Lucy Harris

1 response

All around the world, passionate Mozillians are working to move Mozilla’s mission forward. But if you asked five different Mozillians what the mission is, you might get seven different answers.

At the end of last year, Mozilla’s CEO, Chris Beard presented a clear articulation of Mozilla’s mission, vision, role and how our products will help us get there in the next five years. The goal of this Strategic Narrative is to create for all of Mozilla, a concise, shared understanding of our goals that we can use to be more empowered as individuals to make decisions, and identify opportunities to move Mozilla forward.

In order for Mozilla to achieve it’s mission we cannot work alone. We need all of the thousands of Mozillians around the world aligned behind this, so that we can do incredible things at a pace and with a voice that is louder than ever before.

That is why one of the Participation Team’s six strategic initiatives for the first half of this year is to spread this narrative to as many Mozillians as possible so that in 2016 we can have our largest impact yet. We will also be creating a follow-up post that will do a deep dive specifically on the Participation Team strategy for 2016.

Screen Shot 2015-12-18 at 2.02.07 PMUnderstanding this strategy will be crucial for anyone looking to make an impact at Mozilla this year, as it will determine what we advocate for, how we focus our resources, and which projects we focus on for 2016.

As the year kicks off we will dive more deeply into this strategy and share more details of how the various teams and projects around Mozilla are working to further these goals.

The immediate call to action is to think about this in the context of your work and about how you will contribute to Mozilla next year this helps shape your innovations, your ambitions and your impact for 2016.

We hope you will join the conversation and share your questions, comments, and plans for what you will do to drive the strategic narrative forward in 2016 on discourse here or share your thoughts on Twitter with the hashtag #Mozilla2016Strategy.

Mission, Vision & Strategy

Our Mission

To ensure the Internet is a global public resource open and accessible to all.

Our Vision

An Internet that truly puts people first. An Internet where individuals can shape their own experience. An Internet where people are empowered, safe and independent.

Our Role

Mozilla is a true advocate for you in your online life. We advocate for you both within your online experience & on your behalf for the health of the Internet.

Our Work

Our Pillars

  1. Products: We build people-centered products & educational experiences that help people unlock the full potential of their online life.
  2. Technology: We develop robust technical solutions that bring the Internet to life across multiple platforms.
  3. People: We develop community leaders and contributors who will invent, shape and   defend the Internet.

How we lock-in positive change for the long-term.

The “how” matters just as much as the “what”. Our health and lasting impact depends upon how much our products and activities:

  1. Promote Interoperability, Open Source & Open Standards
  2. Grow & Nurture Communities
  3. Champion Policy & Legal Protections
  4. Educate and activate digital citizens

Participation Lab Notes: Participation Champions

Lucy Harris

This year, during the 2016 planning process, an exciting opportunity arose to impact goals around participation across the organization. Chris Beard announced “invite participation” as one of the five top-line guiding principles for 2016 and each team was asked to show a clear connection from one of the top-line principles to their team’s goals for the year.

In order to capitalize on this momentum, the Participation Team formed a group called the Participation Champions to help improve the quality and maximize the impact of teams’ “invite participation” initiatives as they were being built.

Invite Participation Top-Line Guidance:    

  • Empowering people and building community to invent, shape and defend the Internet is core to who we are, and critical to the success of our mission.
  • Participation is key to our ability to have impact at scale. It is both an end and a means. We need it in our work and on the Internet more broadly to achieve and sustain positive change.
  • We must design participation into our products, innovation activities, and efforts to promote our cause.

The key asks for initiatives tied to “invite participation” were: 

  1. Ensure that we are designing for participation.
  2. Find and rally allies, leaders and supporters to our cause, and support their work.
  3. Identify and invest in opportunities to pilot radical and modern participation

The Process

As each team began drafting their 2016 plans and identifying initiatives for the first half of the year, the Participation Team formed a group of 21 staff members from across 11 different teams all who work directly and regularly with contributors. This group of Participation Champions met regularly with the purpose of reviewing the 2016 plans with a focus on “invite participation” to help identify opportunities and adjustments to plans that would increase their capacity to empower people and build community around Mozilla’s mission.

Our process was, first, to collectively review each “invite participation” initiative, specifically considering how it could be strengthened and identifying concerns or missed opportunities. After the collective review, each functional and supporting team was delegated to a different Participation Champion who looked deeply at that team’s goals, and made specific suggestions for strengthening participation in that area. These suggestions were based on both the feedback from the collective review and a more in-depth look at the overarching goals.

We decided that each Participation Champion would communicate those suggestions and feedback directly to the team owner and/or the planning point person. At the end of the quarter we came together assess the impact of our approach, to share what we learned and identify suggestions for future reviews.

The Outcome

Based on the final discussion we concluded that while we didn’t have an immediate and dramatic effect on the plans themselves, this exercise helped drive more conversations about participation, and added accountability to many team’s who hadn’t realized that people would be reading or reviewing their “invite participation” plans.

At the end of this process we had three pairs of findings and suggestions that we will attempt to implement and incorporate into the next strategic planning process:

  • Finding: Teams were willing to talk about increasing participation in their work but reluctant to change the label of initiative to “invite participation”.
  • Suggestion: Change the way the drop-down menus are structured in the planning spreadsheets so that it’s easier for teams to choose multiple top-line guidances. Find ways to emphasize the importance of hitting on multiple top-line guidances instead of just one.
  • Finding: Some parts of the process were uncomfortable because team’s weren’t expecting or ready to have a conversation about their initiatives.
  • Suggestion: Re-think the one-on-one conversation approach for the next planning process and have this kind of review surfaced formally at the start of the planning process so teams are more open/expecting it.
  • Finding: It was difficult to convey a crisp incentive for why teams should care about participation or incorporate it into their plans.
  • Suggestions: Model the potential of participation through “bright light” projects and help individual teams identify their needs that could be met by participation. Additionally, work with managers find ways to tie a team’s success in participation to points, deliverables, or other rewards.

We believe that these planning processes are an excellent opportunity to strengthen participation at Mozilla. Therefore in 6 months we’ll be reconvening the Participation Champions, and based on our experience this round, we’ll spend some time thinking about how we can help move participation forward in the next round of planning! If you’re interested in joining please let me know at lucy@mozilla.com.

Firefox OS Participation in 2015

Brian King

2 responses

TL;DR

Though a great deal was achieved and accomplished through the Participation Team’s collaboration with Firefox OS, a major realization was that participation can only be as successful as a team’s readiness to incorporate participation into their workflow.

Problem Statement

Firefox OS was not as open a project as many others at Mozilla, and in terms of engineering was not structured well enough to scale participation. Firefox OS was identified as an area where Participation could make a major impact and a small group from the Participation Team was directed to work closely with them to achieve their goals. After the Firefox OS focus shift in 2015 from being partner driven development to user and developer driven, participation was identified as key to success.

The Approach

The Participation Team did an audit of the current state of participation. We interviewed cross-functional team members and did research into current contributions. Without any reliable data, our best guess was that there were less than 200 contributors, with technical contributions being much less than that. Launch teams around the world had contributed in non-technical capacities since 2013, and a new community was growing in Africa around the launch of the Klif device.

Based on a number of contribution areas (coding, ports, foxfooding, …), we created a matrix where we applied different weighted criteria. Criteria such as impact on organizational goals, for example, were given a greater weighting. Our intent was to create a “participation sweet spot” where we could narrow in on the areas of participation that could provide the most value to volunteers and the organization.

Participation Criteria

Participation Criteria

The result was to focus on five areas for technical contributions to Firefox OS:

  • Foxfooding
  • Porting
  • Gaia Development
  • Add-ons
  • B2GDroid

In parallel, we built out the Firefox OS Participation team, a cross-functional team from engineering, project management, marketing, research and more areas. We had a cadence of weekly meetings, and communicated also on IRC and on an email list. A crucial meeting was a planning meeting in Paris in September, 2015, where we finalized details of the plan to start executing on.

Team Meeting

Team Meeting

The Firefox OS Participation Hub

As planning progressed, it became clear that a focal point for all activities would be the Firefox OS Participation Hub, a website for technical contributors to gather. The purpose was two-fold:

  1. To showcase and track technical contributions to Firefox OS. We would list ways to get involved, in multiple areas, but focusing on the “sweet spot” areas we had identified. The idea was not to duplicate existing content, but to gather it all in one place.
  2. To facilitate foxfooding, a place where users could go to get builds for their device and register their device. The more people using and testing Firefox OS, the better the product could become.
Firefox OS Participation Hub

Firefox OS Participation Hub

The Hub came to life in early November.

Challenges

There were a number of challenges that we faced along the way.

  • Participation requires a large cultural shift, and cannot happen overnight. Mozilla is an open and open source organization, but because of market pressures and other factors Firefox OS was not a participatory project.
  • One learning was that we should have embedded the program deeper in the Firefox OS organization earlier, doing more awareness building. This would have mitigated an issue where beyond the core Firefox OS Participation team, it was hard getting the attention of other Firefox OS team members.
  • Timing is always hard to get right, because there will always be individual and team priorities and deliverables not directly related that will take precedence. During the program rollout, we were made acutely aware of this coming up the release of Firefox OS 2.5.

For participation to really take hold and succeed, broader organizational and structural changes are needed. Making participation part of deliverables will go some way to achieving this.

Achievements

Despite the challenges mentioned above, the Firefox OS Participation team managed to accomplish a great deal in less than six months:

  • we brought all key participation stakeholders on the Firefox OS team together and drafted a unified vision and strategy for participation
  • we launched the Firefox OS Participation Hub, the first of its kind to learn about contribution opportunities and download latest Firefox OS builds
  • we formed a “Porting Working Group” focused on porting Firefox OS to key devices identified, and enabling volunteers to port to more devices
  • we distributed more than 500 foxfooding devices in more than 40 countries
  • the “Mika Project” explored a new to engage with, recognize and retain foxfooders through gamification – The “Save Mika!” challenge will be rolling out 2016Q1

Moving Forward

Indeed, participation will be a major focus for Connected Devices in 2016. Participation can and will have a big impact on helping teams solve problems, do work in areas they need help with and achieve new levels of success. To be sure, before a major participation initiative can be successful, the team needs to be set-up for success 4 major components:

  1. Managerial buy-in. “It’s important to have permission to have participation in your work”. Going one step further, it needs to be part of day-to-day deliverables.
  2. Are there tools open? Do you have a process for bug triaging and mentorship? Is there good and easily discoverable documentation?
  3. Do they have an onboarding system in place for new team members (staff and volunteers)?
  4. Measurement. How can we systematically and reliably measure contributions, over time, to detect trends to act upon to maintain a healthy project? Some measurements are in place, but we need more.

We put Participation on the map for Firefox OS and as announced at Mozlando, the Connected Devices team will be doubling down its efforts to design for participation and work in the open.

We are excited about the challenges and opportunities ahead of us, and we can’t wait to provide regular updates on our progress with everyone. So as we enter the new year, please make sure to follow us on Discourse, Twitter, and Facebook for latest news and updates.

2016, here we come!

Brian, on behalf of the Participation Team.

(Originally posted on Brian King’s blog)