MDN Articles

Sort by:


  1. Announcing the MDN Fellowship Program

    For nearly a decade, the Mozilla Developer Network (MDN) has been a vital source of technical information for millions of web and mobile developers. And while each month hundreds of developers actively contribute to MDN, we know there are many more with deep expertise in the Web who aren’t participating—yet. Certainly MDN and the Web would benefit from their knowledge and skill, and we’re piloting a program to provide benefits for them as well.

    Mozillians at Summit 2013.

    Mozillians at Summit 2013. Photo by Tristan Nitot.

    What it is

    The MDN Fellowship pilot is a seven-week part-time (5-10 hours per week) education and leadership program pairing advanced web and mobile developers with engineering and educational experts at Mozilla to work on significant, influential web projects. Fellows will contribute by developing apps, API descriptions, and curriculum on MDN for their project. They will also receive hands-on coaching from project mentors, as well as others at Mozilla who will provide training and guidance on curriculum development, so that their work can be taught to others.

    An overview of projects

    Here’s a look at some of the technical topics and the associated project tasks we’ve identified for our first group of MDN fellows.

    • ServiceWorkers essentially act as proxy servers that sit between web applications, the browser, and (when available) the network. They are key to the success of web apps, enabling the creation of effective offline experiences and allow access to push notifications and background sync APIs.
      What you’ll work on: You’ll write a demonstration web app (new or existing) to showcase Service Worker functionality and provide detailed API descriptions.
    • WebGL is the latest incarnation of the OpenGL family of real-time rendering immediate mode graphics APIs. This year WebGL is getting some cool new features with the publication of standardization efforts around the WebGL 2.0 spec.
      What you’ll do: Develop a curriculum on MDN for teaching the WebGL APIs developers new to graphics programming.
    • Web app performance. App performance is impacted by many factors, including serving content, rendering, and interactivity. Finding and addressing performance bottlenecks depends on tooling the browser networking and rendering but also (and often more importantly) user perception.
      What you’ll do. Develop a curriculum on MDN for teaching developers to master performance tooling and to develop web apps with performance as a feature.
    • TestTheWebForward. Mozilla participates in an important W3C initiative, TestTheWebForward, a community-driven effort for open web platform testing.
      What you’ll do: Review various existing technical specifications to identify gaps between the documentation and current situation. Refine existing tests to adapt to this cross-browser test harness.
    • MDN curriculum development. MDN serves as a trusted resource for millions of developers. In 2015, MDN will expand the scope of this content by developing Content Kits: key learning materials including code samples, video screencasts and demos, and more.

      What you’ll do: Act as lead curator for technical curriculum addressing a key web technology, developing code samples, videos, interactive exercises and other essential educational components. You may propose your own subject area (examples: virtual reality on the web, network security, CSS, etc.) or we will work with you to match you based on your subject area knowledge and Mozilla priorities.

    “I’m looking forward to working with a Fellow to make low-level real-time graphics more approachable,” says WebGL project mentor Nick Desaulniers. More information, including project mentors and the type of skills & experience required for each project, can be found on the MDN Fellowship page.

    MDN writers

    Photo by Tristan Nitot.

    How to apply

    If any of these projects sounds interesting, check out the website and apply by April 1. We’ll announce the fellows in May and start the program in June by bringing fellows and mentors together to get everyone familiarized with their projects and one another. Then, for 6 weeks, you’ll work directly with your mentor on your project from your home base. You’ll also receive ongoing feedback and coaching to set you up for success on teaching what you’re building to larger groups of developers.

    Here’s a timeline:

    • Now – April 1: Apply!
    • April: Finalist candidates will be interviewed.
    • May: Fellows are announced.
    • June (dates & location TBA): Orientation at a Mozilla space.
    • June 29 – August 3: Work on your projects + regular team calls to receive coaching on your work.
    • August 11-12: Graduation

    This program is for you if…

    You code, document, and ship with confidence, and now you’d like to start sharing your skills with a broader community. Maybe you want a way out of the walled garden and you’d like to contribute to Mozilla’s mission of keeping the web open for all. Perhaps you want to be effective at sharing your expertise with a wider audience.

    Consider this program if you want an opportunity to:

    • Amplify the impact of your technical expertise by contributing to influential, significant projects at Mozilla.
    • Stretch your technical expertise by working closely with Mozilla technical mentors.
    • Integrate educational best practices into your work with Mozilla teaching mentors.

    Check out the MDN Fellowship website, apply by April 1, and encourage others as well!

    Mozillians at Mozcamp Warsaw. Photo by Tristan Nitot

  2. New on MDN: Sign in with Github!

    MDN now gives users more options for signing in!

    Sign in with GitHub

    Signing in to MDN previously required a Mozilla Persona account. Getting a Persona account is free and easy, but MDN analytics showed a steep drop-off at the “Sign in with Persona” interface. For example, almost 90% of signed-out users who clicked “Edit” never signed in, which means they never got to edit. That’s a lot of missed opportunities!

    It should be easy to join and edit MDN. If you click “Edit,” we should make it easy for you to edit. Our analysis demonstrated that most potential editors stumbled at the Persona sign in. So, we looked for ways to improve sign in for potential contributors.

    Common sense suggests that many developers have a GitHub account, and analysis confirms it. Of the MDN users who list external accounts in their profiles, approximately 30% include a GitHub account. GitHub is the 2nd-most common external account listed, after Twitter.

    That got us thinking: If we integrated GitHub accounts with MDN profiles, we could one day share interesting GitHub activity with each other on MDN. We could one day use some of GitHub’s tools to create even more value for MDN users. Most immediately, we could offer “sign in with GitHub” to at least 30% (but probably more) of MDN’s existing users.

    And if we did that, we could also offer “sign in with GitHub” to over 3 million GitHub users.

    The entire engineering team and MDN community helped make it happen.

    Authentication Library

    Adding the ability to authenticate using GitHub accounts required us to extend the way MDN handles authentication so that MDN users can start to add their GitHub accounts without effort. We reviewed the current code of kuma (the code base that runs MDN) and realized that it was deeply integrated with how Mozilla Persona works technically.

    As we’re constantly trying to remove technical debt that meant revisiting some of the decisions we’ve made years ago when the code responsible for authentication was written. After a review process we decided to replace our home-grown system, django-browserid, with a 3rd party library called django-allauth as it is a well known system in the Django community that is able to use multiple authentication providers side-by-side – Mozilla Persona and GitHub in our case.

    One challenge was making sure that our existing user database could be ported over to the new system to reduce the negative impact on our users. To our surprise this was not a big problem and could be automated with a database migration–a special piece of code that would convert the data into the new format. We implemented the new authentication library and migrated accounts to it several months ago. MDN has been using django-allauth for Mozilla Persona authentication since then.

    UX Challenges

    We wanted our users to experience a fast and easy sign-up process with the goal of having them edit MDN content at the end. Some things we did in the interface to support this:

    • Remember why the user is signing up and return them to that task when sign up is complete.
    • Pre-fill the username and email address fields with data from GitHub (including pre-checking if they are available).
    • Trust GitHub as a source of confirmed email address so we do not have to confirm the email address before the user can complete signing up.
    • Standardise our language (this is harder than it sounds). Users on MDN “sign in” to their “MDN profile” by connecting “accounts” on other “services”. See the discussion.

    One of our biggest UX challenges was allowing existing users to sign in with a new authentication provider. In this case, the user needs to “claim” an existing MDN profile after signing in with a new service, or needs to add a new sign-in service to their existing profile. We put a lot of work into making sure this was easy both from the user’s profile if they signed in with Persona first and from the sign-up flow if they signed in with GitHub first.

    We started with an ideal plan for the UX but expected to make changes once we had a better understanding of what allauth and GitHub’s API are capable of. It was much easier to smooth the kinks out of the flow once we were able to click around and try it ourselves. This was facilitated by the way MDN uses feature toggles for testing.

    Phased Testing & Release

    This project could potentially corrupt profile or sign-in data, and changes one of our most essential interfaces – sign up and sign in. So, we made a careful release plan with several waves of functional testing.

    We love to alpha- and beta-test changes on MDN with feature toggles. To toggle features we use the excellent django-waffle feature-flipper by James Socol – MDN Manager Emeritus.

    We deployed the new code to our MDN development environment every day behind a feature toggle. During this time MDN engineers exercised the new features heavily, finding and filing bugs under our master tracking bug.

    When the featureset was relatively complete, we created our beta test page, toggled the feature on our MDN staging environment for even more review. We did the end-to-end UX testing, invited internal Mozilla staff to help us beta test, filed a lot of UX bugs, and started to triage and prioritize launch blockers.

    Next, we started an open beta by posting a site-wide banner on the live site, inviting anyone to test and file bugs. 365 beta testers participated in this round of QA. We also asked Mozilla WebQA to help deep-dive into the feature on our stage server. We only received a handful of bugs, which gave us great confidence about a final release.


    It was a lot of work, but all the pieces finally came together and we launched. Because of our extensive testing & release plan, we’ve 0 incidents with the launch – no down-time, no stacktraces, no new bugs reported. We’re very excited to release this feature. We’re excited to give more options and features to our incredible MDN users and contributors, and we’re excited to invite each and every GitHub user to join the Mozilla Developer Network. Together we can make the web even more awesome. Sign in now.


    Now that we have worked out the infrastructure and UX challenges associated with multi-account authentication, we can look for other promising authentication services to integrate with. For example, Firefox Accounts (FxA) is the authentication service that powers Firefox Sync. FxA is integrated with Firefox and will soon be integrated with a variety of other Mozilla services. As more developers sign up for Firefox Accounts, we will look for opportunities to add it to our authentication options.

  3. Technical Blogger? Mozillian? Here's a plugin for you to tell us about your work!

    One great thing about Mozilla is that we want people to have a voice. Our products give people a voice on the web without being spied on. As a Mozillian, you don’t have to go through various levels of red tape before you are allowed to speak out in public.

    many voices one mozilla

    As Mozilla grows, it becomes more difficult to stay in touch with what people are saying. Mozilla is many voices, but there is also a lot of noise on the web and others scream loudly about what they do, too. We can help each other being heard by speaking together and tell other people about what we do. We’re not really playing to our strengths when the people in Mozilla who communicate to the outside world hear about great work by Mozillians by chance or from other sources.

    This is why we wanted to make it easier for you to tell us when you created something interesting. That’s why Luke Crouch (@groovecoder) of the Mozilla Devengage team extended the functionality of the “Promote MDN” WordPress plugin.

    promote mdn

    Originally, this plugin was meant to promote MDN by automatically linking certain words in your posts to the correct Wiki pages. We talked about it before here.. Now we added an extra feature: when you write a post, you get a checkbox in the editing screen that says “Notify Mozilla of this post”:

    notify mozilla checkbox in the new post screen of wordpress

    When checked, publishing the post will automatically send an email to the Mozilla developer engagement team and the Mozilla communications team about your post. That way we can visit your blog, check what you wrote and give you the promotion your work deserves. This could mean tweeting about your article, creating a follow-up post on the Hacks blog, or whatever seems appropriate to the situation.

    The Promote MDN plugin still does what it was supposed to do when we originally released it: it links various expressions in your text to MDN for people to read up. These expressions are maintained on the Mozilla Wiki ( and you have many customisation options allowing you even to fully opt out of this feature:

    promote MDN options screen

    You can become a trusted expert simply by telling us when you post. We can help get your message much further and you could become a go-to person for us when we need an expert on a particular topics. None of this is mandatory, we just want you to know the opportunity is there to take advantage of.

    Get the Promote MDN WordPress Plugin here. If you are interested in modifying the plugin for your own company needs, Luke also made the source code available on GitHub.

  4. The Mozilla Developer Network has a New Face

    Last summer the Mozilla Developer Network (MDN) underwent a massive platform change, moving from a hosted third-party solution to our own custom Django application code-named Kuma. That move laid the ground work for our latest major MDN upgrade: a complete front-end redesign, included many new features as well as usability and accessibility enhancements. Let me provide you with a quick overview of what you can expect to see on the new MDN and what features we’re cooking up for the future!

    New MDN Features

    Increased Commitment to Search

    The majority of MDN users are looking to find documentation the moment they land on the MDN homepage, so we’ve placed search front and center:

    We’ve also added search filters to the mix, allowing users to narrow down search results to their specific needs:

    From a technical perspective, we’ve moved to Elasticsearch for search, allowing us to continue making indexing and filtering improvements, as well as add new search features at will. We anticipate fine-tuning search as we receive feedback so we’ll continue the push to get you to better documentation faster.

    Ease in Navigation

    Getting from document to document was a pain point in the previous design, so we’ve fixed that in two ways. The first was creating Content Zones, a method for creating navigation for a given topic. We’ve started with the most prominent parts of MDN, including App Center, Firefox, Firefox OS, Firefox Marketplace, Add-ons, and Persona:

    Content Zones

    MDN’s new Content Zones provide a complete collection of documentation about a given topic, encompassing the very basics of a topic to API details and advanced techniques. We’ll be kicking off with the following zones:

    Firefox OS

    Highlights of the Firefox OS zone include:

    • A detailed Platform Guide
    • Build and Install details
    • Hacking Firefox OS
    • App Design & Development
    Firefox Marketplace

    Highlights of this zone include:

    • App submission and review
    • App publishing and monetization
    • Marketplace API information
    App Center

    Highlights of the App Center zone include:

    • Quickstart Guide
    • Design and Build tips
    • App publishing guidelines
    • API references

    Highlights of the Persona zone include:

    • Guide to using Persona on your site
    • Becoming an identify provider
    • Details on the Persona project

    Highlights of the Firefox zone include:

    • A complete Firefox Add-on overview
    • Information on Firefox internals
    • Detailed instructions for building Firefox and contributing

    Highlights of the Add-ons zone include:

    • XUL extension information
    • Best practice tips
    • Theming
    • Add-on publishing guidelines

    “See Also” Links

    We’ve also implemented “See Also” links which may appear in any wiki page, linking to documents which may be relevant based on the document you’re currently viewing.

    Both the zone subnavigation and “See Also” link sidebar widgets are built from basic link lists in the wiki document, so adding links and shuffling navigation is easy for anyone looking to contribute to MDN. These link lists can also be built using MDN’s macro language, Kumascript, and our writing team has done a great job automating “See Also” links so that contributors can save on the manual labor of hunting down other relevant documents.

    Top level navigation

    In the top level navigation, you will have access to five distinct areas:

    • The above-mentioned Content Zones
    • Web Platform, including direct links to more information on technologies, references and guides
    • Developer Program – To be able to help developers and establish long-term relationships and channels, we have created the Mozilla Developer Program. We have a lot of plans and ideas for iteratively expanding the Program, and we want you involved as we do so! So, sign up! You will get a membership, be able to subscribe to our newsletter and get access to features over time as we roll them out.
    • Tools – more information on the Firefox Developer Tools and their features
    • Demos, being a direct link to the Demo Studio

    Enhanced Kumascript Macro Features

    Kumascript, MDN’s dynamic macro language, was also outfitted with the ability to read external RSS feeds. At present MDN is using the feed reader capability to pull forum posts from StackOverflow and blog posts from the Mozilla Hacks blog. Check out the MDN:Common macro to view the fetchJSONResource and fetchHTTPResource methods which aid in displaying feed content in wiki documents.

    Future Features

    This visual redesign is just the beginning of our push to make MDN more dynamic and usable. The MDN development and UX teams have plenty more coming in 2014. Here are a few peeks into what you can expect to see!

    Dynamic Search Filtering

    To improve the efficiency in user search, we plan to implement hashtag-prefixed text filtering which may be added in the initial search — doing so will prevent the need for additional filtering when the user lands on the search results page.

    Holly Habstritt Gaal has detailed this query system in detail on her blog. Check out her blog post to see implementation details.

    Docs Navigator

    So you’ve completed a search and you click the first link you thought would be applicable, but you want to move onward and view other results. Instead of backing out to the search results page again, the wiki page (if the user came from search) will display a doc navigator to move to the next or previous result, or you can view the entire list of results from your original search:


    Just another handy way of finding what you need faster!

    Demo Studio and Dev Derby Redesign

    A redesign to the MDN Demo Studio and Dev Derby will be coming shortly. We have an excellent design in review and we hope to roll that out in early 2014.

    If you have a suggestion or find any bugs within the new MDN, please let us know.

    Look forward to more from MDN in 2014 and beyond. The MDN platform promises to expand and improve the way we view, write, and experience documentation and web technologies!

  5. MDN community news moving to about:community

    News about the Mozilla Developer Network (MDN) community, such as doc sprints, community meetups, and so on, has a new home on the Mozilla about:community blog, in the Developer Engagement category. This category will also cover other news related to the community involved in developer engagement/relations/outreach/evangelism (whatever you want to call it) for Mozilla.

    Subscribe to the Developer Engagement category feed to stay up to date, and head over there to check out the first post in the category:

    MDN doc sprint with Mozilla Francophone community

  6. Introducing… our new evangelists

    It is with great pride that we can announce three new faces in our midst, three people Mozilla just managed to hire to do Firefox OS developer outreach. Over the next few months you will hear and read a lot from these, that’s why we thought we start by introducing them with some short interviews.

    Jason Weathersby

    Jason Weathersby The first of the new bunch to sign up is Jason Weathersby, based in Inman, South Carolina in the United States. You can reach Jason on Twitter as @JasonWeathersby. When asked for a one liner about what he is looking forward to the most in this new role he stated “I am looking forward to helping developers create some fantastic Firefox OS apps.” and one of his big hobbies is playing the guitar. You can see what Jason had to say in his introduction interview on YouTube.

    Angelina Fabbro

    Angelina Fabbro Angelina Fabbro, based in Vancouver, Canada also got on board despite being pestered and climbed on by her cat during the video interview. You can contact Angelina on Twitter as @angelinamagnum. In her own words, she is “looking forward to making Firefox OS a solid product for the end user by encouraging best practices amongst developers. Pretty stoked to play with the newer APIs as I like trying new things.”. When asked for hobbies, she replied that she is taking singing lessons and plays “Magic: The Gathering”. Not at the same time though. You can see what Angelina had to say about herself here.

    Frédéric Harper

    Frédéric Harper Adding the final “je ne sais quoi” into the mix we have Frédéric Harper from Montréal (Québec, Canada). You can catch him on Twitter as @fharper in French or English. He is all about “Helping the Mozilla mission by promoting the openness of the Web, sharing my passion of Web standards, and helping people to be successful with Firefox OS.” and – in his own words – is a mad Geek t-shirt collector, likes gnomes and unicorns. You can see how he dealt with my questions here.

    Get prepared to hear a lot from these around here and on the interwebs from now on and join us in welcoming them to Mozilla and to the world of open web technology evangelism.

  7. May MDN sprint wrap-up

    Here are some of the high points from the MDN sprint that took place last weekend, May 31st and June 1st.

    New content

    Mixed security content blocking is now turned on by default in Firefox Aurora. David Bruant and Xavier Borderie improved the Mixed content page and David created How to fix a website with blocked mixed content.

    Jérémie Patonnier hosted the meet-up in the Paris office, and finished documenting the WebFM API. Jérémie has been documenting lots of the hardware device APIs. Check out this Device orientation example, if your browser and device support it.

    New contributor Scott Turner improved the Using IndexedDB article.


    A sprint meet-up in Mozilla’s Paris office meant that lots of French translation work got done, with lots of fixes to the corresponding English content along the way. Several people continued working after the end of the sprint, so by now:


    William Reynolds completed editorial reviews on a large number of articles, from Rhino Runtime to Object defineProperty.

    Editorial reviews (checking grammar, spelling, etc.) are a quick and easy way to contribute to MDN, even if you’re new to development. Lots of newcomers to MDN start out by doing editorial reviews — you can too! Just click Sign in on any MDN page, and create an account via Mozilla Persona.

  8. MDN sprint for better web tech resources — join in!

    MDN is one of our most important resources, and the core of knowledge and sharing for developers around the world. Additionally, it’s one of the vital cornerstones for all information we share at Mozilla Hacks, so in whatever way you can take part, it is highly appreciated. – Editor’s note

    Over on the Mozilla Developer Network site, this Friday and Saturday (May 31 and June 1), we’re having the latest in our series of “MDN sprints”. This is a chance for you to learn about a web development topic, and help improve the resources about it on MDN by sharing what you learn or what you already know. Please join us!

    About what?

    The major topical focus for this sprint is Web device APIs, which give JavaScript code access to device hardware. How about trying them out, and then writing some helpful code examples?

    Another timely topic is mixed content blocking, which just arrived in the Firefox Aurora channel. Help us explain to Web developers how to fix sites so users won’t be tripped up by mixed-security content.

    But those are just suggestions; any topic for Web developers or Mozilla developers is fair game. You can also find more info and ideas on the MDN sprint wiki page.


    You can join in from anywhere in the world. Of course you could just dive into MDN, but part of the point of a sprint is to do it with other people. Join the #devmo channel on to talk with other sprinters, about what you’re doing, they’re doing, or whatever. (Here’s info about IRC if you’re not familiar with it.) We might also do a Google Hangout, so ask about that when you drop in.

    If you happen to be in San Francisco or Paris, we’re holding in-person meetups for this sprint on June 1st, at the Mozilla spaces in those cities. Come on by and sprint in person!


    The sprint officially runs from 8:00 a.m. PDT on May 31st (Starting time in your timezone) to 5:00 p.m. PDT on June 1st (Ending time in your timezone). Of course, you can start earlier or continue later, and stay for as long or as short a time as fits your schedule.

    Sound interesting? Give it a try!

  9. Short sweet doc sprint for March

    This past weekend, a small band of hardy MDN contributors pitched in for the first of a monthly series of doc sprints. This sprint was organized on fairly short notice, yet a significant amount of work was accomplished.

    Web standards docs

    • Jérémie Patonnier created a bunch of API reference pages for MozMobileConnection, and SVG attributes dx and dy, and did a “crazy bunch of clean up” on the SVG documentation.
    • Michael Beckwith cleaned up writing on isNan and indexOf, and made minor touchups to :active.
    • Kevin Brosnan updated the compatibility info in Supported media formats.
    • fusionchess expanded the paragraph on passing data in Using web workers and added an example of a generic “asynchronous eval()”.

    Firefox OS and Apps

    • Gangadhar Nittala made his first contribution to MDN by changing the Apps manifest article to indicate that the .webapp extension for the file is mandatory, not just recommended.
    • Jonathan Watt added a section to Preparing for your first B2G build on how to update your B2G tree.
    • nullspace further clarified in Preparing for your first B2G build that there are gigabytes of Android libraries to download, which can take tens of hours (or days).

    Mozilla technology

    • Cory Gackenheimer updated Web Console for bug 623749.
    • Trevor Hobson updated Styling a tree to reflect changes in Gecko 22.
    • Florian Scholz worked on Firefox dev-doc-needed issues:
      • Documented that a Mac OS X backend for the DeviceLightEvent is now implemented.
      • Updated CanvasRenderingContext2D for the now-implemented isPointInStroke method.
      • Documented the rename of the allowfullscreen attribute of the HTML iframe element in Firefox 18 and WebKit Nightly (was prefixed).
      • Documented that DOMImplementation.hasFeature() and Node.isSupported() will always return true starting with Firefox 19.
      • Noted that createElement(null) works like createElement(“null”) starting with Firefox 19.
    • Tom Schuster worked on lots of little dev-doc-needed bugs.
    • donghao526 updated the simplified Chinese translation of The essentials of an extension.
    • darktrojan added a table about bootstrap data in Bootstrapped extensions.
    • Cykesiopka updated the join() example in Path manipulation so that the MDN and Gecko in-source documentation match.
    • the prisoner updated the French translations of Firefox 19 for developers and Firefox 20 for developers.
    • complynx fixed links to mutation observers in Mozilla event reference.
    • Ernest Chiang updated the traditional Chinese translation of Persona Quick Setup.
  10. Learn and share about new topics every month on MDN

    Did you have “expand my technical knowledge” as one of your New Year’s resolutions a few months ago? How’s that going?

    How about setting aside a day, or just a few hours, once a month, to teach yourself about a topic related to Web development, and share what you’ve learned with others? Wouldn’t it be fun to do that alongside a bunch other people, either virtually, or maybe in person?

    Monthly MDN sprints

    Based on discussions among the core MDN community, we’re upping the frequency of MDN doc sprints from “roughly once a quarter” to once per month. To keep them from getting too routine, we’re going to focus on a couple of different topics each month. One will be the topic of the following month’s DevDerby contest; the other will be something related to Firefox OS or open web apps. But since Firefox OS and open web apps are built with open Web technologies, that’s a pretty wide range to pick from. And of course, no one’s going to stop you from working on a different relevant topic of your choice.

    As background, a doc sprint is a short period when a group of people come together (virtually or actually, or some combination) to collaborate on writing documentation. If “writing documentation” sounds boring, think of it as a “learning and sharing” sprint. And if you’re not a “words” person, writing example code is a great way to contribute. You’ve probably experienced how much someone can learn from a good code example.

    We’ve set dates and some topics for the next three sprints (see below). The first one is just a week away, to squeeze it into March, before Easter weekend.

    • March 22-23: getUserMedia, offline storage
    • April 26-28: Web Workers, Web device APIs (specific ones TBD)
    • May 31-June 1: Topics TBD

    These dates are all in the MDN Community Calendar.

    How to join a sprint

    Sprints run for two or three days, but you can join for whatever part of that you are able to.

    1. Take a look at the wiki page for the sprint you’re joining, for specific details.
    2. During the sprint, hop into the #devmo channel on, and introduce yourself. There will be other sprinters in the channel, unless they’re all asleep.
    3. Login to MDN and get started.

    That’s it for participating virtually. In some cases, there will be in-person meet-ups. For example, for the April sprint, there will be a meet-up in the Mozilla Space in Vancouver, British Columbia. (Watch for further details!) Or you can organize a local sprint meet-up of your own, like Fred Bourgeon did in Montréal in February. This could be as simple as tweeting an invitation to meet up at a local coffee shop. Check out our (draft) Doc sprint planning guide if you’re interested.

    Meet-up or not, please join us for one or more of the upcoming sprints. It’s a great opportunity to give something back to the Web development community, while expanding your own understanding at the same time.