Mozilla

MDN Articles

Sort by:

View:

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

    Launch

    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.

    Outlook

    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.

  2. 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 (https://developer.mozilla.org/en-US/docs/Template:Promote-MDN?raw=1) 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.

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

    Highlights of the Persona zone include:

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

    Highlights of the Firefox zone include:

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

    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:

    image

    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!

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

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

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

    Translations

    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:

    Reviews

    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.

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

    Where?

    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 irc.mozilla.org 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!

    When?

    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!

  8. 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.
  9. 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 irc.mozilla.org, 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.

  10. How MDN and Web Platform Docs Align

    We have been asked a number of questions since the launch of Web Platforms Docs (WPD) about how it aligns with the Mozilla Developer Network (MDN). Questions such as how content will be shared between the two, how changes will be tracked, who will do the work to port content, and which site people should contribute to. To try and help answer some of these questions, we’ve put together this short FAQ.

    Before we dive into these, it’s worth underscoring that Mozilla sees MDN and WPD complementing each other. While WPD is just starting out on its journey to become an invaluable resource for developers, MDN is fully mature and will continue to serve needs that WPD doesn’t. We also want to take this opportunity to remind people that Mozilla is community driven, so any decisions to change what we’re doing will be based on community feedback.

    Here are the top questions we’re getting on the introduction of WPD. If you have additional questions, post a comment or email jswisher (at) mozilla (dot) com.

    MDN and WPD seem to have similar goals. How are they different?

    Mozilla supports WPD because it fits with Mozilla’s mission to promote openness and innovation on the Web. WPD has the benefit of financial support, content contributions, and perspectives from multiple browser vendors and Web-oriented companies. MDN has a long history of supporting developers of many stripes: Web developers, developers who use Mozilla code, and developers who work on Mozilla code. MDN promotes Mozilla’s mission by serving all these audiences.

    One difference is in the default licenses for reuse of the content from the two sites, although they are both Creative Commons licenses. MDN uses a CC-BY-SA license, which ensures that reused content will always be published in the context of an openly licensed work. WPD uses a CC-BY license, which enables the content to be reused as widely as possible, including potentially in the context of otherwise proprietary works.

    Why support two similar sites? Isn’t there a lot of topical overlap?

    WPD is in its infancy, and will take time to gather momentum, soothe teething problems, and foster a community, which Mozilla and other WPD stewards will help to do. Meanwhile MDN needs to support the hundreds of thousands of developers who visit it every week.

    As WPD matures, the MDN community will evaluate if and when it makes sense to defer to it on particular topics. In an ideal future, WPD would become the authoritative resource on Web standards, with a large volunteer community and community-based governance, while MDN could focus on Mozilla’s vision and its open source products that implement those standards. But it will take some time to get there.

    WPD launched its site as a “minimum viable product”, providing just enough features to get started. This is a prudent and reasonable strategy, so that feedback can help determine how the site is developed. However, it means that WPD is currently lacking desirable features that will be added later. Key among these missing features is support for translating articles into other languages, to help Web developers whose native language is not English.

    Meanwhile, due to its long head start as a Web resource, MDN offers translations in multiple languages, which are created by global communities of volunteer localizers, who prioritize translation of topics based on local needs and interests. As with English content, the localization communities will evaluate whether and when it makes sense to defer to content on WPD.

    Can MDN content be copied to WPD? Who is going to do the work of porting MDN content to WPD?

    Anyone working on articles on a given topic on WPD is more than welcome to incorporate content from MDN, as it makes sense to do so. Rather than exporting MDN content into WPD, wholesale, we hope that it will be curated by WPD authors into the appropriate context on the new site.

    Please be sure to following the licensing and attributing guidelines for MDN content on WebPlatform.org. This is needed because of the different licenses for the sites’ content; MDN content on WPD must be delineated and attributed, to ensure proper credit to MDN authors, and to convey the share-alike license requirement.

    Will duplicated content in both sites be automatically kept in sync?

    There’s no technical solution to do this at this time. We expect that each site’s content will evolve independently.

    Doesn’t that mean that there will be redundant work to keep both of them updated, especially as browsers and standards progress?

    Yes, unfortunately. There may eventually be areas where the sites can share information, such as browser compatibility data.[1] That has yet to be worked out.

    Are the stewards just turning WPD over to “the community” or are they devoting staff to it?

    Mozilla has paid staff participating in the WPD community in addition to working on MDN. Chris Mills of Opera is spending half of his time as a W3C Fellow, with a focus on WPD. Other stewards, as well as W3C, also have staff working on WPD; you’d have to ask them about their time allocation. However, contributions from Web developers, writers, educators, and others who are not paid staff of stewards are essential to the long-term success of WPD (as well as that of MDN). If only steward-paid staff contribute, it will not achieve its vision to be a truly open community resource.

    I want to contribute to Web standards documentation. Should I contribute to MDN or to WPD?

    Both sites could use your help, and Mozilla is contributing to both sites. MDN has an established community and lots of open documentation for the Web, which always needs improving, expanding, and translating. We will continue to build that community and give them a place to learn and share knowledge about the Web. WPD’s community is still forming, and could use your input into basic issues like information architecture and the translation scheme. WPD aims to bring together tutorials and materials from many different organizations, as well as contributions from Web developers, and we believe that will also support the open Web. Check them both out. Meet the communities. Join in where you feel comfortable.

    Here are some channels for getting involved:

      Mozilla Developer Network Web Platform Docs
    Introduction to contributing Getting started Getting Started Guide
    Mailing list dev-mdc@lists.mozilla.org public-webplatform@w3.org
    IRC channel

    #devmo on irc.mozilla.org #webplatform on irc.freenode.org

    [1] Specifically, MDN has lots of manually collected cross-browser compatibility data, which WPD can use now; WPD is looking at ways to automate collecting such data, which MDN could then also use.