Firefox 58 new contributors

With the upcoming release of Firefox 58, we are pleased to welcome the 53 developers who contributed their first code change to Firefox in this release, 49 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 57 new contributors

With the upcoming release of Firefox 57, we are pleased to welcome the 53 developers who contributed their first code change to Firefox in this release, 47 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 56 new contributors

With the upcoming release of Firefox 56, we are pleased to welcome the 37 developers who contributed their first code change to Firefox in this release, 29 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 55 new contributors

With the release of Firefox 55, we are pleased to welcome the 108 developers who contributed their first code change to Firefox in this release, 89 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 54 new contributors

With the release of Firefox 54, we are pleased to welcome the 36 developers who contributed their first code change to Firefox in this release, 33 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:

Revitalize participation by understanding our communities

As part of the bigger Open Innovation strategy project on how openness can better drive Mozilla products and technologies, during the next few months we will be conducting research about our communities and contributors.

We want to take a detailed, data-driven look into our communities and contributors: who we are, what we’re doing, what our motivations are and how we’re connected.

Who: Understanding the people in our communities

  • How many contributors are there in the Mozilla community.
  • Who are we? (how diverse is our community?)
  • Where are we? (geography, groups, projects)

What: Understanding what people are doing

  • What are we doing? (contributing with)
  • What are our skillsets?
  • How much time we’re able to devote to the project.
  • The tools we use.
  • Why do people contribute? (motivations)
  • What blocks people from contributing?
  • What other projects do we contribute to?
  • What other organisations are we connected to?
  • How much do people want to get involved?

Why: Understanding why people contribute

  • What are people’s’ motivations.
  • What are the important factors in contributing for Mozilla (ethical, moral, technological etc).
  • Is there anything Mozilla can do that will lead volunteers to contribute more?
  • For people who have left the project:why do they no longer contribute?)

How & Where: Understanding the shape of our communities and our people’s networks

  • What are the different groups and communities.
  • Who’s inside each group (regional and functional).
  • What is the overlap between people in groups?
  • Which groups have the most overlap, which have the least? (not just a static view, but also over time)
  • How contributors are connected to each other? (related with the “where”)
  • How are our contributors connected to other projects, Mozilla etc

In order to answer all these questions, we have divided the work in three major areas.

Contributors and Contributions Data Analysis

Analyzing past quantitative data about contributions and contributors (from sources like Bugzilla, Github, Mailing Lists, and other sources) to identify patterns and draw conclusions about contributors, contributions and communities.

Communities and Contributors survey

Designing and administering a qualitative survey to as many active contributors as possible (also trying to survey people who have stopped contributing to Mozilla) to get a full view of our volunteers (demographics), motivations, which communities people identify with, and their experience with Mozilla. We’ll use this to identify patterns in motivations.

Insights

We’ll bring together the conclusions and data from both of the above components to articulate a set of insights and recommendations that can be a useful input to the Open Innovation Strategy project.

In particular, one aim that we have is to cross reference individuals from the Mozillians Survey and Data Analysis to better understand — on aggregate — how things like motivations and identity relate to contribution.

Our commitments

In all of this work we are handling data with the care you would expect from Mozilla, in line with our privacy policy and in close consultation with Mozilla’s legal and trust teams.

Additionally, we realize that we at Mozilla often ask for people’s time to provide feedback and you may have recently seen other surveys. Also, we have run research projects of this sort in the past without following up with a clear plan of action. This project is different. It’s more extensive than anything we’ve done, it is connected a much larger project to shape Mozilla’s strategy with respect to open practices, and we will be publishing the results and data.

We would like to know your feedback/input about this project, its scope and implementation:

  • Are we missing any areas/topics we should get information about our communities?
  • Which part do you feel it’s more relevant?
  • Where do you think communities can engage to provide more value to the work we are going to do?
  • Any other ideas we are not thinking about?

Please let us know in this discourse topic.

Thanks everyone!

Firefox 53 new contributors

With the release of Firefox 53, we are pleased to welcome the 63 developers who contributed their first code change to Firefox in this release, 58 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 52 new contributors

With the release of Firefox 52, we are pleased to welcome the 50 developers who contributed their first code change to Firefox in this release, 45 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:

  • 166291: 1310835
  • adamtomasv: 1308600, 1312173, 1313565
  • asppsa: 1304019
  • cody_tran95: 1301212, 1301214, 1301223
  • p23keshav: 1314158
  • patrickkerry.pei: 1264929
  • psnyde2: 1315438
  • u579587: 1287622
  • vinayakagarwal6996: 1304097, 1304167
  • Aaron: 1304310
  • Ajay: 1303708, 1304735
  • Alin Selagea: 1315690
  • Amal Santhosh: 1303356
  • Brian Stack: 1275774, 1304180
  • Chirag: 1296490
  • Dave House: 1307904
  • David Malaschonok: 926579
  • Dhanesh Sabane (UTC+5:30): 1308137
  • Dzmitry Malyshau: 1322169
  • Eden Chuang: 1287664
  • Enes Göktaş: 1302855, 1303227, 1303236
  • Francesco Pischedda: 1280573, 1285555, 1291687
  • Fuqiao Xue: 1111599, 1288577
  • Haard Panchal: 1307771
  • Heikki Toivonen: 209637
  • Horatiu Lazu: 1292299
  • Julia Friesel: 1256932
  • Kaffeekaethe : 1256887, 1307676, 1308931
  • Kanika Narang: 1302950
  • Kirti Singla: 1301627
  • Laszlo Ersek: 1304962
  • Leandro Manica: 1306296
  • Manuel Grießmayr: 1311783
  • Mark Golbeck: 1091592
  • Mark Smith: 1308275
  • Matthew Spencer: 1293704
  • Max Liu: 1312719
  • MikeLing: 1287018
  • Nevin Chen: 1310621
  • Petr Gazarov: 1300944
  • Petr Sumbera: 1309157, 1309246, 1315956
  • Robin Templeton: 1316230
  • Samriddhi: 1303682
  • Saurabh Singhal: 1278275
  • Sourav Garg: 1311343, 1311349
  • Umesh Panchaksharaiah: 1301629
  • Vincent Lequertier: 1299723, 1301351, 1304426
  • Will Wang: 1255977
  • William CS: 1295000
  • Yen Chi-Hsuan (UTC+8): 1143421
  • katecastellano: 1256941
  • Open and agile?

    Facilitating openness and including volunteers in agile sprints

    This post is based on a discussion at the Mozilla All-Hands event in December 2016. Participants in that discussion included Janet Swisher, Chris Mills, Noah Y, Alex Gibson, Jeremie Patonnier, Elio Qoshi, Sebastian Zartner, Eric Shepherd, Julien G, Xie Wensheng, and others.

    For most of 2016, the Mozilla marketing organization has been moving towards working agile — much of our work now happens within “sprints” lasting around 2.5 weeks, resulting in better prioritization and flexibility, among other things. (For those familiar with agile software development, agile marketing applies similar principles and workflows to marketing. Read the Agile Marketing Manifesto for more background.)

    However, one aspect of our work that has suffered in this new paradigm is openness and inclusion of our volunteer community in marketing activities. While the agile workflow encourages accountability for full-time team members, it leaves very little space for part-time or occasional participation by volunteers. We are Mozilla, and transparency, openness, and participation are part of our core values. This disconnect is a problem.

    This post explores the issues we’ve found, and shares some potential solutions that we could work towards implementing.

    The problem

    Since moving to an agile, “durable team” model, the amount of interaction we have had with our volunteer community has decreased. This is written from the perspective of the Mozilla Developer Network (MDN) team, but we are sure that other teams have experienced similar negative trends.

    The main reasons for this decrease are:

    • The tools used to track work are not open, so volunteers cannot access them.
    • The agile process in general does not lend itself well to volunteer discovery or contribution. Their work is deprioritized, they feel ignored, they find it harder to participate.
    • There is very little information provided for volunteers who want to participate in a project managed in an agile fashion.

    The challenge we face is how to make the agile process more transparent, so that volunteers can understand what is happening and how it happens; more open so that volunteers can contribute in meaningful ways; and more welcoming so that volunteers feel they are part of a team and are appreciated and recognized for their efforts.

    Solutions

    Let’s look at the solutions that were discussed. These details are fairly brief, but they act as good starting points for further investigation.

    Openness of tools

    We need to review the tools we are using, and make sure that they are open for volunteers to get information and updates. For example:

    • Slack is hard in terms of giving people the right permissions.
    • Some of the “agile tools” can appear closed off and difficult to access for those outside your organization (at least, in the ways we’ve been using them).

    We need to work out better tools/workflows for volunteer contributions.

    Information

    An explainer doc to explain the agile process would be useful, including:

    • How the process works in general, and an explanation of key terms like durable team, “functional team”, “cross-functional”, etc.
    • What the different teams are and what they are responsible for.
    • How to find more information on what you can do for each team at the current time and in the future.
    • How you can contact each team and get updates on their work.

    There is some information that already exists — an explanation of MDN’s agile process, and a glossary of agile terminology.

    When questions are asked, it would be good to make sure that we not only answer them on a public list, but also document the answers to make them easy to find for others.

    When decisions are made, they need to be clearly communicated on the public list for the agile team it relates to.

    Including volunteers

    To participate in an agile team, volunteers need:

    • Access to tools and information, so they can do work and communicate with agile teams.
    • Access to lists of “low hanging fruit” tasks related to the team’s work that they can pick up and work on.
    • A chance for inclusion in the conversation, whether synchronously or asynchronously.

    To achieve this, we need to:

    1. Review our tools, and make sure they can be made open to volunteers.
    2. Make information available, as described in the previous section.
    3. Make lists of tasks that volunteers can do in each agile team easily available. To achieve this, one suggestion is to share Epics with volunteers (don’t overwhelm them upfront with too much detail), but make lists of tasks available on the epic pages, along with who to contact about each task.
    4. Make it clear how you can communicate with agile teams — a clear mailing list and IRC/slack channel would be the minimum.
    5. Keep an open dialog going with our community:
      • Open up planning meetings to allow volunteers to take part in the planning.
      • Say what we are working on next before the sprint starts and what work volunteers can do.
      • Say how things are going during the sprint, and what help we need at each stage.
      • Report on how things went at the end of the sprint.
    6. Make meetings (standups, mid-sprint review, post mortem, etc.) more useful.
      • Include an IRC channel running at the same time, for further communication and to provide notes that people can read afterwards.
      • Allow people to talk about other subjects in meetings, to make them more human.
      • Sometimes conversation can be monotonous (e.g. “I’m still working on the same task” for 5 days running). If this is the case, use the time more usefully.
      • Use the meetings as an opportunity to update volunteer asks; if we find we need more help than we initially thought, do a shout out to the community.
      • Consider office hours for agile teams (whether in Vidyo, IRC, etc.), so team members and volunteers alike can drop in and talk.
      • Record video meetings so others can benefit from them asynchronously.

    We ought to fit communication with the community/volunteers into each agile meeting, as a recurring agenda item.

    Further points

    1. Make sure there is always someone present to help volunteers with questions they have, all the way through a sprint. Keep communication public; don’t let conversations happen in private, then risk the team member going on holiday or something.
    2. We should relax a little on the agile principles/processes — use them where they are useful, but don’t stick to the letter of the law for the sake of it, when it isn’t helpful. As an example, the MDN durable team has gone from everyone having a standup every day, to two standups per week for the writers, and two standups per week for the developers. We found anything more to be too high-frequency, and a waste of time.
    3. One situation that might make using open tools difficult is if any of the work is sensitive, e.g., discusses security issues. We could get around this by dealing with such issues inside private bugs on Bugzilla.

    Next steps

    We want to get feedback on this, and hear about other people’s pain points and solutions or insights for working open inside agile teams. If you have any other thoughts about how the process could be improved, please do share!

    After that, we want to distill this information down in a set of documentation to help everyone in marketing (Mozilla, or otherwise) to be open while working in an agile form.

    Mozilla at FOSDEM 2017

    With over 17 talks hosted in our packed Mozilla Devroom, more than 550 attendees at our booth, and our #mozdem hashtag earning 1,8 million impressions, Mozilla’s presence at FOSDEM 2017 February 4-5 was a successful, volunteer-Mozillian driven initiative.

    FOSDEM is one of the biggest events in the Open Source world and attracts more than 6,000 attendees from all over the world — Open Source advocates, Technical developers, and people interested in Copyright, new languages, and the open web. Through our booth we were able to hear from developers about what they expect from Mozilla — from our tools and technologies, our involvement in the open source community, how we can improve our contribution areas. We had a full day Devroom on Saturday with 17 talks (8 from volunteers) averaging nearly 200 attendees per talk that covered several topics like Dev Tools, Rust, A-Frame and others. There were also presentations about community motivation, Diversity & Inclusion, and Copyright in Europe. Together these allowed us to show what’s important for Mozilla right now, what ideas and issues we want to promote, and what technologies are we using.

    In working with volunteer-Mozillians to coordinate our presence, the Open Innovation team took a slightly different path this year, being more rigorous in our approach. First, we identified goals and intended outcomes, having conversations with different teams (DevTools, DevRel, Open Source Experiments, etc). Those conversations helped us to define a set of expectations and success for these teams. For example, Developer Relations was interested in getting feedback from participants on Mozilla and web technologies, since the event has an audience very relevant for them (web developers, technical developers). Open Source Experiments was interested in create warm leads for project partners, to help boost the program. So we had a variety of goals, which were shared with volunteers, and that helped us to measure the success of our participation in a solid way.

    DevTools talk Graphic

    DevTools talk Graphic

    FOSDEM is always a place to discuss and have interesting conversations. While we covered several topics at the Devroom and at our booth, Rust proved to be a common talking point on many occasions. Although it can be considered a new programming language, we were asked about how to participate, where to find more information and how to join the Rust community.

    All in all, the Mozilla presence at FOSDEM proved to be very solid and it couldn’t had happened with the help of the volunteers that staffed the booth and worked hard. I would like to mention and thank (alphabetically): Alex Lakatos, Daniele Scasciafratte, Edoardo Viola, Eugenio Petullà, Gabriel Micko, Gloria Dwomoh, Ioana Chiorean, Kristi Progri, Merike Sell, Luna Jernberg and Redon Skikuli and a lot of other volunteers that went there to help or only participate at the event. Also big kudos to Ziggy Maes and Anthony Maton, who helped to coordinate Mozilla presence.

    our volunteers at FOSDEM 2017

    our volunteers at FOSDEM 2017

    Some highlight numbers of our presence in this edition:

    • Nearly 200 people on average per talk in our devroom
    • Mozillians directly engaged with around 550 people during the weekend at our booth
    • More than 200 people checked our Code of Conduct for our devroom
    • Our hashtag #mozdem, had around 1,8 Million impressions
    • The Survey we ran at the event was filled out by 210 developers

    There are a lot of pictures and blogposts from mozillians on medium, or in their blogs. If you want to see some tweets, impressions and photos, check this storify.