MDN Fellows: What They Did & What’s Next

It’s hard to believe our MDN Fellowship Pilot is winding down! Announced in May and oriented in June, our five Fellows and mentors have been heads’ down ever since.  Here’s a short summary of their accomplishments in the program and a taste of what’s next.

Curriculum (Steve Kinney, Fellow; Chris Mills, Mentor)

For the curriculum Fellowship we selected to write a full course on “Advanced beginning JavaScript.”  Steve and Chris considered this to be important because, while there are loads of resources looking at beginner-level stuff like variables and basic function usage + a load of discussion of really advanced techniques, there is very little to help a budding developer who has already mastered the basics and wants to level-up their skills.

Steve and Chris are still working on the course, and will be for weeks to come — see the repo, and read the index file for an idea of the content we’ll include.

If you want to dig in right away, you can already start working through some of the tutorials and demos.

Service Workers (Flaki Szmozsanszky, Fellow; Brittany Storoz + Anne Van Kesteren, Mentors)

With more widespread browser support for service workers fast approaching, we were aiming for creating a “baseline” service worker content kit. It was to cover the general, high-level “what are service workers and why should I care?” questions as well as being able to provide resources for interested parties. Take a test drive of the content kit here.

Beyond just collecting and completing the above baseline content kit, during the Fellowship Flaki had the chance to work closely not just with his service worker mentors Brittany Storoz and Anne van Kesteren but also with the content & platform teams at Mozilla who work hard on implementing service workers and related features in Firefox & Firefox OS.

We also devised a proof-of-concept transparent image format polyfill that uses service workers, which, besides being a novel approach in using service workers, helped a lot in uncovering some lurking bugs in Firefox’s preliminary implementation. We especially want to thank Ben Kelly of the platform team who was invaluable in tracking down, reporting and fixing those issues.

See this blog post for more details on the content kit and the proof-of-concept polyfill.

Test The Web Forward (Ben Boyle, Fellow; James Graham and Josh Matthews, Mentors)

As Test the Web Forward already has great documentation on getting involved, we had two goals: (1) address the quality of the contributions, and (2) build confidence in new contributors.

We’ve focused on understanding web specifications in order to write accurate tests both in terms of coverage (understanding the detail in a simple specification) and in challenging assumptions so that tests are based on what the spec says (and not what we think it means).

We’ve set up a codepen to use the testing framework. This can be forked to write new tests to check behaviour and is useful for exploring a problem, or for accompanying bug reports. It’s a nice quick way to get started, before installing the Test the Web Forward repo to contribute directly.

We are also working on a couple of case studies (more to come) showing the experience after finding an interoperability issue including researching the specs and analysing the behaviour seen in browsers. Each journey is different, and a wonderful chance to learn more about the web.

Web App Performance (Vignesh Shanmugam, Fellow; Harald Kirschner, Mentor)

With the increase in average website size, we need to better access the web from varying levels of computing power devices and experiments to show the impact on revenue with the increased load times – particularly during development.

The content kit that we are building helps web developers and others understand basic techniques for their websites to load faster. The focus is heavily on the network side of the performance since 70% of the time is spent on the network. Our Content Kit also has various beginner and advanced tutorials, slides and demos.

The kit is not complete yet. We are also planning to include lots of deep dive tutorials on understanding packet level information on TCP stack, how to leverage modern capabilities in browser etc. Please feel free to pour in your ideas.

It was an amazing experience to work with the fellows and mentors who are all part of the MDN fellowship program. Thanks to Mozilla for making this happen 🙂


WebGL (Greg Tatum, Mentor; NIck Desaulniers, Mentor)

It has been really exciting being part of the first Mozilla Fellowship group. One of the big reasons for my involvement with the web and open source communities is the feedback from my peers and the quick sharing and collaboration on ideas. The fellowship has quick-started my involvement with MDN and their enthusiastic team of staff and contributors. One of the most valuable experiences was being able to write an article for MDN and get immediate in-person feedback from one of the staff writers. It was really empowering to know that the docs I use every day are so easily improved.

I had a blast diving into explanations of some of the fundamentals of how you go from abstract data to 3D-rendered images in the browser. It was really helpful for my own understanding to build out content kits and articles that step through matrix math fundamentals, the 3d projection process, and finally getting to taking that data and lighting it.

I’m very passionate about creative coding and the technologies surrounding it. It still feels like a niche genre with a community that is growing, especially with people moving from desktop applications to web projects. I only want this community to get larger and produce more and more interesting works that inspires me. I hope my time spent with the Mozilla Fellowship and other open source contributions can help to continue to grow people’s knowledge and interest in technologies like WebGL.

Content kits

Shared utility library for WebGL explanations:

MDN Articles based off of the content kits:

…with Lighting Models coming soon

What’s Next?

We’ll be evaluating the role that this type of program might make towards the goals of both MDN and Mozilla overall. You also might see more contributions on MDN from our Fellows. And rumor has it you may be seeing some of this great work – and even contributing to it – at our November MozFest event in London.
Can’t get to London? Nothing’s stopping you from diving into those repos.

Firefox 41 new contributors

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

Participation Lab Notes: Short Simple Tasks Increase Engagement

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 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 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.

This first experiment 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.


  • 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.


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).


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 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

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

    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

    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

    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, or “Devmo,” started as a redirect to a developer-oriented page on the main 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.


    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.


    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.


    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

    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

    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

    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


    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!