Aug 222014
 

This week looks slower than usual when you look at this list, but the week involved a lot of research.

What I did this week

  • Reviewed and made (very) minor tweaks to Chris Mills’s doc plan for the Gaia web components and QA documentation.
  • Created an initial stub of a page for the canvas documentation plan.
  • Spent the weekend and a bit of Monday getting my broken server, including this blog, back up and running after a not-entirely-successful (at first) upgrade of the server from OS X 10.6.8 Server to 10.9.4. But most things are working now. I’ll get the rest fixed up over the next few days.
  • Pursued the MDN inbox project, trying to wrap it up.
    • Asked for feedback on the current state of things.
    • Added a subtle background color to the background of pages in the Inbox.
  • Started discussions on dev-mdc and staff mailing list about the documentation process; we’re going to get this thing straightened up and organized.
  • Filed bug 1056026 proposing that the Firefox_for_developers macro be updated to list both newer and older versions of Firefox.
  • Redirected some obsolete pages to their newer, replacement, content in the MDN meta-documentation.
  • Created a Hacker News account and upvoted a post about Hacks on canuckistani’s request.
  • Updated the MDN Administration Guide.
  • Installed various packages and add-ons on my Mac and server in preparation for testing WebRTC code.
  • Forked several WebRTC projects from GitHub to experiment with.
  • Found (after a surprisingly length search) a micro-USB cable so I could charge and update my Geeksphone Peak to Firefox OS 2.0′s latest nightly build.
  • Re-established contact with Piotr at CKSource about continuing work to get our editor updated and improved.
  • Removed a mess of junk from a page in pt-BR; looks like someone used an editor that added a bunch of extra <span>s.
  • Successfully tested a WebRTC connection between my Firefox OS phone and my iMac, using my Mac mini as server. Now I should be ready to start writing code of my own, now that I know it all works!
  • Filed bug 1057546: we should IMHO strip HTML tags that aren’t part of a string from within a macro call; this would prevent unfortunate errors.
  • Filed bug 1057547 proposing that the editor be updated to detect uses of the style attribute and of undefined classes, and present warnings to the user when they do so.
  • Fixed a page that was incorrectly translated in place, and emailed the contributor a reminder to be careful in the future.

Meetings attended this week

Monday

  • MDN dev team meeting on security and improved processes to prevent problems like the email address disclosure we just had happen.
  • MDN developer triage meeting.

Tuesday

  • Developer Engagement weekly meeting.
  • 1:1 with Jean-Yves Perrier.

Wednesday

  • 1:1 with Ali.

 Thursday

  • Writers’ staff meeting.

Friday

  • #mdndev weekly review meeting.
  • MDN bug swat meeting.
  • Web API documentation meeting.

So… it was a wildly varied day today. But I got a lot of interesting things done.

 Posted by at 6:16 PM
Aug 162014
 

I’m quite satisfied with how well the past week has gone. It’s been incredibly productive despite a few distractions and a great many meetings. Here’s my report on what I’ve been doing, and what I will be doing in the near future.

What I’m up to

I’ve been busy optimizing my own work processes, as well as setting up information so others know what needs to be done as well. I’ve also done a lot of copy-editing and organizational work in content, and have been touching up stuff ranging from the MDN inbox to the Learning Area to doc plans. It’s been a wonderfully productive week, and it feels good to be getting back into the swing of things.

What’s up next

Next week, I intend to dive into WebRTC, and to start putting together sample code so I can begin work on writing guides to working with WebRTC. It’s going to be really exciting!

As usual, of course, I have a number of other, smaller, tasks I want or need to accomplish, too.

What I did this week

  • Moved the main page on DocShell from the top level of MDN to its proper home, and filed a bug on getting it fully documented.
  • Dealt with infrastructure failures at my office: the air conditioning completely failed (working in a swelteringly hot office is not fun), and I discovered standing water in the restroom. The A/C is now fixed; the water problem has not been figured out yet, although the water has evaporated for now.
  • Helped test the new GitHub login support on the MDN staging server, and filed a few bugs regarding quirks I noticed.
  • Reviewed and had nothing but nice things to say about the new welcome email sent out by MDN to new members.
  • Got involved in the discussion about disabling styled pasting in the MDN editor. I’m opposed to this; I would much rather we solve the problem from the user’s end — contributors should learn to be sure they don’t include crufty styles when they paste into MDN. But ideally we can come up with a solution that doesn’t break existing workflows, punishing people who aren’t making this mistake.
  • Moved the page Write a new entry in the Glossary to the right place; it had accidentally been given an obsolete URL due to a couple of MDN bugs. Reviewed and copy-edited the content.
  • Filed a bug for a feature suggested by biraj: content from one page on MDN that’s presented inside another page should be reflected in the displayed contributor list. I don’t know how likely this is to be addressed (it certainly won’t happen soon). It’s a big project and there are many unanswered questions.
  • Copy-edited the new Glossary entry for the term “i18n“.
  • Added the word “Glossary” to the list of tags that MDN offers auto-completion for.
  • Followed-up on a bug asking me to write some copy for the Github login experience.
  • Did some tidying up of the MDN style guide, including moving Chris Mills’ excellent new section on our policies on gender-neutral terminology to be among the language and grammar topics rather than in the markup and wiki usage topics area.
  • Minor changes to the Learning Area page on CSS. This page needs a lot of work still but I saw low-hanging fruit.
  • Converted the Learning Area into a zone. Its landing page needs finishing, but this is a nice step.
  • Finished an extensive review and copy-edit of the Learning Area page Write an article to help learn about the web.
  • Removed a page that was actually just a set of Firefox problem reports, and emailed the author information about how to properly report issues.
  • Found an MDN “Linking Guide” lurking in a dead part of the site, and moved it into the MDN user guide, with major updates and copy-edits.
  • Updated the MDN user guide’s landing page to use the LandingPageListSubpages macro, so it looks a little better.
  • Adapted Luke’s screenshot/diagram about how to enable a page subscription on MDN into a new page in the MDN how-to guide.
  • Tweaks to the Inbox page in preparation for expanding its visibility.
  • Integrated the first round of feedback into the WebGL documentation plan.
  • Updated my Geeksphone Peak to Firefox OS 2.0 nightly for use in upcoming WebRTC sample code tests.
  • Filed a bug about iCloud.com saying “Android not supported” on Firefox OS 2.0′s browser.
  • Pinged developers about reviewing the WebGL documentation plan.
  • Created several new basic (that is, mostly empty) MDN development project plan pages:
  • Copy-edited the Learning Area’s How to contribute to the Learning Area article.
  • Filed a documentation request bug for documenting the NavigatorFeatures (hasFeature/getFeature) API. This API is low-priority privileged API, documentation-wise.
  • Added notes to a couple of pages in the MDN contributor guide about being careful when pasting, to avoid pasting unwanted styles and classes into MDN.
  • Created the DocPlanHelpUs macro, which inserts text inviting participation in a project and describing how to get started. Added it to the appropriate place in all extant doc plans.
  • Took some notes, sent some emails, and added links to the project planning page for the on-site messaging project.
  • Added a link to the MDN contributor guide to the footer of messages on the dev-mdc mailing list, and tweaked my email address on the moderator email list names.

Meetings attended this week

Monday

  • #mdndev bug triage
  • MDN development planning

Tuesday

  •  1:1 meeting with Jean-Yves

Wednesday

  • MDN Community meeting
  • 1:1 meeting with Ali

Friday

As you see, it was an intensely busy week! I’ve started moving into using OmniFocus to track what needs to be done and by when and I think it’s going to help, but we will see how it plays out over time. I have a history of not doing well at keeping up with my organizational systems, as you’ve possibly noted if you read my posts over history about my various attempts to get organized.

At any rate, it’s been a good week, and I can’t wait to get more done!

 

 Posted by at 12:07 AM
Aug 082014
 

It’s been another good week of Making Things Happen. I’m pleased with the productivity this week: not just mine, but the entire writing community’s.

What I’m up to

As usual, what I did this week doesn’t entirely line up with what I’d expected, but it was still productive, which is the important thing, right?

Work continued on finishing up the doc project planning page migration work, and better integration with other pages on MDN and elsewhere. I also put together the first draft of the WebGL doc plan.

I’m working on trying to reshuffle my many personal appointments that happen regularly to less often interfere with meetings, but unfortunately there’s only so much I can do.

What I did this week

  • Replaced the main documentation plan page on wikimo with a link to the new page on MDN, with an explanation of why it moved.
  • Finished work on moving the Learning area doc project plan to MDN.
  • Migrated the “Writing chrome code” doc plan to MDN, then emailed Will Bamberg to let him know his planning docs had moved.
  • Wrote first draft of the WebGL doc plan and emailed dev team to request feedback.
    • Got quick feedback with WebGL 2.0 ship date and added that information to the doc plan.
  • Added the dev-doc-needed keyword to man WebGL 2.0 related bugs.
  • Filed a bug about a problem with the link editor not suggesting zone pages that have moved out of the /docs/ hierarchy.
  • Added a link to the WebRTC doc project plan to the WebRTC documentation status page.
  • Posted to the dev-media list asking for suggestions on topics to cover in the WebRTC docs.
  • Updated the MDN page about KumaScript macros to link to the new article on troubleshooting them that Stephanie Hobson wrote.
  • Did a quick copy-edit pass on the troubleshooting article, and added some information about how to use search keywords to get to macro pages quickly (to read the built-in documentation most have).
  • Emailed out various meeting reminders.
  • Updated the team priority list spreadsheet with updated URLs and new information.
  • Wrote agenda for writers’ staff meeting and Web API docs meeting.
  • Wrote a nifty new MDN macro, ContentFromWikimo, which imports the content of a specified block (by ID) from a page on wikimo and inserts it into the MDN page.
  • Used the ContentFromWikimo macro to embed module owner information about WebRTC, WebGL, Web Workers, and XPCOM to their doc plans.
  • Filed a number of meta/tracking bugs for the various doc plans.
  • Created meta/tracking bugs for all current documentation plans. See my standup for today for links; I’m not going to copy and paste them all here. :)

Meetings attended this week

Monday

  • #mdndev bug/triage/planning meetings.

Tuesday

  • Messaging discussion for MDN feature planning.

Wednesday

  • 1:1 meeting with Ali.

Thursday

  • MDN writers’ staff meeting.

Friday

  • MDN development bug swat meeting.
  • Web APIs documentation meeting.

So, whew! Lots done! I’m particularly proud of the ContentFromWikimo macro work. It was also a lot of fun to do. I think it’ll be useful, too, at least sometimes.

I have a good feeling about next week. I think it’ll be even more productive!

 Posted by at 1:47 PM
Aug 012014
 

It’s been a while since my last Sheppy Report; there several good(ish) reasons for that. I won’t rehash all that today, though.

My intent is to resume these weekly reports; they were well-received back then, and I hope they’ll help improve my ability to keep people apprised of what I’m doing and about what’s new on MDN.

What I’m up to

My primary mission this week was to work on the MDN documentation project plans, getting them prepared for use by moving them to MDN, building any necessary content and macros  to support their presence, and so forth. This has gone pretty well, although it’s not quite finished yet. I plan to work on Saturday to complete this project.

Next week, I intend to tackle integration of the project plans with doc status pages and to write the WebGL documentation project plan. This will let us get started with the job of finding someone to write that important content.

There’s plenty more on my to-do list, and it’s possible priorities could shift, but finishing the current work is pretty much my Most Important Thing right now.

What I did this week

  • Created the landing page for the new home of MDN documentation project plans.
    • We decided to move these planning documents to MDN (even though planning docs don’t traditionally belong on MDN) in order to integrate them with our processes better. Having them on MDN means we can use KumaScript to automatically populate tables from bug lists, other areas of MDN, and so forth.
    • This will also let us integrate them with our existing doc status page system, which has been a great tool. I look forward to this augmentation work.
    • This page automatically rebuilds every four hours so its macro-generated list of subpages can be kept up to date.
  • Archived our old “Team Status Board” page. This was an experiment in tracking what individual MDN contributors were working on that didn’t work out.
  • Updated the non-standardGeneric macro
    • Corrected a typo that broke the macro, causing a KumaScript error on all pages using this macro or one that calls it.
    • Improved performance slightly by adding code to bounce out of loops when an end condition is detected early.
  • Migrated the developer phone documentation project plan to MDN, reformatting it to follow the new organizational structure for these plans.
  • Copy-edited the string.repeat() documentation.
  • Rewrote parts of the MakeColumnsForDL macro on MDN; this macro, which breaks up a <dl> into two columns for our landing pages, was in some cases splitting the list in the midst of a <dt> tag.
  • Migrated the Game Developer Zone documentation project plan to MDN.
  • Created a framework doc plan page for the RecRoom project.
  • Created a framework doc plan page for the WebGL docs project.
  • These framework doc plans will require filling -out, of course.
  • Corrected an accidental “translation-in-place” incident that replaced the English Apps zone landing page with Italian.
  • Created the <picture> element doc plan page on MDN.

There’s lots not covered here, such as email catch-up from my vacation a week or two ago, and all sorts of non-meeting discussions about MDN features, ideas for improving articles, etc. But you’re likely not interested. In fact, I bet you didn’t actually read this far anyway. :)

Meetings attended this week

Monday

  • #mdndev planning meeting
  • #mdndev pull request triage
  • MDN bug triage
  • Mozilla staff meeting

Tuesday

  • Developer Relations town hall meeting

Wednesday

Thursday

  • One-on-one meeting with Jean-Yves
  • Employee training meeting

Friday

  • One-on-one meeting with Ali

Unfortunately, a personal meeting ran very long on Friday, causing me to miss several scheduled meetings. Repeat apologies to everyone affected.

In general, a pretty productive week. A lot got done, and I’m making definite progress.

 Posted by at 6:12 PM
Jun 142014
 

I’m happy with how my talk at the Open Help conference went this morning. I gave a talk about how Mozilla builds, fosters, and provides useful information to our documentation community. I enjoyed giving it, and the questions were good ones.

I saw a lot of note-taking and nodding heads, and the discussions over the rest of the day definitely gave me the sense that people appreciated my thoughts on documentation community-building and processes. I hope there will be video available at some point; certainly it was recorded.

Our documentation status pages and other ways we present data about tasks that need to be performed really got a lot of attention, and Florian’s graph of our contributor growth really opened some eyes — especially when I pointed to the sharp uptick since we deployed our in-house grown, open source, Kuma documentation platform.

Also, I think our development team will be pleased that I heard a lot of “I wish we were using Kuma for our docs” today, and at least one person saying they’re going to look at setting up to try building it themselves.

Three or four people said that if it were separated from the Mozilla-specific bits, they’d be pushing to switch to Kuma. That made me smile; hopefully they will still feel that way if/when we manage to ever make the platform separate from the MDN-specific parts.

I’m with my people here; it’s really wonderful to just talk about documentation tactics without all the other stuff. It’s a great feeling, especially when it seems you’re able to give your peers ideas to take home and try for themselves.

My slides

View my slides below, or download them as a PDF.

 Posted by at 10:10 PM
Jun 112014
 

I’ll be attending the Open Help Conference & Sprints event this weekend, arriving in Cincinnati on Friday afternoon and returning home on Tuesday morning after the first day of documentation sprinting. Mozilla is a proud sponsor of this event, which features a number of key influencers in the open source documentation arena. The mission: to exchange notes and ideas about how to improve the quality and quantity of good open source documentation, and to hold documentation sprints to get some writing projects done.

I’ll be giving a talk on Saturday morning (at 10 AM—the first presentation of the event) entitled “Help people so they can help you.” I’ll be covering the things the MDN team does to build, foster, and support its growing community of contributors. I’m looking forward to this, even though I’m nowhere near prepared yet. I enjoy sharing ideas about how to create and maintain excellent documentation. It’s my career’s mission, and as a Mozillian, I’m pleased to be able to share. Hopefully, too, I’ll get new ideas this weekend as well!

As an aside, if you have any thoughts on things I should be sure to mention, don’t hesitate to leave a comment or drop me an email!

If you’re going to be at Open Help, or are simply in the Cincinnati area, I hope to run into you!

 Posted by at 9:51 AM
Mar 142014
 

Last weekend, we had an MDN work weekend at Mozilla’s Paris space. Over the course of the three days—Friday, Saturday, and Sunday—we built code, wrote and updated documentation, and brainstormed on new and better ways to present documentation on MDN. A grand total of 34 participants (wow!) including 16 volunteers and 18 paid Mozilla staff sat down together in a big room and hacked. 11 countries were represented: France, the United States, Canada, the United Kingdom, Sweden, Italy, Spain, Poland, Germany, India, Bangladesh, and Brazil. We completed 23 projects and touched (either adding, updating, or closing) over 400 bugs.

The most important thing, to me, was the reminder that our community is a real, tangible presence in the world, rather than an ephemera that flits about touching documentation from time to time. These people have real jobs, having real and important impacts on their local communities. Coming together is a chance to enhance our bond as Mozillians. That’s a great thing.

What’s also great, though, is the amazing amount of output we produced. Let’s look over some of the stuff that went on (if I leave out something you did, I apologize!).

Documentation work

  • Prototyped new UX for the MDN App Center.
  • All KumaScript errors on every page in the English, German, and French locales were resolved! This is a huge deal and I’m grateful to Jean-Yves, Florian, and Sphinx for this work.
  • Lots of work was done to sketch out and plan an improved onboarding experience for new contributors.
  • Lots of new Web documentation was added for various CSS properties, as well as for the HTML <template> element used by Web Components.
  • Over 100 pages of beginner content were properly tagged to be easier to find using MDN’s search filters.
  • Planning work for the new MDN “Learning” area was done; this area will provide content for new Web and Web app developers.
  • Work to plan out requirements for future MDN events was done.
  • Planning for the next steps of the compatibility data project was done; I missed this meeting although I meant to be there. We will be building a system for maintaining a database, in essence, of compatibility for all the things that make up the Web, then updating our compatibility tables to be constructed from that database. This database will also be queryable.
  • Progress was made on documenting the Web Audio API. Thanks to Scott Michaud for his work on this.
  • Chris Heilmann worked on adding live samples to pages; his work included some experiments in ways to make them more interactive, and he talked with our dev team about an improved user interface for implementing live samples.

Kuma platform work

Seven new people had the Kuma build system set up on their computers, with a virtual machine running a Kuma server up and running. Those seven people included me. In fact, I devised and submitted three patches to the Kuma platform over the weekend! They’re nothing particularly big, but it did allow closing three longstanding minor bugs. Not a big deal, but I’m proud of that anyway.

And I’m not the only one: a ton of amazing enhancements to the Kuma platform were developed over the weekend. Some are already deployed; others will not be for a while, since there are quirks to iron out.

  • Live samples are now better delineated by having a border drawn around them (this one is mine, and already deployed).
  • A new JavaScript snippet has been developed that can be embedded into any Web site to automatically link common terms to the appropriate pages on MDN. This is almost but not quite ready to deploy as I write this.
  • A bunch of old code we inherited from the Kitsune project has been removed (Ricky did this).
  • The email sent to admins after a page move operation is completed has been enhanced to include a link to the new location and to have the subject be more specific as to which move finished (another of mine; not yet deployed but probably will go out in the next push).
  • The “revert this page” confirmation prompt has some wording corrections (mine, and pushed to production).
  • A new “top contributors” widget has been developed; this will show the top three contributors to a page, with their avatar image, at the top of the page somewhere. This isn’t finished but the prototype is promising. This work was done primarily by Luke Crouch, I believe.
  • UX design work was done for future enhancements to how we display search results.
  • UX design work was done for how we display the language list, to improve discoverability both of the fact that there are multiple languages, but also that pages can be localized by contributors.
  • The revision diff page you get when comparing two pages in an article’s history now includes a “Revert to this revision” button. Also mine; I don’t know if it’s on production yet but I think so.
  • Lots of design and planning work for improved search UX, filtering, and more. This stuff will amaze you when it lands!

I won’t become a huge contributor to Kuma, probably. I don’t have time. I’m too busy writing and (more often, really) organizing other writers. That’s okay, of course. I’m having my own impact on our worldwide community of Mozillians and users and developers on the World Wide Web.

 Posted by at 6:47 PM
Feb 212014
 

The most important rule of contributing to the developer documentation on MDN is this:

Don’t be afraid to contribute, even if you can’t write well and can’t make it beautiful. It’s easier for the writing team to clean up information written by true experts than it is to become experts ourselves.

Seriously. There aren’t that many of us on the writing team, even including our awesome non-staff contributors. We sadly don’t have enough time to become experts at all the things that need to be documented on MDN.

Even if all you do is copy your notes onto a page on MDN and click “Save,” that’s a huge help for us. Even pasting raw text into the wiki is better than not helping at all. Honest!

We’ll review your contribution and fix everything, including:

  • Grammar; you don’t have to have perfect (or even good) writing skills—that’s what the writing team is here for!
  • Style; we’ll make sure the content matches the MDN style guide.
  • Organization; we’ll move your content, if appropriate, so that it’s in the right place on the site.
  • Cross-linking; we’ll add links to other related content.
  • Structure and frills; we’ll ensure that the layout and structure of your article is consistent, and that it uses any advanced wiki features that can help get the point across (such as live samples and macros).

It’s not your job to make awesome documentation. That’s our job. So don’t let fear of prevent you from sharing what you know.

 Posted by at 10:15 AM
Feb 202014
 

Among the first steps we need to take for our “Year of Content” this year is to review our existing documentation to find where improvements need to be made. This involves going through articles on MDN and determining how “healthy” they are. If a doc is reasonably healthy, we can leave it alone. If it’s unhealthy, we need to give it some loving care to fix it up.

Today, I’d like to share with you what constitutes a healthy document. Only once we know that can we dive into more depth as to how to fix those articles that need help.

Check the content’s age

Look to see how recently the content was updated. If it’s been a long time, odds are good that it’s out of date. The degree to which it’s out of date depends, of course, on what the topic is and whether or not there’s been development work in that area recently. Content about CSS is a lot more likely to go quickly stale than material about XPCOM, for example.

Review articles in areas of the site, looking to see how long it’s been since it was last changed, and use your judgement as to whether it’s been too long.

Do the pages have quicklinks?

Quicklinks appear in the left sidebar on MDN pages to offer links to related content. We are in the process of phasing out the old “See also” block at the end of articles in favor of quicklinks. If you see pages that have a section entitled “See also”, they need to be updated. Similarly, many areas of the site have standard quicklink macros that should be used, such as HTMLRef or CSSRef. These automatically construct advanced sidebars which link to related material as well as all other HTML elements or CSS properties.

Pages with no “See also” section or quicklinks may need some added; it’s often useful to provide additional links like these. However, they’re not mandatory.

Are there any KumaScript errors?

This is a big one. Any page that presents a big red KumaScript error box at the top of the page is an immediate “drop everything and fix this” alert. If you don’t know how to fix these (or aren’t able to), visit #mdn on IRC or drop me an email.

Are there appropriate examples and images?

Developers learn best and fastest by example. Any page about a developer technology that doesn’t have good code samples—with explanations of how they work—is probably flawed. Take note of pages that are missing examples, or have overly simplistic (or excessively complicated) examples. Also, most examples should be presented using our live sample system, which allows us to demonstrate inline the results of executing a piece of code.

Similarly, if an article would benefit from screenshots or other images (or videos) to help explain a topic, and doesn’t have any, that’s a detriment to its health, too.

Are there compatibility tables?

Every page about an API or technology should have a compatibility table that indicates what browsers and platforms support it. This includes both tutorials and reference pages. If these are missing, users will have a hard time evaluating whether or not a technology is ready for prime time.

On a related note, pages that are written from the perspective of using them from a particular browser are also flawed. Much of our content is still very Firefox-specific, which isn’t appropriate. MDN’s content should be browser-agnostic, supporting our developers regardless of what platforms and browsers their users are on. We need to find and get rid of boxes and banners that say a technology was added in Firefox version X and move that information into proper compatibility tables.

Do reference pages link to specifications?

Every reference page should include a link to the specification or specifications in which that API was defined. We have a standard table format for presenting this information, as well as a set of macros that help construct them.

Are pages formatted properly?

All pages on MDN should follow our style guide. Admittedly, our style guide is a bit in flux at the moment, and not all of it is written down yet. However, that will change soon (certainly by the time we dive in deeply into this work), so it deserves mentioning here. Content that deviates from the style guide needs updating.

Important: Many older parts of MDN use custom styles, or embed CSS examples within the body of articles. This is no longer allowed, and in fact the ability to edit content like this will eventually go away, so it’s important that these pages be updated to use only our standard styles, and to move all examples into live samples.

Are pages tagged correctly?

Increasingly, we’re using macros for everything from generating landing pages and menus to search filtering to building to-do lists. This depends heavily on pages being tagged correctly. Articles that don’t follow our tagging standards need to be updated so that all of these features of the MDN Web site work correctly.

Do pages need review?

Healthy articles have been fully reviewed; they have no review requests flagged for them. New articles are automatically flagged for both editorial and technical review, and these reviews may be requested at any time after the article has been created, as well. These reviews help to ensure the documentation’s quality and clarity.

Make sure there aren’t any dead ends

Every article should have links to other pages. Articles that don’t cross-link properly to other content become dead ends in which users get lost. Be sure that terms are properly linked to relevant content elsewhere on MDN; if there aren’t appropriate links to other pages, the articles aren’t healthy.

Do pages use macros properly?

We use macros on MDN for a lot of things. It’s important that they’re used consistently and correctly. By using macros to generate content, we can create more and more consistent content more quickly. For example, when linking to API interface objects, use the DOMXRef macro instead of directly linking to the object’s documentation. This macro can adapt quickly to site changes and design changes. In addition, it automatically creates appropriate tooltips and automatically handles other tasks to improve the site’s usability.

 Posted by at 12:05 PM
Feb 182014
 

A key aspect to the documentation process is communication. Not only is the completed documentation itself a form of communication, but thoughtful, helpful communication is critical to the production of documentation. For the MDN documentation team to create content, we need to be able to interact directly with the developers behind the technologies we write about.

Today I’d like to share with you how that communication works, and how you can help make documentation better through communication. Not only do we need your help to know what to document, but we need information about how your technology, API, or the like works. The less time and effort we have to put into digging up information, the sooner we can have documentation for your project, and the better the coverage will be.

Pro tip: Assume we know nothing about your project. We don’t know who you are, what your technology is or does, or even that it exists. If you start with that assumption, and provide all the information you have, everyone probably wins.

Share details

There is basic information we will almost always need when working on documentation for an API or technology. If you’re proactive about providing this information, it will save everyone time and energy. I mentioned this previously in my post about writing good documentation requests, but it bears repeating:

  • Who are the responsible developers? We will almost certainly have questions, and nothing slows down a writing project like spending two weeks trying to figure out who can answer simple questions.
  • Make sure we have links to the specifications and any design or implementation notes available for the project. We probably will find the specification on our own, but anything beyond that is likely to be missed. And if you send us the spec link (which you probably have memorized by now anyway), you’ll earn our appreciation, which can’t hurt, right?
  • Where’s the code for your implementation? Providing a link (or links) to the code tree(s) on mozilla-central and/or Github can save us tons of time, since we will refer to the code often while writing.
  • When the specification and/or design is finalized, let us know! We usually won’t start writing until the design has settled down into a reasonably stable state, and if we don’t know it’s stabilized, we might never get started. Similarly, if there’s an unexpected change after the specification was supposedly finished up, be sure to ping us then, too!
  • Do you have code samples or snippets? Sharing links to those, or to any tests you’ve written, can help us understand how your API or technology works—and it gives us a head start on writing example code for the documentation.
  • Do you have a schedule? Let us know when you expect to hit your milestones and when you expect to reach each branch.

Looping us in

The more your team is able to integrate the documentation team into your docs process (and vice-versa), the better. It’s actually pretty easy to make us feel at home with your team. The most important thing, of course, is to introduce your project to the writer(s) that will be working on documenting it.

To find out who will most likely be writing about your project or API, take a look at our topic drivers list on MDN. If you’re unable to figure it out from there, or don’t get a reply when you ping the person listed there, please feel free to ask me!

  • Invite us to attend any planning or status meetings for your project. Don’t assume we know about them (we probably don’t, unfortunately). Being able to listen in on your meetings (and occasionally even offer suggestions) is incredibly helpful for us. We see a lot of APIs, and you never know, we might have ideas you can run with.
  • Be sure we know what mailing list or mailing lists your team has discussions on. We will probably either want to become regular readers or at least be able to quickly pull up archives while doing research.
  • Let us know what IRC channels we should hang out in to participate in discussions about your project or the technology you’re working on.
  • Do you have work weeks? Invite us to join you! Having a writer attend your work week is a great opportunity to interact and get some face-to-face discussion in about the documentation, what you need, and what you’d like to see happen.
  • Whenever someone blogs about the project, technology, or API, let us know. Don’t assume we’ll see it go by on Planet, because odds are very good that we won’t. Ideally, you should add a link to it to your documentation request bug, but at least email us the link!

Join the conversation

We will almost certainly be having discussions about the documentation work you need from us! It’s often helpful for you to be proactive about being engaged in those discussions. It’s always best to get your input, requests, and suggestions sooner rather than later.

  • If your project is large enough, we might start having meetings specifically to discuss its documentation work. This type of meeting is typically short (our Web APIs documentation meeting has never run longer than 20 minutes, for example). We will invite you to attend these, and we’d love to have you, because it’s a great way for you to comment on documentation quality, priorities, and the like.
  • You’re welcome to join us in #mdn, the IRC channel in which we discuss documentation work, if you want to chat with us about specific documentation concerns or questions, or if you want to make a fix or addition yourself but need some advice.

Useful resources

There are a few additional useful resources on MDN that can help to improve the interaction between the writers and the developers for a project:

 Posted by at 12:44 PM