We’ve just pushed a Kuma platform update to MDN. The key change that I feel is worth sharing is that we’ve added support for the Malay locale.
To our Malay users and community members: we look forward to your contributions! Welcome aboard!
As part of our effort to improve our documentation process, we now have a Bugzilla form that makes it easy to provide the proper information we need in order to handle a request for documentation. In addition to offering guidance as to how to fill out the form, fields that we don’t need (or need to have specific values) aren’t presented, and are handled automatically on your behalf.
If you find yourself often requesting the addition of (or changes to) documentation on MDN, you should seriously bookmark the new form:
https://bugzilla.mozilla.org/form.doc
The new form looks like this:
The Request Type indicates whether you’re asking for new documentation or a correction to existing materials. The Topic drop-down menu offers a list of topic areas (DOM, HTML, JavaScript, etc.) to help categorize your request. It’s helpful to specify a technical contact; this is the email address of someone that knows about the topic so that the writers can find someone quickly to help answer questions. This field supports lookups from Bugzilla’s user database, to help you get it right the first time.
The Development Bug field lets you enter the bug number of a bug that should be blocked by this documentation request. That lets us monitor the development process as well as to locate people that may know more about the topic to be documented.
The Urgency field lets you indicate how quickly the documentation request would preferably be handled. The default is “No Rush,” but there are options to indicate that the docs are tied to a given stage on the release train, as well as an “Immediately” option for emergency documentation updates.
It’s important to note that we make no guarantees as to how quickly documentation will be written. There’s a lot to write, and there aren’t that many people to do the writing, so sometimes even important things will sit around and wait for a while.
If you’re a member of any of our illustrious localization and translation teams for MDN, you’ve likely noticed that for a while now, trying to save changes to pages that have been moved has been failing with a strange error about not being allowed to change the page slug.
This bug has just now been fixed, and you should be able to edit these pages again without any problems. Let us know if you’re still having problems!
Thought provoking bad temporal sci-fi.
This post is not just a note about the changes in yesterday’s Kuma push to the MDN web site, but also serves to explain a change to our deployment process. The MDN development team is switching to a “continuous deployment” model, where new changes will be pushed to production as soon as they’re ready, instead of batching them.
Because of that, I won’t be blogging every single push anymore. Instead, I’ll mention specific new features as they’re ready for you to use, if they’re of major interest, or I’ll batch pushes together and mention the little but still interesting things all at once.
However, we do have a few interesting things in this new push, so I’ll mention those today:
A few nice improvements, and the new deployment plan is an interesting development!
We have a new Kuma platform update tonight! The new version features the following improvements:
Nothing major, but a few nice quality of life improvements.
The core MDN team has been meeting in Austin, Texas this week to plan development work for the next year. I’ll be blogging more about what we’ve come up with next week. We have Plans! Big Plans!
That’s right! Even though just earlier today I blogged about last night’s Kuma software update on the MDN web site, we have another one. I adore our development team. I could squee all day about this stuff, but instead, let’s have a look at what’s changed:
Not a lot of changes, but several that will be a real boon to select people. In particular, I’m personally thrilled by the improvement to the page move tool, since I’ve been doing a lot of organizational clean-up work lately, and this will streamline that work noticeably. I’m also happy about the update to the Style menu, since these styles are getting used more and more — and being able to avoid dropping into the source editor to apply them is a huge help!
The staff MDN writers and the MDN development team are meeting next week in Austin, Texas to talk about development plans for the next six months or so. I’m looking forward to seeing them all. These are excellent people, and it’s a privilege to work with them all.
We pushed an update to MDN’s Kuma platform last night. One nice, currently-useful change, one change that has more work left to be done before it’s ready to use, and a few behind-the-scenes tweaks you won’t notice yet.
There are some technical issues involved in getting these lists reported as actual arrays, but that’s something we do hope to do soon.
Other than the bug fix and the revision dashboard change, most of these changes are behind-the-scenes for now (the VM changes and the save logic changes).
In addition, you can’t yet see that tag information for other pages (it’s only available via the current page’s environment variables list). I’m filing a bug for that right now; I didn’t clearly communicate the use cases for this to the development team. Oops.
We pushed a very small update to MDN’s Kuma software today. There’s only one change: if the text “bug X”, where “X” is a number, appears in an article revision comment, it’s turned into a Bugzilla link to bugzilla.mozilla.org, so you can quickly hop over to that bug for reference.
That’ll be a handy feature! I’ve been looking forward to it for a while now. Enjoy!
As a leader of a community-driven documentation project such as that which we have on the Mozilla Developer Network (MDN) wiki, part of my job is to help build that sense of community while at the same time trying to make sure that things get done. This can be a tricky balancing act, especially since I go into things with my own ideas of how I think things should be done, and I’m certainly not always right.
For that reason, it’s sometimes a useful exercise to not get involved in debates and discussions about ideas. At times, I try to simply observe and see where the conversation goes. I let the conversation run its course, then jump in until the discussion reaches one of its typical end points:
It can be incredibly educational to simply follow along while your community thinks out loud. By keeping your biases out of the way, a lot of great things can happen; often ideas come up that you would never have thought of. In addition, it lets your community members exchange ideas more freely, and can help build their sense of belonging. Certainly it helps them feel more confident that you’re not dictating how things should be done!
Silence isn’t always the best policy, but sometimes it’s a useful tool. Used properly, it can help your community become stronger.