Participation Lab Notes: Short Simple Tasks Increase Engagement

Lucy Harris

0

The Mozilla Participation Lab is an initiative that focuses on experimenting and surfacing new approaches to Participation. Read more about the Lab on our wiki page.

Every year, about 7 million people come to the contribute page on Mozilla.org looking for information about how to get involved with Mozilla. These visitors represent an exciting opportunity to increase the number of long-term relationships Mozilla has with people who are passionate about the open web.

Right now, however, only about 0.76% of those people ever register to contribute. Even once they’re registered, how we connect them to their contribution area of interest is far from optimized.

In partnership with the Mozilla.org team, the Participation Team has set out on a medium-term project to try and maximize the potential of this page. Our aim is to make it a better tool for potential contributors, Mozilla, and the mission.

The part of this project set out to figure out how to increase engagement with tasks presented to a visitor after they said they were interested in contributing. We designed and ran an A/B test over a few weeks, presenting visitors with different types of tasks.

tl;dr

  • we were able to increase the engagement rate to 60% (from 15%) in selecting tasks
  • visitors preferred simple tasks to challenging tasks, and shorter tasks to long tasks
  • presenting more options (6) versus fewer options (2) increased the number of people who chose to pursue a task

Keep reading to learn more about the results and the future iterations and experiments we have planned.

Experiment

In this A/B test we created four new versions of the contribute sign-up page. Each page presented viewers with a number of tasks categorized either as simple/challenging (variation a) or as taking a little time/more time (variation b). For each of these variations we displayed either 2 or 6 tasks per page.

Variation B : Simple vs. Challenging

Variation B : Simple vs. Challenging

Variation A : Little Time vs. More Time

Variation A : Little Time vs. More Time

For the purpose of this first test we did not track engagement past choosing the specific task, and we did not track engagement with individual tasks, measuring only the category of the tasks selected (eg. simple/challenging or little/more time).

Results

The major findings from this first round of testing were that visitors to the contribute page preferred simple tasks to challenging tasks, and shorter tasks to long tasks. We also found that presenting more options (6) increased the number of people who chose to pursue a task instead of selecting the “not ready” button. Finally across all of the page variations we found the percentage of people who engaged with the pages (either by choosing a task or selecting not-ready) was 60%, much higher than the 15% engagement rate of the original page.

Based on all of the results we can infer that majority of visitors to the contribute page prefer easier, low-barrier tasks, and prefer a handful of choices to just 2.

However there were still a minority of individuals who expressed a preference for more challenging tasks — they may represent skilled contributors who are ready to become deeply engaged in complex projects. In coming iterations of this experiment we will be exploring the level of readiness and skill of these contributors, and whether individuals from this group are more likely to become core contributors than those who selected simpler tasks.

Overall, the enormous engagement rate by both groups further supports the amazing opportunity latent in this page.

Next Steps

Over the coming months we will undertake several rapid iterations on this test. There is a great deal still to be learned, however we believe that through experimenting with participation in venues like this we can unlock huge potential to help people engage with Mozilla in high impact ways.

Over the next few weeks the Participation team will be working to design a second experiment and we will focus on:

  • Enhancing our understanding of the specific kinds of tasks contributors are most interested in
  • How the task completion rate varies among types of tasks and levels of difficulty and what this tells us about the contributors we are able to attract through this page
  • How wording and framing of tasks effects task selection and completion

Other topics we will seek to explore in the longer-term include:

  • Understanding best practices for how to setup second and third tasks to engage contributors in a more long-term way
  • How presenting localized tasks affects completion rate How to identify and present tasks with the maximum appeal to contribute page contributors
  • How to provide “off-shoots” for the non-typical contribute page contributors (such as those who want to contribute code)
  • How to increase the conversion rate from the homepage to the contribute sign-up page If, when and how to collect email sign-ups and what the process is for engaging contributors by email

This project is currently owned by Lucy from the Participation Team in conjunction with the Mozilla.org Team. If you have any questions, ideas for future tests, or if you just want to chat about the future of this page please do not hesitate to get in touch!

Firefox 40 new contributors

Josh Matthews

2

With the release of Firefox 40, we are pleased to welcome the 55 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:

  • ijdt.editor: 1139429
  • kevin.m.wern: 1148694
  • wrahman0: 1132208, 1150514, 1153877
  • Aaron Graham: 892229
  • Aime Galmi: 1084911, 1132213
  • Ali Movahedi: 1154773
  • Anirudh S: 1134494
  • Anthony Tseng: 1158425
  • Anton Myagkov: 1132558
  • Antonio Ladeia: 1123372
  • Atif Iqbal Ahangar: 1150197
  • Bryan Quigley: 1155943
  • Daniel Miller: 699860
  • Darren Lyons: 1147233
  • David Cooper: 667471
  • Denis Volk: 1095098
  • Dipti Nirmale: 1148095
  • Dmitry: 1154676
  • Dmitry Sagalovskiy: 977586
  • Elbart: 1069979
  • Ethan Wu: 1148268
  • Fabian Furger: 1107941
  • Florian Merz: 1063946
  • Giorgos Logiotatidis: 1155579
  • Gordon Klaus: 1155140, 1155648
  • Ilya: 1125816
  • James Lai: 1150800, 1155956
  • Jose Rios: 1161640, 1161666
  • Julian Descottes: 999568
  • Kai Bittner: 1148167
  • Kartik Somani: 1147398
  • Keita Mimura: 1137234, 1149198
  • Kevin Chen: 1097479
  • Kit Cambridge: 1150683
  • Krishnashish Gogoi: 982852
  • Lee Salzman: 1156536, 1158154
  • Martin Tomes: 1084296, 1160487, 1160489
  • Matt King: 952290, 1140592, 1147027, 1150621
  • Michael[tm] Smith: 1096172
  • Morgan Phillips: 1151834
  • Nazim Can Altinova: 1127234, 1144399
  • Németh László: 318040
  • Patryk:Res: 733679
  • Paul17041993: 979705
  • Ross: 1152454
  • Ryan Hamley: 1150484
  • Ryan Nath: 1158547
  • Shane Tomlinson: 1146904
  • Sheefeni Hauwanga: 1142192
  • Shyam Venkatesh: 1157728
  • Taylor Brown: 1018932
  • TheOneisNEO: 1149872
  • Thibaud Backenstrass : 1157661, 1158122
  • Tomas Flek: 1127139
  • bogas04: 1139026
  • cedric raudin: 1079697, 1115365
  • Q3 Objectives for the Participation Team

    Lucy Harris

    After weeks of meetings and planning the Participation Team has decided on six objectives to focus on this quarter.

    Each of these objectives was chosen for it’s ability to bring us closer to our 2015 goal: Demonstrate that participation brings strategic advantage to Mozilla’s key product and functional goals.

    Here are our six objectives for Q3 and the key results for each:

    1. Firefox OS Ignite Initiative has a great, validated community program design

    View on GitHub

    • KR1 – Long-term FirefoxOS community program design
    • KR2 – 50 weekly users of updated Foxfooding tools
    • KR3 – 100 weekly contributors on ‘beta’ community collaboration platform
    • KR4 – 5 “test” events for in-person contribution and community building

    2. Mozilla and Firefox brand building efforts in Germany  boosted by larger and stronger community

    View on GitHub

    • KR1 – Specific areas of contribution and participation measures defined jointly by participation and engagement teams
    • KR2 – 10 new community leaders/organizers recruited and on-boarded
    • KR3 – Events with a total of 1,000 attendees for the purpose of growing community and building issue support

    3. Our Indian community is successfully contributing to Fennec with “local” strategy in mind

    View on GitHub

    • KR1- 25 contributors active and committed on Fennec projects
    • KR2 – Articulation of strategic opportunities/options for bringing local advantage to Fennec

    4. Systematize support for ReMo and communities of focus

    View on GitHub

    • KR1 – ReMo + region/country of focus + partnership performance profile, dashboard and review process is developed and implemented
    • KR2 – Medium-term planning process in 3 communities is developed and tested
    • KR3 – Coaching methods and process for community leaders is systematized

    5. Launch the basics of a refreshed leadership development program

    View on GitHub

    • KR1 – Basic first iteration of “Foundations of Mozilla” curriculum is developed and tested
    • KR2 – Volunteer selection for MozFest, Leadership Summit and Orlando Work Week is strategic and builds trust with volunteer communities, by designing, executing and systematizing a process
    • KR3 – Outline and plan for a Leadership Summit to be held in late 2015 or early 2016

    6. Cross-Mozilla Participation Technology Group is formed and aligned on goals and key questions

    View on GitHub

    • KR1 – Participation Technology Group is formed and trust is built through delivering a first draft of user stories and technology options
    • KR2 – 7 of 9 Mozillians next and Reps abstraction projects delivered

    We work in three week sprints called “heartbeats” and you can follow along with each of these projects on GitHub to see what we will be working on for the next three weeks.

    Can’t find what you’re looking for? Team members also have individual projects and objectives that aren’t directly related to these team objectives. You can read about the other projects we’re working on here.

    Want to get involved? Search for tasks with the “Volunteer Task” label here.

    Meet an MDN Contributor: Heather Bloomer

    Janet Swisher

    2

    Headshot photo of Heather Bloomer

    Heather Bloomer started contributing to Mozilla in November 2014, initially on SUMO. There, she saw a link to MDN, and realized she could contribute there as well. So, she is a “crossover” who contributes to helping both end-users and developers. She has been heavily involved in the Learning Area project, writing and editing Glossary entries and tutorials. She describes her contributions as “a continuing journey of enlightenment and an overall awesome experience.”

    Here’s more from Heather:

    I feel what I do on MDN has personally enhanced my writing skills and expanded my technical knowledge. I also feel I am making a positive impact in the MDN community and for developers that refer to MDN from beginners to advanced. That is an amazing feeling to be part of something bigger than yourself and grow and nurture not only ones self, but others as well.

    My advice for new contributors is to just reach out and connect with the MDN community. Join the team and just dig in. If you need help on getting started, we are more than happy to point you in the right direction. We are friendly, supportive, encouraging and a team driven bunch of folks!

    Thanks, Heather!

    Ten years of evolution of MDN

    Janet Swisher

    3

    Logo for MDN 10 year anniversaryThis week marks the tenth anniversary of Mozilla Developer Network (MDN) as a wiki. This post offers a deep dive into where MDN came from, how it has evolved in various ways, and where it may be going.

    (This post is based in large part on a round table discussion about MDN that was held during the “Hack on MDN” weekend in Berlin in April 2015, and on Florian Scholz’s history of MDN’s JavaScript documentation.)

    What is MDN today?

    For many web developers, MDN is the reference manual for the Web, the place they go to look up or learn about open web technologies. MDN offers much more than that. It is a resource for learning about the Web, and a place for developers to share their skills and knowledge. MDN’s strength lies in its openness, where anybody can help make the resources incrementally better, or substantially better. MDN can also encourage the growth of web technologies into new spaces from where they’ve been in the past.

    MDN is a community of programmers, writers, and localizers. A few of these are paid staff of Mozilla, but they are a subset of the larger community of people who make small or large contributions.

    One of the coolest things for those who contribute to MDN is that every time we talk to developers, they tell us how much they love MDN. It’s not, “Oh MDN is kind of cool,” or “It’s great.” The response is: “I love MDN. It’s the best resource out there.” It’s tremendously gratifying to feel that you are part of something that people really love.

    Who is MDN for?

    MDN serves a variety of audiences:

    • Web developers, first and foremost
    • People who want to teach themselves about web development
    • Teachers of web development skills and concepts
    • Developers in the ecosystem of Mozilla products, such as Firefox add-ons, and Firefox OS apps
    • Developers working on the Mozilla codebase

    Beginnings of MDN

    The site that became MDN, developer.mozilla.org or “Devmo,” started as a redirect to a developer-oriented page on the main mozilla.org site. Later that content was moved over to Devmo; it contained primarily information for developers contributing to the Mozilla codebase.

    Just as the Mozilla project emerged from the remains of Netscape, also MDN as we know it began with documentation originally written at Netscape. The site known as “Netscape DevEdge” documented web technologies, such as JavaScript, and other things that were implemented in Netscape products. After Netscape was acquired by AOL, the DevEdge site eventually was shut down, and that information disappeared from the Web.

    Mitchell Baker (Chair of Mozilla) and others from Mozilla worked out an arrangement with AOL to release the DevEdge content, which she announced in February 2005. At the same time, Deb Richardson was hired to migrate and curate the DevEdge content into Devmo.

    Mitchell and Deb made the decision to put the content into a wiki, to enable open contributions to maintain and update the content. Previously, the DevEdge content was in a CVS source control system, and published as a static site. Using a wiki for documentation was a novel concept at the time, and it took a while for some core developers within the Mozilla project to warm to this way of working. However, others quickly embraced the idea, and the many of the earliest contributors to the Devmo wiki were developers who were active elsewhere in the Mozilla project.

    Deb and some volunteers spent a few months mining and migrating the still-useful content from DevEdge, working on a test server. This effort was still in progress when the content was migrated to the Devmo site, now titled “Mozilla Developer Center” or “MDC” in July 2005. We mark this as the starting point of what we now call Mozilla Developer Network.

    Platform evolution

    MDN has lived on three different wiki platforms in the course of its history: first MediaWiki, then MindTouch DekiWiki, and now Kuma, a Mozilla-developed platform. Looking at the technical infrastructure is interesting not just from a technical point of view, but also because technology influences social structures like community.

    MediaWIki

    The wiki platform used for the first iteration of MDC was MediaWiki, the open source software that underlies Wikipedia. It was the most robust and widely-used wiki at the time. The Devmo project began to discover that software designed for writing a general-purpose encyclopedia was not necessarily ideal for writing developer-oriented technical documentation. For example, it did not handle code examples well, reformatting them to be unreadable. Mozilla tried to fix such issues by creating its own fork of MediaWiki, which then ended up being quite difficult to maintain.

    On the level of contributions, using MediaWiki was initially an advantage, because many technical people were already familiar with how to use it. However, the project eventually reached a plateau, where it became difficult to keep contributors coming back. This, combined with the technical quirks, led to a search for a more user-friendly platform.

    Dekiwiki

    After an evaluation process that looked at all the wiki products available on the market (not just open source ones), the choice was made of DekiWiki by MindTouch. One advantage of DekiWiki was that the source format for articles was HTML, rather than wiki markup. It seemed a logical choice for a site targeting web developers, to have the source format be a standard web language. This required migrating all of the content from MediaWiki markup format to HTML, which was a major migration project. The choice of DekiWiki was announced in November 2007, and the site switched to it in August 2008.

    While DekiWiki was a quality product, one way that the selection process was flawed was that it did not include a major group of stakeholders: volunteers who contributed to the site. The rate of contribution nose-dived, because the platform was not embraced by the contributor community. In particular, localization communities, who translated the content into various languages other than English, were severely disrupted. They had built tools and processes around working with MediaWiki, and these tools didn’t work with DekiWiki. After a few months, many of these groups simply disbanded and decided not to contribute any more, with the result that translated documentation started to become stale, and became more and more out of date over time.

    DekiWiki was also written in C#, and designed to run in a Microsoft .NET environment. This was a mismatch with Mozilla’s technical infrastructure, which is Linux-based. Trying to run DekiWiki on Mono led to a great deal of instability, with the site being down for days and weeks at times.

    These issues, after a couple of years, led to looking for another solution. The best candidates on the market were still MediaWiki and DekiWiki. Now that the content was all written in HTML, migrating back to MediaWiki markup syntax was not feasible. No product seemed suited to the specific needs of an open developer documentation site, so Mozilla decided to create its own.

    Kuma

    The current platform for MDN, known as Kuma, is written in Python with Django. It started as a fork of Kitsune, the platform for the Mozilla support site, and was adapted to the needs of a wiki site for developers rather than end users. (Also, “kitsune” means “fox” in Japanese, and “kuma” means “bear”. Because users : foxes :: developers : bears, right?)

    Like DekiWiki, Kuma uses HTML as the source format for the content. The migration effort in this case was converting the scripts and macros used on the site. DekiWiki used “DekiScript,” based on Lua, while Kuma introduced KumaScript, which is based on JavaScript, using Node.js. KumaScript is the brainchild of developer Les Orchard. As with creating content in HTML, KumaScript means that MDN is implemented using the same technologies that it documents, and that its contributors are familiar with. It was possible to migrate about 70% of the existing macros automatically, but the rest had to be manually converted.

    The goal when launching the Kuma platform was to achieve feature parity with the DekiWiki implementation of MDN. The content was migrated to the new system, and changes from the production server were periodically updated on the Kuma staging server. Thus, the Kuma instance was kept in sync with the production DekiWiki server. While the months leading up to the launch of Kuma were involved a great deal of migration work, the actual launch was very smooth. A routing switch was flipped, and traffic shifted to the new site seamlessly, without even disrupting login sessions.

    Community evolution

    From the beginning, the community for the DevMo site grew organically, starting with contributors who were already active in other parts of the Mozilla project. Like other areas of Mozilla, communication happens through a mailing list and IRC chat channel. By mid-2007, contributions were typically 250 per month. As mentioned before, the migration to Dekiwiki led to a dramatic drop-off in localization contribution, and total contribution declined as well.

    Doc contributors sitting around a table, in Paris, in October 2010

    MDN doc sprint, Paris 2010


    As part of an effort to engage the community more actively, I (Janet Swisher) was hired as a staff technical writer in mid-2010. I brought experience with open source developer documentation, and in particular, experience with the “book sprints” methodology used by the FLOSS Manuals project to produce manuals for free software in five days or less. The first MDN “doc sprint” took place in October 2010, in the Mozilla Paris office. Doc sprints bring together a number of MDN contributors, either physically or virtually, for focussed, collaborative work, typically over a weekend. These were held about once a quarter for about three years. More recently, they have evolved into less frequent but broader “Hack on MDN” events, whose scope includes hacking on the platform or tools, as well as on content, to make them more attractive to developers.
    Idea pitches at HackOnMDN weekend, Berlin 2015

    Idea pitches at HackOnMDN weekend, Berlin 2015


    In addition, the MDN community holds a number of regular online meetings, both for general information, and for tracking specific projects. These community activities, as well as the migration to Kuma in 2012, have led to a significant increase in contributions, now around 1000 per month.

    Branding evolution

    In the beginning, the DevMo site was known as “Mozilla Developer Center.” At first, it simply sported that title, with a simple skin on MediaWiki. With the move to DekiWiki, the word “Mozilla” became the Mozilla wordmark, followed by “<developer center/>”, to convey slightly more webbiness.

    Wordmark for Mozilla Developer Center

    Wordmark for Mozilla Developer Center

    In September 2010, the name of the site was changed from “Mozilla Developer Center” to “Mozilla Developer Network” or MDN. This change was met with some skepticism from the developer audience at the time, though by now they simply accept MDN as MDN. The visual design of the site changed at the same time, to a darker theme, and MDN acquired a logo, the “robot dino,” which it had never had before.

    MDN robot dino logo

    MDN robot dino logo

    Along with these visual changes, features were added to the site to broaden its scope beyond just documentation. One successful feature is known as “Demo Studio”, an area where developers can upload code demos, share them, and show them off.

    When MDN migrated from DekiWiki to Kuma, the visual appearance was preserved, so there was very little visual difference between the pre- and post-migration sites. After six to eight months of bug-fixing on Kuma, a project was started to change not only the visual design, but also the content structure. These changes were rolled out using feature flags, to users who chose to be beta testers. Thus, while most users continued to see the old design, while beta testers saw and tested the new visuals and structure. “Launch day” for the redesign consisted of simply flipping a switch in the database to make the new features visible to everybody.

    The redesign brought not only a new logo, the dino-head-map that we see today, but also structural features like the navigation sidebar, which varies depending on which content area an article is in. In localized pages, items in the sidebar that are not yet translated link to their English versions, and show an invitation to translate them.

    Content evolution

    We mark the start of MDN “as we know it” from the acquisition and republication of the Netscape DevEdge content in 2005. But in the early days, the content was very slanted toward Mozilla products and technology. Not only was there documentation of XUL and internal Mozilla APIs (which are still there), but documentation of web technologies tended to be focused on Mozilla and Firefox, for example, with big banners like “works in Firefox 2.0″ or explanations of Gecko’s support of a feature in the middle of an otherwise neutral article.

    As Mozilla began engaging more actively with the MDN community in 2010, community members began to express a vision of MDN as a vendor-neutral resource for web developers, whatever browsers they are targeting. Adopting this as a strategy required a lot of clean-up effort to remove Firefox-specific content from articles about web standards, and to create the compatibility tables that exist now, with information about all major browsers. Not coincidentally, as the content on MDN became more browser-agnostic, MDN started seeing contributions from other organizations.

    MDN today and tomorrow

    Two current projects on MDN are having a major impact on the shape of MDN in the near to medium term: the Learning area, and the compatibility data project.

    MDN’s information about web technologies has long been a resource for experienced web developers. But it has poorly supported beginners to web development. The aim of the Learning area is to change that by offering tutorials and other resources to people who want to teach themselves about web development. This effort is happening in response to surveys we’ve done of our audience, who reported basic learning material as a significant gap. The Learning area project has been underway for about a year, and in that time has created a large Glossary about web technology concepts, and a number of new tutorials, corresponding to the Web Literacy Map developed by the Mozilla Foundation. The Learning area is a great opportunity to get started in contributing to MDN, since learners and teachers are as needed as technical experts.

    Currently, data on MDN about browsers’ compatibility with web technology features is maintained in tables on the relevant pages. The data is pretty good, thanks to many, many crowd-sourced contributions. But this approach is not very sustainable or maintainable; for example, every table must be replicated on all localized versions of the page. The compatibility data project aims to improve the quality of the data, make data contribution easier, make access to the data easier, and allow reuse of the data, through a centralized data store. This project is action-driven rather than time-bound; contributions and involvement are welcome.

    MDN in 10 years?

    MDN as it exists today is quite different from its beginnings ten years ago. The Web has evolved, Mozilla has evolved, and MDN has evolved. We can expect even greater changes in the next ten years. Perhaps the vision of a direct brain interface to virtual reality “cyberspace” will finally come to pass. We know for sure there will be many more web developers, many more types of devices, and many standards that are not yet written.

    Some things won’t change: Mozilla’s mission will continue to be to work towards an Internet that is a global public resource, open and accessible for all. MDN will continue to be a means towards that mission, by providing resources to enable anyone to become a creator of the Web, and to develop on the Web as a primary platform. MDN’s content, no matter how it’s delivered, will continue to be contributed by a global community of people who are passionate about learning and sharing knowledge about the Web.

    Hacking Tech Evangelism in Bangalore: Q & A With Kaustav Das Modak

    Havi Hoffman

    Back in May, we completed the pilot run of a new program. Mozilla Tech Speakers is designed to empower and support technical evangelists around the world who are serving their communities as speakers and trainers, presenting Mozilla and open web technologies at conferences, workshops, and events. We’ve already posted about the first phase of the program and shared examples of talks and activities from our first cohort of participants.

    Not long after that post went up, I learned that Mozilla Rep and Mozillian Tech Speaker Kaustav Das Modak was organizing a Tech Evangelism Workshop with a group of volunteers from Mozilla India’s Bangalore community. Their goal: Work together over a weekend to build confidence and communication skills for technical evangelism. Have each participant finish the weekend with a new presentation and accompanying blog post or article ready to go. The reported results were impressive.

    Photo by Kaustav Das Modak

    Photo by Kaustav Das Modak

    I invited Kaustav to share his activity and its outcome with more Mozillians, who might want to replicate a version of this event in their own communities. The basics apply for all presenters, so you don’t have to be a technologist to find value. Here’s what I learned from Kaustav (in Q & A format):

    1) Kaustav, tell us a little about who you are and the work you do as a Mozilla contributor and technical evangelist.

    I’m currently working on my start-up, Applait, where we are building a unified layer for real-time communications over the internet.

    I’ve been publicly involved with Mozilla a little over 2 years now. Meeting people all over the world and working on open technologies has been my motivation to volunteer with Mozilla.

    I’ve always enjoyed sharing what I know with everyone else, since my childhood. My inspiration to pursue technical evangelism as a profession, and then as a passion, came from attending a workshop on technical evangelism conducted by Christian Heilmann, Robert Nyman and Ali Spivak in Bangalore in 2013.

    Photo by Kaustav Das Modak.

    Photo by Kaustav Das Modak.

    I was involved with the Mobilizers team during the Firefox OS launch, and I try to coordinate community evangelism for Mozilla in India, whenever I can.

    2) What inspired you to create this event?

    I’ve been planning over a year to conduct workshops to help fellow Mozillians get more confident in presenting themselves. I have helped folks individually all along. But, the Tech Speakers pilot programme finally made me get over the lethargy and actually the start the event. I plan to make this into a series, generating a ton of useful content in the process.

    3) Can you share your thinking about the agenda and how you designed it?

    The core goal of the Tech Evangelism Workshop is to help participants get better at what they are already good at. Participants are asked to choose a topic in which they think they have sufficient knowledge. Then, through the rest of the workshop, they practice building content around that topic – they give 2 presentations, write a talk abstract and an article.

    By the end of the workshop, they realize that they already had the capability within them. The true success of this workshop is to make participants realize that all they needed was to do quality research, better practice and letting go of the shyness within.

    4) What advice would you offer for other Mozillians who would like to organize a training/workshop like this to prepare presentations and practice public speaking? Do you have specific advice for technical presenters?

    One thing that has always helped is to do your homework. _Nothing_ beats a healthy research. Research your audience and respect cultural differences.

    5) What are you planning next? What advice do you have for other Mozillians who want to organize a workshop focused on technical evangelism skills?

    I’m already planning for a second run of this workshop. I’m also eager to help any Mozillian who needs help individually. It’s okay to ping me anytime on IRC, my nick is kaustavdm.

    MDN Contributor of the Month for June 2015: Sebastian Zartner

    Janet Swisher

    Congratulations to Sebastian Zartner, who is the MDN Contributor of the Month for June 2015. Sebastian has contributed a lot to both the content and structure of the CSS reference, including creating a JSON API for CSS pages, and a macro for CSS syntax.

    Sebastian Zartner at Whistler, BC

    Photo: Sebastian Zartner

    Here is an interview with Sebastian, conducted by email:

    When and how did you get started contributing to MDN?
    My first contributions to MDN were back in 2007, so already some months ago. :-) My first contributions were related to German translations to articles, but I also quickly started working on English ones. Some of those contributions were information updates, some of them spelling corrections and I also already started writing a few new articles back then.

    How does what you do on MDN affect other parts of your life, and vice versa?
    Writing on MDN requires some deeper understanding of web technologies on the one hand, and on the other the writer needs to be able to explain those technologies to other people. So by writing those articles, it helps me to learn about and understand the technologies myself and at the same time it allows me to improve my teaching skills. Having said that, what I’m currently mainly working on and what I was awarded for is more background and cleaning up work.

    What advice do you have for new contributors on MDN?
    New contributors to MDN should start by doing small changes to or translating existing articles. If they need help, there is already a lot of information on MDN explaining what to do. And if they prefer to ask someone, there’s always a helping hand [via email and IRC].

    Participation at Whistler

    Lucy Harris

    18674802734_74a153b26c_z
    From June 23rd to 27th, the Participation Team spent an exhilarating and exhausting work week in Whistler sharing and learning about Participation with Mozillians from all over the world.

    During this week we exceeded even our own expectations for  team success. We raised the profile of our team’s diverse expertise as an asset to the goals of every team across Mozilla.  We started a number of conversations about participation across the organization, and ultimately strengthened our own strategy as a team.

    Here’s an overview of what we accomplished, as well as what and where we’ll be headed next.

    What We Did

    Since the Participation Team is new to Mozilla this was our first opportunity to present our goals, ideas, and objectives to the organization and to show other functional areas how we could help them tackle their problems or capture opportunities related to participation. We ended up scheduling sessions with 25 teams across just two days.

    We included volunteers, who acted as co-facilitators for the sessions, and some external experts who helped us to shape what Participation means for Mozilla, and provide value to the functional teams we consulted with.Throughout the week the Reps Council played a key role, acting as an extension of the Participation Team in discussions around the definition of participation and how we better integrate contributors into projects in the future.

    Other accomplishments from the week included:

    1. We built our team team’s trust and relationships (staff and volunteers) and improved our capacity for working together in an integrated and flexible way.
    2. We built and learned a new human centered design framework and applied it with groups across the organization. This is an asset that we can bring to communities and teams across the organization, and use ourselves moving forward.
    3. We moved forward our participation strategy and structures by articulating and co-creating a forward thinking vision and strategy for 18-months from now, which we will share in the near future. We surfaced important issues and conversations.
    4. We rocked a main-stage presentations, showcasing three initiatives that reinforced participation as a strategic advantage to Mozilla: Chota Fennec in India, Marketpulse and Advocacy which you’ll be able to watch on AirMozilla in a few weeks.

    Overall, we grew excitement for a fresh approach to participation across Mozilla. There is a buzz about participation now!

    Where We Want To Go

    19290380002_a60226a8f9_z

    The outcome of the Workweek is that we still need to walk a long path. There’s still many challenges and things to do, and we expect to see a lot of progress and development in this year, and the following. Our proposals to move things forward are:

    1. We will build and continue to develop the  shared vision of success for participation that we started working on during Whistler.
    2. Based on this vision we will identify key priorities for the team and select projects to contribute to to help drive us towards our goals.
    3. We will continue to work with ongoing projects and develop new projects around the organization goals.
    4. We will work closely with volunteer leaders to create a highly effective set of regional/local communities
    5. We will help all interested staff teams create a plan around engaging, sustaining and recruiting volunteers.
    6. We will work to develop a culture of excitement and energy around the strategic impact only possible by empowering volunteer contributors.
    7. We will embed volunteer leadership opportunities and training in all that we do.

    You can follow along with the projects we’ll be working on in the coming months on GitHub here and we’ll also be posting regularly on this blog and from our new Twitter account @MozParticipate.

    You can also see more pictures from Whistler on Flickr here.

    The Participation Team would also like to say a big thank you to all the volunteers, Reps, staff, and experts who joined us this week. We couldn’t have accomplished any of this without you!

    MDN Fellows Successfully Oriented

    Diane Tate

    The first-ever cohort of MDN Fellows convened at the Mozilla Vancouver space the weekend of June 20. This MDN Fellowship Pilot is an experiment for Mozilla to engage advanced web developers in strategic projects at Mozilla to advance our teaching and learning objectives.

    Day 1: Learning About Learning

    One of the first things we did was to collectively identify shared goals for the weekend:

    • Welcome our Fellows into the Mozilla fold.
    • Create ties between our Fellows and their project mentors.
    • Build familiarity with key learning and curriculum design principles.
    • Set up our Fellows for success in creating Content Kits, a new framework designed by both MDN and the Mozilla Foundation to facilitate wide teaching of web content.
    • Understand how the Fellows’ work ties into the broader mission and efforts at Mozilla.

    And Day 1 was an exercise in integrity: because one of the least effective ways people learn is by lecture – and since we wanted our fellows to learn about learning – we all jumped in and engaged with learning content. Bill Mills, Community Manager for Mozilla’s Science Lab, conveyed several principles. A few nuggets that our teams have already started to apply to their projects:

    • Structure curriculum into as small, manageable pieces as possible. This allows instructors and students to customize and adapt the content to their specific needs and learning pace. This also helps avoid the common pitfall of underestimating how much time is required to teach material generally.
    • Employ techniques to identify gaps in learning. For example, it’s possible to design multiple choice answers to flag specific learning errors e.g. if the question is “What is 23 + 28?” and a student selects one of the incorrect answers of “41” then you can assume the student did not properly ‘carry’ in their math.
    • Provide multiple approaches to explain the same issue to avoid the common pitfall of simply repeating the information more slowly, or more loudly ;).

    Day 2: Getting to Brass Tacks

    Day 2 had our Fellows applying their new knowledge to their own projects. They developed a plan of attack for their respective work for the remainder of the Fellowship. Some highlights:

    The Curriculum team was well-served by referencing the Dunning-Kruger effect in designing its pre-requisites list. Specifically, they decided to parse this out using a “get information as you need it” approach for the pre-reqs rather than present their potential instructors with one long daunting list.

    Both the Service Workers team and the WebGL team are embracing the above-mentioned concept of modularizing their content to make it more manageable. Specifically, Service Workers will create different approaches for different use cases to accommodate the evolving nature of its nascent technology; and WebGL will parse out different components so instructors and students can create reusable hackable code samples.

    The Test The Web Forward team is employing “reverse instructional design” so its instructors can help others understand how problems are solved a step-by-step basis that students can dissect rather than simply see the final ‘answers.’ If you’ve heard of “reverse engineering” then “reverse instructional design” should make sense.

    The Web App Performance Teamtaking into consideration the complexity of performance and the difference of optimizing the network vs the front-end, will compartmentalize the courses. To keep the introductory course short & crisp, and to further help trainers & students to master performance, each module will have an advanced follow-up. Examples of bad and good performance are linked throughout the course along with practical code to best showcase these performance tactics.

    How MDN Fellows Support the Mozilla Mission

    Last year MDN began working with our colleagues at the Mozilla Foundation to see how we might partner to advance our common goals of growing web literacy. The work MDN is doing to expand beyond documentation and into teaching and learning dovetails nicely with the Foundation’s efforts to harmonize Mozilla’s learning and fellowship programs. This is a work in progress and we expect our MDN Fellows to play a key role in informing this.

    MDN at Whistler

    Janet Swisher

    The MDN community was well-represented at the Mozilla “Coincidental Work Week” in Whistler, British Columbia, during the last week in June. All of the content staff, a couple of the development staff, and quite a few volunteers were there. Meetings were met, code was hacked, docs were sprinted, and fun was funned.

    Cross-team conversations

    One of the big motivations for the “Coincidental Work Week” is the opportunity for cross-pollination among teams, so that teams can have a high-bandwidth conversations about their work with others. MDN touches many other functional groups within Mozilla, so we had a great many of these conversations. Some MDN staff were also part of “durable” (i.e., cross-functional) teams within the Engagement department, meeting with product teams about their marketing needs. Among others, MDN folks met with:

    • Add-ons, about future plans for add-ons.
    • Mozilla Foundation, about MDN’s role in broader learning initiatives, and about marketing themes for the last half of the year.
    • Firefox OS, about their plans in the next six months, and about increasing participation in Firefox OS.
    • Developer Relations and Platform Engineering, about improving coordination and information sharing.
    • Firefox Developer Tools, about integrating more MDN content into the tools, and making the dev-tools codebase more accessible to contributors.
    • Participation, to brainstorm ways to increase retention of MDN contributors.

    Internal conversations

    The MDN community members at Whistler spent some time as a group reflecting on the first half of the year, and planning and prioritizing for the second half of the year. Sub-groups met to discuss specific projects, such as the compatibility data service, or HTML API docs.

    Hacking and sprinting

    Lest the “Work Week” be all meetings, we also scheduled time for heads-down productivity. MDN was part of a web development Hack Day on Wednesday, and we held doc sprints for most of the day on Thursday and Friday. These events resulted in some tangible outputs, as well as some learning that will likely pay off in the future.

    • Heather wrote glossary entries and did editorial reviews.
    • Sebastian finished a new template for CSS syntax.
    • Sheppy worked on an article and code sample about Web RTC.
    • Justin finished a prototype feature for helpfulness ratings for MDN articles.
    • Saurabh prototyped an automation for badge nominations, and improved CSS reference pages’ structure and syntax examples.
    • Klez got familiar with the compatibility service codebase and development workflow; he also wrote glossary entries and other learning content.
    • Mark learned about Kuma by failing to get it running on Windows.
    • Will finished a patch to apply syntax highlighting to the CSS content from MDN in Dev Tools.

    And fun!

    Of course, the highlight of any Mozilla event is the chance to eat, drink, and socialize with other Mozillians. Planned dinners and parties, extracurricular excursions, and spontaneous celebrations rounded out the week. Many in the MDN group stayed at a hotel that happened to be a 20-minute walk from most of the other venues, so those of us with fitness trackers blew out our step-count goals all week. A few high points:

    • Chris celebrated his birthday at the closing party on Friday, at the top of Whistler mountain.
    • Mark saw a bear, from the gondola on the way up to the mountain-top party.
    • Saurabh saw snow for the first time. In June, no less.