After spending some time reading through Pro Git on the Safari bookstore, as well as surfing the web, I figured out how to do it and got it all set up and working. I figured that, having done so, I should share what I did. So here we go!

Creating the server

1. Start up Workgroup Manager and create a new “git” user. Set the startup shell for this user to a custom shell and enter “/usr/bin/git-shell”. This will prevent the “git” user from logging into a bash shell.
2. In the Server Admin utility, add the “git” user to the list of users that have SSH access to the server; this is done in the “Access” panel.
3. Open a terminal on the server (or ssh to it) and su git to work as the “git” user.
4. Create your repository or repositories (see “Adding repositories” below).
5. Add files to the repository; see “Adding files” below.

Giving access to users

In order to let contributors access the server, we’ll use SSH keys. Gather SSH public keys from everyone that will be contributing to the project. Then follow these steps:

1. su git
2. cd
3. mkdir .ssh
4. Append all of the public keys for your users to the file “.ssh/authorized_keys”, one per line.

Adding repositories

Follow these steps for each repository you want to create on the server.

1. mkdir projectname.git
2. cd projectname.git
3. git init –bare

Adding files

For each repository, add files to the repository by following these steps from the machine on which your files are currently located:

1. cd projectname
2. git init
3. git add *
4. git commit -m “Some initial commit text.“
5. git remote add origin git@myserver.com:projectname.git
6. git push -u origin master

At this point, any of your users whose keys you’ve authorized can access your git server and can both push and fetch files from it.

Wrapping up

I wrote this little guide up from jotted-down notes and memory, so if I’ve made any mistakes, be sure to let me know so I can fix it. I fully expect I will refer back to this in the future (which is part of why I wrote it all down here)! I hope this helps you out too.

More precisely, IT has shut down one of our three MDN hosts and created a VM based on it down at the new data center; MDN will be hosted entirely off that one VM until the physical hardware is in place, at which point we’ll switch back over to the three physical servers we usually run on. Because the VM will be using our real database server the whole time, we don’t even have to lock down to prevent editing! This is an unexpected but highly welcome development that deserves a huge round of applause for our IT department, because every time we’ve tried this in the past, some dark MindTouch secret has prevented it from working.

All that said, because MDN will be operating on a single VM instead of three physical servers, I expect performance will be significantly lower than usual. So be ready for that.

For the duration of that move, I expect visitors to MDN will be directed to visit dochub.io or other sites temporarily for their basic documentation needs.

It will be interesting how many panicky emails, bug reports, and angry tweets we get over this planned downtime.

In some cases, it’s a matter of the uncanny valley effect. A long time ago, Firefox felt like a Windows application on the Mac. The UI was distinctly different from every other Mac application, and it stood out like a sore thumb. But you knew what you were getting into. You started it up, and because it looked nothing like a Mac app, it was okay that it didn’t really act like one. You didn’t expect it to.

But then we put a fair amount of work into making it look a lot more like a Mac application. As a result, we now have a Firefox that looks much more like a Mac app… but doesn’t quite act like one. There are little, subtle things that just feel wrong. This gives you this uneasy feeling, very much like the uncanny valley effect, and it’s unsettling. This really needs to be addressed, because it’s a big turnoff to a lot of people (myself included).

There are big things, too, of course.

A few things, right off the top of my head, that bug me:

• Pop-up menus don’t behave like real Mac pop-up menus. This is one of those uncanny valley problems; they used to act totally different, then we made them much closer, but there are still differences, and they’re annoying.
• Our pop-up panels (like the one that appears when you go to edit a bookmark) look very out-of-place, and many of them are not resizeable even though they would be much more useful if they could be resized.
• Text selection behavior is subtly different in ways I can’t put my finger on, but I know the issue is there.
• Drop-down sheets — particularly the one for configuring the toolbar — are just not right.
• If Firefox isn’t running, and you click a link in another app that causes Firefox to open to open that app, and Firefox has an update pending, the update installs, Firefox restarts, and you don’t get your link opened. This was fixed at one point, then rebroke (possibly around the time we switched from Carbon to Cocoa). This drives me nuts, especially since I run on Aurora and/or Nightly, so it happens to me all the time.
• We could use more and better gesture support. At one point, we had swipe to top and bottom support, but that vanished at some point. With Lion making it clear that gestures are the wave of the future on Mac, we need to get on board.
• With Mountain Lion on the way, we need to look at integrating with the new Notification Center as well as the operating system’s built-in sharing service. Being able to quickly tweet using that service would be a really nice touch.

That’s by no means everything, but just what I could think about in the five minutes or so it took me to compose this post.

So if you’re a Mac developer looking for work, consider Mozilla! You’ll be glad you did! It’s a kick-ass place to work, and a lot of fun. And you’ll be making a great browser greater on the best operating system around.

In addition to writing a lot of material, we got a lot cleaned up, and spent some great time talking, getting to know one another, and seeing the city of San Francisco and the surrounding area. Our ferry ride up to Sausalito for dinner, and the cab ride back to the city across the Golden Gate Bridge was, I know, a big hit with some of our first-time visitors to the Bay Area.

I personally enjoyed meeting everyone I didn’t already know, and seeing familiar faces once again. On top of that, it was nice to check out the San Francisco office, which I’d not yet seen. I understand now why it’s so popular. It’s one of the most impressive locations I’ve ever seen!

While most people share pictures of the view of the Bay or of the Bay Bridge, I want to share this one. I remember this sign from when I was a kid, but never from this close up!

It makes me very proud to work for an organization that will bring community members together like this to collaborate in real time, in person, now and then. It’s great for community bonding as well as for just getting things done. And I’m proud of our contributors that attended for giving up some of their personal time to spend time with us here in the City by the Bay. Thank you!

Note: This Wiki Wednesday is published way off-schedule, and a little short, due to a technical problem I ran into compiling it.

Contributors to Wiki Wednesday will get recognition in the next Wiki Wednesday announcement. Thanks in advance for your help!

JavaScript

Thanks to Berker Beksag for contributing!

• Float32Array
• Using js-ctypes
• Regular Expressions

SeaMonkey

• Debugger.Frame
• SpiderMonkey compartments
• JS_GetPropertyDefault

Developing Mozilla

• Building Firefox with Address Sanitizer
• Table of errors
• Creating custom Firefox extensions with the Mozilla build system

Extensions

Thanks to Neil Rashbrook for his contributions since last time!

• UpdateListener
• Extension etiquette
• Components.utils.makeObjectPropsNormal

XUL

• Introduction to XUL
• tab
• XULBrowserWindow

XPCOM

Thanks again to Neil Rashbrook for his help!

• nsIPluginHost
• Components.utils.schedulePreciseGC
• nsIWorkerGlobalScope

Interfaces

Thanks (yet again!) to Neil Rashbrook for his contributions.

• nsISelection2
• IAccessibleRelation
• amIInstallTrigger

Plugins

• NPN_RequestRead
• Drawing and Event Handling
• Plug-in Basics

CSS

Thanks to brianloveswords!

• inherit
• background-clip
• clip-path

Edit Source adds options to the Web Developer menu and the context menu on text-based documents (including HTML, CSS, XML, and JavaScript), which lets you open a source editor window. You can then edit the document’s text, save it to your local disk, and most interestingly, re-render the original document (for HTML, anyway) to reflect the changes you’ve made.

This makes it a handy tool for experimenting with HTML, and a nice learning tool. In addition, if you open up an about:blank tab and edit its source, you can write HTML from scratch and see what it looks like rendered on screen. That’s also a pretty neat trick.

There are things that would be fun and useful to add to it, but I probably need to move on and get to writing again! So I’ve posted the code to Github. Feel free to take a look and tweak it! There’s an IDEAS.txt file in the repository you can look at for some thoughts for things that might be handy to add.

Done? Good.

So this is going to have something of an impact on the priorities for Mozilla’s staff documentation team. Since we’re putting an emphasis on Web apps and, by extension, open Web standards, we’re going to be increasingly focused on this area of documentation, and by extension (no pun intended) less of our attention will be directed toward add-on related documentation.

That means we’re going to need to rely more on the broader community to cover extension and other add-on related documentation work. If we don’t pull together a few folks to volunteer to work on that, it will likely fall behind significantly over the coming months, unfortunately. We will see what we can do to at least ensure the absolutely critical stuff (things that break compatibility, for instance), but beyond that, it will pretty much be up to you!

In the meantime, the staff writers will be doubling down on the Apps, BrowserID, Open Web (CSS/DOM/HTML/JavaScript), WebAPI, and probably WebRTC related documentation.

You can expect to see further blog posts on this over the coming days and weeks. It’s going to be an exciting ride!

That means we need to sort out which documentation issues need addressing the most urgently.

What documentation is “important”?

There are basically two categories of high-priority documentation:

1. Very new and exciting technologies that we want to be able to make a big deal of. These need documentation so that developers can jump into them quickly and easily.
2. Significant changes to existing technologies that may cause problems for existing web content or Firefox add-ons.

The documentation team isn’t always the best set of people to determine which documentation issues fit into these categories. As such, we need to start recruiting others to participate in the prioritization process.

Who can help?

Those two categories of high-priority documentation I mentioned above just happen to correspond to two very different sets of people:

1. Evangelists and product marketing folks are ideal for flagging the priority on documentation issues that correspond to new and exciting technologies. They want to be able to promote technologies through blog posts, press releases, release notes, and so forth, and as such want to have documentation for those high-visibility technologies. Preferably before they start making a fuss about them.
2. Engineers and developers tend to know which changes are going to be a headache for web and add-on developers. That puts them in a perfect position to mark the priority on these documentation issues.

How do you help?

If you fit into one of these categories (or, really, even think you’d like to try to help out), you can easily help prioritize our documentation issues! We use a documentation tracker web application developed by Florian Scholz. It interfaces with Bugzilla, using the dev-doc-needed and dev-doc-complete keywords we apply to bugs that affect documentation, but adds additional features, including support for tracking bugs by Firefox release, additional note fields, and, most importantly for the purposes of this blog post, a priority field for each bug.

So here’s how you can help: go to the documentation tracker, log in (using your Bugzilla login), and peruse the list of bugs. Click the edit button at the right edge of the row for any bug you can help prioritize, and set the priority. It’s that easy; it’s a wonderful tool and we use it a lot.

What do the priorities mean?

The priority field can be set from 1 to 5. Each of these values means something fairly specific (in fact, I’m hoping Florian will update the tool to include a reminder of the meanings in each menu item in the popup for the priority). Those values are as follows:

1. Must be documented if possible within one week after reaching Aurora.
2. Must be documented if possible within one week after reaching Beta.
3. Must be documented if possible within one week after release.
4. Must be documented if possible before the next release.
5. Should be documented. Someday.

Yes, these values are tied to Firefox releases. However, that gives a general sense of the urgency of the item, even independently of Firefox itself.

Let’s say you’re an evangelist, and you’re looking over the list and see that a particular bug corresponds to a technology you want to blog about when the corresponding release reaches Beta. You should in that case set that bug’s priority to 2. That lets us know to put a rush on that item, but not to block any priority 1 items on it.

It’s not a guarantee!

It’s important to keep in mind that our resources are stretched pretty thin right now. We can’t guarantee that items will be documented by the time the priority requests it be done. We will, however, do our best. And, of course, you should always feel free to contribute documentation. Even a rough outline will encourage someone to come along and spruce things up!

Help us help you

The developer documentation team is here to help. We can get things done faster if you give us all the information you can about when you need something written and, if possible, how it works (or at least the name of someone we can contact to ask questions). Feel free to add that to the notes field in the doc tracker!

And, as always, feel free to contact me by email or drop into the #devmo channel on IRC with your developer documentation related questions.