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!
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.
Why, hello there! It’s been several weeks since our last push of new code to MDN’s Kuma platform, so the list of changes in our new update is quite long. Let’s dive in and have a look!
Revision dashboard
Wiki improvements
Other improvements and fixes
So this is a huge update, and it’s got some really nice stuff in it. Stay tuned! There’s more to come!
Today, I missed that a meeting that I run was about to start, because while all the other attendees knew about it, it wasn’t on my calendar for this week. It’s a biweekly meeting, and my calendars show it as happening next week.
This is not a new problem. It’s not even a rare one. Calendar sync is a problem that has continued to almost uniformly suck beyond words since people first started carrying gadgets around. Interestingly, it seems to have gotten worse, rather than better. Problems with my calendar being out of sync were rare back in the days I was carrying a PalmPilot around, syncing it using the good-old-trusty HotSync® protocol and a cradle. Nowadays, though, it seems to be the norm for my calendars to be entirely out of whack.
This is, of course, probably because I expect my calendars to be accurate in more places. Web apps, my iPhone, my iPad, two desktop computers, and a laptop. I use them all to update calendar information. Perhaps I need to give up on this expectation and hope, and just use one gadget for all my calendar information from now on.
I shouldn’t have to do that, though. This shouldn’t be an impossible problem to solve, especially since the information is being maintained on a server.
I’m tired of not being able to trust my calendar to be correct. Why hasn’t this been solved yet? I’ve been using electronically synchronized devices to keep track of my schedule for almost 20 years now (I started with a Newton MessagePad 110 in 1994). There’s no reason why this should continue to be so frustrating after all this time.
I’d appreciate tips on what you do to reduce these problems!
Given our ongoing documentation-needed overload, we’ve decided to look into contracting out some writing work to help catch up our Firefox developer documentation. Basically, we’ve not been able to keep up with our Firefox X for developers documentation (see Firefox 17 for developers, for instance). While stuff gets listed, the list is often not complete, and even where items are put on the list, they’re usually not actually documented.
This is, frankly, embarrassing.
However, the staff writers, and even most of our community of writers, have been very busy with Firefox OS and other documentation, leaving Firefox itself rather strapped for attention. That’s got to change.
So the other day, I talked to Ali (my boss) and we agreed that we should see about contracting someone to go through all of these documents, from Firefox 13 onward, and get them fully up to date, and try to document the technologies and changes as needed.
There are some skills required:
You won’t be in this alone, of course. Our existing community of writers hangs out in #devmo on irc.mozilla.org and we’ll be there to offer encouragement, advice, and some help.
If you’re interested, let me know. We haven’t opened up this contract yet, but I’d like to start getting a handle on who might be interested, so I can have a list of possible candidates ready to go once that happens.
This is important work that’s sadly fallen by the wayside due to limited resources and conflicting priorities. Help us make the Firefox developer documentation excellent again!