We’re going to close the survey down TOMORROW, and we need to get as many responses as we can. The survey should only take 5-8 minutes to fill out, and we’d really appreciate all the feedback we can get.

>>> Feature Page Survey < <<

Thanks!

We’re going to close the survey down at the end of January, and we need to get as many responses as we can. The survey should only take 5-8 minutes to fill out, and we’d really appreciate all the feedback we can get.

>>> Feature Page Survey <<<

Thanks!

The survey should only take 5-8 minutes to fill out, and we’d really appreciate all the feedback we can get.

Feature Page Survey

Thanks!

Posting a rant is also a pretty crap way to get your point across, because:

a) It’s hurtful and humiliating to the person being criticised
b) It immediately puts the other person on the defensive
c) It brings the situation to the direct attention of a larger number of people, which makes the other person feel even worse if they do turn out to be wrong
d) It often doesn’t accomplish a lot other than bring some widespread drama to a situation that probably could have been resolved in a much more sensible way

Mozillians are almost invariably smart, capable people who care deeply about what they’re doing and are always genuinely trying to do the right thing. Always start from that premise, give them the benefit of the doubt, and just talk to them if there’s a problem.

I’ve made one small-but-awfully-helpful change to how the product Feature Lists are going to work. Now, if you start working on one of the items on the list, please change the “Rank” for that item on the Feature List to “In Progress”. Don’t worry about moving it to the top of the list, we’ll sort that part out.

I’ve done a few on the Firefox Feature List, as an example. Obviously this makes it a lot easier to figure out what is currently being worked on.

If you are working on a Feature from one of the Feature Lists, please do me a huge favour and flag it as “In Progress” on the Feature List Page. Thanks!

To manage all of this, we need to be a bit more disciplined about what we do and how we do it. Prioritizing what we want to do (and when) is a big part of what this post is all about — we can’t do everything all at once, so we need to be more deliberate about what we focus on at any given time.

We also have to be more conscientious about what and how we communicate with each other — there simply isn’t enough time for any one of us to dig through our various channels to find out everything we need to know. We need a consistent and centralized place where everyone can go to get the information they need.

How are we doing this?

We’ve developed a system to help us manage this stuff, and it looks something like this:

simplified, but you get the idea

Roadmaps are where we set forth our vision for each product and what we believe our priorities need to be in order to achieve that vision. Roadmaps often include other stuff as well, but for the most part the Roadmaps define where we want to go (vision) and how we’re going to get there (priorities).

Product Managers don’t weave these out of whole cloth, but drive the process of creating the Roadmaps through extensive discussion with people throughout the community. These are also not things to be dusted off once a year when we sit down to write a new roadmap — we will evolve them as we go.

Feature Lists are the things we believe need to be changed or added in our various products over the next year or so. These lists are derived from the Roadmaps and then divided by engineering group. The purpose of Feature Lists is to make it easier for engineers to know what they should work on next.

Like Roadmaps, Feature Lists will be revised constantly as we add, remove, and reprioritize things based on changing circumstances and information, and as we ship features out. Ultimately, each Feature List will be rank ordered by priority — #1, #2, #3, etc. with no ties — but we’re not quite there yet.

Feature Pages are really the heart of this system, as this is where each Feature is defined, specified, staffed, and tracked during development. The goal is that eventually (by Firefox 7) all significant development projects will be defined and tracked via Feature Pages.

When we talk about a feature, we’re talking about a “shippable unit”, a well-scoped and atomic piece of work that improves a part of one of our products. This is a smaller unit than what we normally think of as a feature, but conceptually larger than a typical bug fix.

Something like “Create a Home Tab as a Permanent App Tab” is a feature under this definition, whereas “App Tabs” is too large to be well-scoped. “App tab rendering glitch on OS X” is too small to be worth feature tracking, as it is really just fixing a flaw rather than adding to the product or changing how something behaves.

Feature Pages are really guidelines rather than strict templates to be slavishly filled out. Use them as you see fit. The only requirements are:

• The status block at the top be filled in and kept up to date.
• The team list must be fleshed out as completely as possible (and everyone on that list should be aware that they’re on that list).

After that, you’re free to do whatever you need with the Feature Pages. The sections in the template are really just prompts to help you get things clarified and written down, but you can ignore them if it makes sense to do so.

With the vision and priorities defined in the Roadmaps, and the Features defined and tracked through Feature Pages, we’re just missing a place to track the collective progress for each release. This is where the Release Tracking page comes in.

Once a Feature is underway and we know which release it’s going to target, the status block from that Feature Page will be transcluded into the appropriate table on the Release Tracking page.

Throughout development, with Feature Page statuses being updated regularly, the Release Tracking page will make it easy to see at a glance how things are progressing. Should a feature miss a release, it’s easy to move the feature into the next release table and continue tracking progress there.

No Surprises

The primary goal for this system can be summed up as “no surprises”. Everyone across the organization — engineering, QA, marketing, PR, web dev, IT, build & release, etc. — should be able quickly and easily to find out:

• what is currently planned for each release
• how things are progressing
• what they need to do
• when they need to do it

No surprises. This will never be a failsafe system, but I think we can get a lot closer to there than where we are now. This is a first step, and we will evolve the system as we learn more.

I’m not looking to track every single bugfix, just changes or additions that you think would be significant enough to include in a write up or announcement about the release — anything that would be of interest to users and/or developers.

If you are not sure whether what you’re working on qualifies, please err on the side of assuming it does. You can contact me by:

• email: deb-at-mozilla-com (email if at all possible)
• leaving a comment on this post
• pinging me in IM (deb.richardson@mac.com) or IRC (dria)
• or at very least cc’ing me on the relevant bugs

Please include any relevant bug numbers and links to wiki pages!

Launch days are great, great days. Official announcement here.

We’re just about ready to release an updated version of Personas Plus for both Firefox 3.6 and Firefox 4, so we’re holding a somewhat impromptu testday for it on Friday (but feel free to start early if you like).

Where to get it…

If you have a few minutes to spare, please grab Personas Plus RC4 from the FTP site and install it on Firefox 3.6 or Firefox 4. You will have to “allow” the site to install the add-on in the dialog that pops up:

https://ftp.mozilla.org/pub/mozilla.org/labs/personas/personas-1.6.2rc4.xpi

How to help…

Please test a few of the activities listed below (and anything else you can think of). If something appears odd or broken, either post a note here, leave a comment on the Personas forum thread or send an email to me directly at deb@mozilla.com.

On IRC?

If you’re on Mozilla IRC, feel free to join the #personas and #qa channels — I’ll be online for most of the day, so look for me (dria) there if you have any questions or think you have found a problem.

Some stuff to test…

• Does the add-on icon (Fox Mask) appear properly in your status bar (Firefox 3.6) or add-on bar (Firefox 4)?
• When you click on the Fox Mask icon, does the menu appear to be complete and correct?
• Do all the menu items seem to do what they should?
• When you open the “My Favorites” menu item, does clicking the “Sign in to Access your Favorites” take you to the correct page on GetPersonas.com (the account sign-in and creation page)?
• When you select the “Random Selection from [galleryname]” submenu item, do you get a new, randomly selected Persona?
• If you have selected the “Random Selection from [galleryname]” submenu item, does your Persona change periodically (every 60 minutes or so)?
• If you are logged into your GetPersonas.com account, does clicking on “Go to My Favorites” do the correct thing?
• If you are logged into your GetPersonas.com account, are you still logged in if you click any of the “#### More from [galleryname]” menu items to visit the GetPersonas.com galleries?
• Go to Preferences and check the “Show Custom Persona in menu” checkbox. Does this add a new “Custom Persona” menu item?
• Are you able to create and apply a custom persona using the Custom Persona menu item?
• Does uninstalling the add-on from the add-ons manager work properly?

Did we miss something?

If you can think of anything else that we should test, please let me know and I’ll add it to the list. Thanks!

A fourth (and really hopefully final!) Release Candidate of the Personas Plus add-on for Firefox 4 is available on the FTP servers. The RC works with Firefox 3+, current nightly builds, and Firefox 4 beta releases.

You can download the add-on here: https://ftp.mozilla.org/pub/mozilla.org/labs/personas/ — you want to get personas-1.6.2rc4.xpi.

If you find any issues (or if you test and everything seems OK), please post a comment here! Thanks!

This RC fixes an interaction with GetPersonas.com, so is relatively minor. There are still some known issues, some of which will be fixed in a future version and others which are server-side. Thanks again for all your help!

A third (and hopefully final!) Release Candidate of the Personas Plus add-on for Firefox 4 is available on the FTP servers. The RC works with Firefox 3+, current nightly builds, and Firefox 4 beta releases.

You can download the add-on here: https://ftp.mozilla.org/pub/mozilla.org/labs/personas/ — you want to get personas-1.6.2rc3.xpi.

If you find any issues (or if you test and everything seems OK), please post a comment here! Thanks!

Zarro Boogs!

We hit zero blocking bugs for Firefox 4. This is a pretty big deal for anyone and everyone who has been working on this release, and means we’ll be rolling out a release candidate Very Very Soon…

Demos!

We launched a demo site that includes this fully interactive HTML5 poster (grab a copy of the latest Firefox 4 beta to get the full effect). I’m biased, obviously, but this is one of the coolest things I’ve seen on the Web in a hell of a long time…

Web Apps!

We announced the availability of the first developer integration release of our Open Web Apps project (along with a neat video that explains what the heck we’re actually talking about when talk about “web apps”). ReadWriteWeb says that we make “a better case for web apps in minutes than Google did in months,” so if you’re still not sure what Web Apps are all about, you chould check out the post over on the Labs blog.

If you’re a web developer, there’s also a bunch of documentation over on the Mozilla Developer Network, and a gallery of apps that people have already built.

The best part? We’re just getting warmed up. 2011 is going to be a ridiculously amazing year.

A second Release Candidate of the Personas Plus add-on for Firefox 4 is available on the FTP servers. The RC works with Firefox 3+, current nightly builds, and Firefox 4 beta releases.

The more testers the better, so we could really use your help. You can download the add-on here: https://ftp.mozilla.org/pub/mozilla.org/labs/personas/ — you want to get personas-1.6.2rc2.xpi.

If you find any issues, please post a comment here or in the bug. Thanks!

UPDATE: Please test personas-1.6.2rc2.xpi, not rc1, thanks!

A Release Candidate of the Personas Plus add-on for Firefox 4 is available on the FTP servers. The RC works both with the current nightly builds and Firefox 4 beta releases.

The more testers the better, so we could really use your help. You can download the add-on here: https://ftp.mozilla.org/pub/mozilla.org/labs/personas/ — you want to get personas-1.6.2rc2.xpi.

If you find any issues, please post a comment here or in the bug. Thanks!

Take part by joining the #testday channel on irc.mozilla.org any time on Friday between 9am to 5pm Pacific time. There’s an etherpad document we’ll be using throughout testing, and you’re welcome to add your ideas about we could or should be testing for on Friday. Please try to find a few minutes to stop by and give us a hand!

Note: Where it says “[EMPTY PAGE]” that’s where the actual Web content or Dashboard would be. So that’s just a lie.

Zenji was an attempt to re-envision the browser as something smaller and simpler. Some of the ideas have actually shown up in modern browsers, which is gratifying. Other ideas are just terrible (no back button? whuck?). Were I to sit down now and put together ideas for Zenji 2, I would do a lot of things differently.

That in mind, here’s a quick overview of Zenji. The long version is a 13 page PDF which you can download.

Goals
The primary goal of Zenji was to be “as simple as possible, but no simpler.” It encompassed a pared down feature set that would let most users use the vast majority of the Web without being overwhelmed.

While Zenji was to be as simple as possible, it also had to be able to grow with the user. Novice users become expert users over time, and what they need in a browser evolves as well.

Features and UI

What Zenji doesn’t have:

• Traditional tabs
• A URL bar
• Any form of bookmark organization
• Back/forward buttons (2010 editorial comment: yeah, what?)
• A “home page”
• Context menus
• Most preferences or customization options
• Traditional “addons”

What Zenji does have:

Search: Search is the primary focus of Zenji, with the main search bar stretching across the entire top of the window.

Toolbar: The Zenji toolbar does not appear at the top of the window, but rather on the side. Default toolbar buttons are: Dashboard, Stars, Timeline, Subscriptions, Zoom, Widget bar. Additional buttons include: Downloads and Archives.

Dashboard: The dashboard was envisioned as a new breed of “start page” that is local on the users’ machine, but that pulls information both from the browser and the web. It could include things such as: recently starred pages, most frequently visited pages, latest subscription updates, Zenji tips & tricks, help/support info, new widget promotion, user polls & feedback requests, etc.

Stars: Stars are Zenji’s simplified bookmarks. Clicking the “Star” button opens/closes the Stars sidebar, which includes the user’s starred pages sortable by recency and/or frequency. Includes a search box.

Timeline: Timeline is a hybrid of history & tabs that can be viewed as a list (with favicons) or thumbnails.

Subscriptions: Subscriptions are essentially fully integrated feeds. If you subscribe to a page, Zenji shows you the most recent updates to your subscriptions in this sidebar.

Zoom: Apparently I thought zoom was important enough to have on the main toolbar. This would probably be different now :)

Downloads: Sidebar of stuff the user has downloaded through Zenji, all neatly organized. Everything goes into a single directory, which can be sorted in Zenji in various ways.

Archives: Archived pages (basically saved web pages) are stored in a single Zenji archives directory.

Widget bar: This is where the user can add things to Zenji’s UI and functionality. Widgets were envisioned as a new breed of add-on, being small, very task-specfic, and allowed to change nothing about Zenji’s UI beyond, at most, displaying a panel when clicked. Examples would include: Gmail bookmark/icon with new message count overlay, Facebook w/ overlay, Current weather + temp, Flickr RSS stream and uploader, Personas, etc. Widgets would be a simple drag/drop to install and uninstall.

Page actions: Star, Subscribe, Archive.

And et cetera. There’s more detail (and more craziness) in the PDF. Turns out thinking about browser design is a lot of fun :)

Check out the Mozilla Labs Chromeless browser experiment if you haven’t — the team is working on making zany experiments like this as fast and easy as possible, which I think could lead to an amazing period of exploration and innovation.

Thinking about the Open Web

I’ve been thinking about how to talk to people about what the Open Web is, why it’s so important, and why they should care.

The Open Web as a global public resource

It struck me that the Open Web is analogous to some other fundamentally vital things in our society:

• public libraries
• public schools
• public parks
• public broadcasting
• public roads
• public art
• public museums
• public galleries
• etc.

Many of these things are deemed so vital a part of our everyday lives and societal infrastructure that we support them through our tax dollars. Others are supported by concerned citizens who believe so deeply in their importance that they donate not only their hard-earned money, but also their time, skills, and creativity.

The Web is an increasingly important part of our lives, and it is absolutely essential that it remain free and open and accessible to all. If it doesn’t — if the Web becomes closed, restricted, controlled, and inaccessible to anyone who is disadvantaged or marginalized in some way — our whole, global society will suffer as a result. The Web cannot become something that further delineates the haves from the have-nots. It is already far too important for that, and it is still only in its infancy.

Mozilla exists to support the Open Web

Mozilla is an organization devoted to ensuring that the Web continue to develop as and remain a global public resource — akin to libraries, schools, parks, and roads — and everything we do, every resource at our disposal, is focused towards this end. This is the absolute core of our mission as outlined in the Mozilla Manifesto, and it is the heart of everything we strive towards.

Why Mozilla makes a browser

Making a browser is one of the most important things Mozilla currently does — not as an end unto itself, but rather in support of our larger mission and goals.

The browser is by far the most important tool we use to create and consume the Web. Without an open browser there is no Open Web. This is why we build Firefox, and why we’re pushing hard to get Firefox on to as many devices and desktops as we can. The Open Web is an increasingly crucial part of our lives and our society, and Firefox is one way we’re working to ensure that the Web remain open and available for everyone.

What do you think?

Is this a useful way to think about and talk about the Open Web to people who might not quite get what we’re so excited about? Not everyone is going to grok the analogy in the same way — and this certainly isn’t the only way to talk about it — but I think that most people understand that public works are a good thing, and that ensuring open and equitable access to fundamental resources and infrastructure — which now includes the Open Web — is an essential part of a just and civilised society.

Also, if you have photos posted but don’t use Flickr, please leave a comment here with a link to where you’ve hosted them. Thanks!

1. Copy/paste these rules and questions into a blog post, answer the questions, then tag some other people (however many you like) and encourage them to do the same.
2. Include a link to the original post.
3. You don’t have to be tagged to take part — if you see this post and want to play, just dive on in. Simple!

How (and when) did you originally get involved with an open source project? Which projects have you contributed to?

I first got involved with open source-related stuff in 1999 when I started Linuxchix (still going) and the Open Source Writers Group (long since dead). In addition to those, I’ve contributed to the PA-RISC/Linux project (about forty million years ago), and the Mozilla project, plus little fiddly-bits here and there.

Why did you choose to contribute to an open source project?

Because I could. I had been using Linux for a few years at that point and I loved it — I loved the community and the openness and everything else about it. When I realized that I had the skills and ability to make real and useful contributions, I got involved. Linux and the open source community had given me a lot, and I wanted to give back however I could.

If you were to pick one or two people who have had a major influence on your involvement with open source, who would those people be? Why?

Chris Beard: Some 10 or 11 years ago, I read about Chris and the Puffin Group (a small Linux consulting company) on Slashdot and sent Chris (a complete stranger) an email asking for a job. He hired me. This is a pretty short story for what has ended up being a decade-long friendship. I have an enormous amount of respect for Chris and the work he does — easily one of the most visionary and driven people I’ve had the privilege of working with.

Mike Shaver: Some 10 or 11 years ago, I met shaver the day before his wedding to which he immediately invited me (a complete stranger). I declined, and I regret that decision to this day because Mike has turned out to be one of my best friends. I’m going to stop now because I’ll just get teary-eyed, and it would take more than a few hours to talk about how his friendship has (actually, and for reals) changed my life.

Both Chris and Mike are why I’m part of Mozilla now, and I believe I still owe them both a beer or two for that.

How have you personally benefited from being involved with open source projects?

Getting involved with open source turned into a career for me. Mozilla, in particular, has been spectacular because this project encourages people to push beyond themselves and to reach for and learn new things all the time. I’ve learned more and done more in the past five years of being involved with Mozilla than I would have been able to do in any traditional organization, had I been able to wedge a foot in the door.

Not only has it become a career, being involved with open source has (as I foreshadowed before) lead to some of my deepest and most lasting friendships. It turns out that open source projects are a fantastic way to meet like-minded (but oh-so-entertainingly diverse) people. I know, talk to, and work with incredibly brilliant and passionate people all over the world, every day. I wouldn’t trade this for anything.

What advice and/or encouragement would you give to someone who is considering getting involved with an open source project?

Do it! Get involved. Persevere. Step up. Be brave. It can be awfully intimidating and overwhelming when you first start out, but don’t give up. Find some niche where you can make a contribution, then just get started. It could be the best thing you’ve ever done.

• Chris Beard
• Mike Shaver
• David Humphrey
• Lukas Blakk
• Mike Morgan

The rules:

1. Copy/paste these rules and questions into a blog post, answer the questions, then tag some other people (however many you like) and encourage them to do the same.
2. Include a link to the original post.
3. You don’t have to be tagged to take part — if you see this post and want to play, just dive on in. Simple!

The questions:

1. How (and when) did you originally get involved with an open source project? Which projects have you contributed to?
2. Why did you choose to contribute to an open source project?
3. If you were to pick one or two people who have had a major influence on your involvement with open source, who would those people be? Why?
4. How have you personally benefited from being involved with open source projects?
5. What advice and/or encouragement would you give to someone who is considering getting involved with an open source project?

That’s it! I’ll post my own responses soon :)

It might sound sort of silly or contrived, but it turns out that a simple note of appreciation really can have a huge impact. Since I’ve started using Rypple to send out kudos, I’ve received a few notes from folks telling me that I’ve basically made their day. It’s a little thing, and doesn’t really take more than a couple of minutes out of your day, but it can really make a difference. We don’t often get genuine, heartfelt, positive feedback, so it’s really incredibly energizing when we do.

Everyone with a Rypple account (which is anyone, since everyone can sign up) can log in and send kudos to anyone with an email address. It’s totally wide open and anyone can do it — so if you have a few minutes sometime today, think of someone who’s done something awesome, head over to Rypple, and send them a kudos. The more you do it, the more fun it becomes.

So, in addition to getting new content produced to help people, I’m going to start collecting existing materials together and figuring out how to make those easier to find and use.

I’ve created a new page on wiki.mo called Learning Mozilla, listing on it some of the useful things I already know about. Now I need your help: if you know of other resources that would be useful for someone who wants to learn more about Mozilla, please take a few moments to add it to the page or leave a note (with a URL) in the comments here.

Anything and everything is great — I’ll dig for more content as I can, and I’ll take it upon myself keep the page cleaned up and organized, so don’t worry too much about where to list things or how to format stuff. Just add the links and we’ll sort out the rest as we go.

On the other hand, positive feedback is absolutely energizing. Those moments where someone goes out of their way to say “thanks” or “awesome job” or “you rock” really does make it all worthwhile. Feeling appreciated — knowing that someone genuinely cares about and values the work you do — can often make the difference between something being a burden or a joy. For me, receiving positive feedback is the most powerful motivator out there — more so than money, fame, or anything else.

Rypple (which we use at Mozilla) recently built a new feedback mechanism into their service called “kudos” that you can use to send someone a quick “thanks”, “you’re awesome”, or “you rock” sort of message. The message you send is visible to everyone in the organization, so serves as a public note of appreciation. Other people can comment on the kudos as well, so there’s a way to quickly add a “+1″ or otherwise pile on the love. You can read more about the Rypple kudos feature (and an ongoing contest they’ve launched to promote it) over at WorkplaceHero.com.

The Rypple kudos system really is fantastic. We don’t often go out of our way to publicly acknowledge the awesome things our coworkers do, but Rypple has given us a fun, fast, simple, lightweight, and unintimidating way to do so. If you haven’t checked it out yet, you should — take a minute to send a kudos and make someone’s day :)

So far, people have suggested the following:

• Lifecycle of a Bug – introduction to the stages involved in fixing a bug from start to end
• Building Firefox – introduction to getting the Firefox source code and compiling it, while going over the basics of hg
• Test Frameworks – introduction to the different test frameworks we use, and how to write a basic test in each of them
• Drinking from the Firehose – how to stay on top of the news, difference between “stream of development and ideas” and “announcments”, how to understand things like what the next milestone is
• Bugzilla for Developers: Getting your patch into the product – how to nom for review; how to determine if you need to nom for approval, blocking, etc.; writing tests; checkin wrangling; watching the tree.
• Gaining Traction – how to publish that wicked cool idea you have; how to rally people around it to see if there’s interest; moving from idea to implementation
• How to navigate the code using MXR/DXR
• How to use and contribute to MDC
• Writing your first automated test
• How to do your own screencasts/videos
• Mozilla Developer Tools & Workflow
• How to optimize edit/compile/test loops
• Presentation tips & tricks

What other screencasts or video introductions do you think would be useful for learning Mozilla and getting involved with the project and community?

Before Readability

After Readability

Note: Readability runs fine on Minefield if you use Nightly Tester Tools to force-install. There’s also a bookmarklet version if you don’t want to install an add-on.

One of the most important parts of my week is my one-on-one (1:1) meeting with Dan, my manager. These meetings generally only last around half an hour, and it’s time extraordinarily well spent. In that half hour we catch up, discuss projects and status, review priorities, troubleshoot blockers, checkpoint against our quarterly goals, and use the time to give each other feedback. It might sound like a pretty dense 30 minutes, and that’s because it is. Our 1:1 meeting is a tightly packed conversation that establishes and reinforces my direction, priorities, and motivation. As a remotie*, I would be lost without it.

The actual meeting is only part of the story, however — while the meeting only lasts for half an hour, I do some prep work the day before. This prep work mostly involves reviewing my projects and goals, writing out what I want to talk about, and sending those notes to Dan so he can review them before we meet. I find this process extremely useful.

Over the months I’ve established a more-or-less standard format for my 1:1 prep notes that includes five fairly straightforward sections:

• Accomplishments & status
• Blocked/Waiting on
• To do over the next week
• Areas to develop
• Quarterly goal tracking

Accomplishments & status: This is where I do a quick rundown of my current projects, with one or two sentences covering what I’ve managed to get done in the last week and what the current status looks like.

Blocked/Waiting on: This is where I list the projects I’m stuck on and why, or other things that are blocking progress — either waiting on resources, people, feedback, or whatever else. Having this section is absolutely vital — if I’m blocked on something, we can usually talk it through so I get unstuck, or Dan can figure out what he can do to help.

To do over the next week: By writing out a short list of specific things I plan to work on over the next week, Dan and I can make sure that I’m working on the right things and am prioritizing things properly. This doesn’t take a lot of time to go over, and since we checkpoint on this every week there usually aren’t any changes, but sometimes my task list gets rejigged slightly if other things have come up elsewhere in the organization.

Areas to develop: Usually this is a one or two sentence “big picture” sort of thing. Dan and I talk about longer-term career development once every month or two, discussing what I need to do or develop in order to progress, become more effective, and have more impact. In this part of my prep notes I take a few minutes to review how I think I’m doing in relation to what we discussed and jot down what I believe I need to focus on improving the most.

This section gives Dan a chance to do some career development coaching. While we normally deal with this part of the meeting in a matter of minutes, it’s profoundly useful — this is an incredibly quick and easy way for me to get ongoing lightweight feedback from Dan on a regular basis.

Quarterly goal tracking: We establish a set of goals each quarter, and every week Dan and I review progress on the ones I own and am driving. I find this useful because regularly checkpointing against my goals helps me make sure I’m focusing on the right things. By reviewing these weekly, we can also make ongoing course corrections where needed. Life rarely happens exactly according to plan, and priorities and projects can shift. It’s far better to review and adjust things weekly than to do a single review late in the quarter just to realize that things got off track (at which point the panic sets in).

Video chat: Another thing I should mention is that Dan and I have our meetings using Skype video. We used to just use the phone, but Dan talked me into using video chat and it’s really much, much better. As a remotie, being able to get “face time” like this is way more important than I thought — not only is the communication much higher bandwidth, there’s a psychological impact I can’t really explain. I just feel more connected to the rest of the company, which is both surprising and fantastic. If you’re remote, you should really try using video chat for your 1:1 meetings…I can almost guarantee that it’s more useful than you expect.

And that’s about it. Having developed the habit of prepping for my 1:1 meetings this way, it only takes me about 15-20 minutes to write up my notes to send to Dan, and it makes our meetings incredibly focused and useful. If you’re not sure you’re getting the most out of your 1:1s, you might try something like this — a half hour of prep work on your part for a half hour meeting can have a huge impact.

Do you have particularly awesome 1:1 meetings? What makes them awesome? What tips would you give to people who would like their meetings to be more useful?

• remotie: noun, a person who works in a different geographic location than his/her manager.

This is something the Planet team was discussing prior to the holidays, but we hadn’t picked it up again until prompted by Matt’s post. It turns out that we should be able to rig the existing Planet software to do more or less what Matt suggests, we’re just not currently sure how well the software will deal with a large number of channels.

I figure we may as well start by defining the ideal and work backwards from it if we run into technical limitations. I’ve expanded upon Matt’s proposed category list, and started defining a set of keywords and keyphrases that the Planet software would use to filter posts into each category.

I’ve posted that list on the Mozilla wiki, and would like your feedback and help. What categories are missing? Which could be safely consolidated? What other keywords should we filter on for each? Etc. You can edit that page directly if you like, or leave a comment on this post. Thanks!

Planet Mozilla policies

The policies are minimal and relatively straightforward, but if you have any questions please feel free to leave a comment here or to email any/all of the Planet Mozilla team (listed on the wiki page).

Planet Mozilla survey.

Thanks!

The Planet Mozilla team would like your help. Planet Mozilla is a central and vital part of the Mozilla Community, but we think it could be better. We’re looking for your input on what you think Planet is (or should be) for, how well it’s fulfilling that purpose, and how it could be improved or augmented to better serve our community.

Please take a few minutes of your time to answer our three short questions about Planet Mozilla. We really want as much feedback as possible, so you can also leave comments on this blog post if you have other questions, comments or insights about Planet or other Planet-related things. Thanks!

Planet Mozilla survey.