Developing a Mozilla Code of Conduct

Mozilla, Mozilla community, Open Source, Work 1 Comment

Mozilla is going to explore developing a Code of Conduct for our community and contributors, using the Ubuntu project Code of Conduct and supporting documents as an initial template. We’re looking to create something aspirational rather than proscriptive, and the Ubuntu documents provide a tried and proven starting point.

The next step is to look at those documents and see what we need to do to adapt them to work for the Mozilla project. For this, I need your help.

I’ve started a thread over in the mozilla.governance newsgroup to get the process started. It includes a link to a rough first draft of a Code and an explanation of where that draft came from.

Please note that all discussion related to the development of a Code of Conduct should happen in that thread/newsgroup. If you post comments here, I’ll just ask you to move ‘em over there :)

Please, please try to make time to participate if you can. This is a big and very important step for the Mozilla project and our community.

Thanks!

About rants: cathartic but generally destructive

Mozilla, Mozilla community, Open Source, Work 1 Comment

Before you post a rant about something going on in the Mozilla project, take a moment to put yourself in the other person’s shoes — getting blindsided by a bunch of criticism on a widely-read forum when no one had previously asked you about it or tried talking to you is never, ever fun.

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.

Firefox Planning & Tracking: A New Approach

Firefox, Focus, Goals, Mozilla, Open Source, Work 4 Comments

If you take a look around Mozilla these days, you’ll notice that there are a lot more of us trying to do a lot more things a lot faster.

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.

A Damn Good Day to be a Mozillian…

Browsers, Firefox, Innovation, Internet, Mozilla, Mozilla Labs, Open Source, things that are awesome, Web, Web Development, Work 4 Comments

Skimming back through my Twitter stream, it turns out that yesterday was a pretty great day in the ol’ salt mine. Sometimes when you’re right in the thick of it, it’s hard to really notice all the awesome that’s going on around here, so here’s a quick roundup of some of it.

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.

Zenji: towards a simpler web browser (from 2007!)

Browsers, Innovation, Mozilla, Mozilla Labs, Open Source, Ramblings, Web, Work 8 Comments

Robcee and I spent a bunch of time thinking and talking about alternative browser designs back in 2006/2007. He recently posted his idea from back then, so I figured I’d dig through the archive and post mine. I call it Zenji.

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

zenji1

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.

zenji-stars

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

zenji-timeline

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.

zenji-subs

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.

zenji-widgetbar

Page actions: Star, Subscribe, Archive.

zenji-pageactions

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

Browsers, Firefox, Internet, Mozilla, Open Source, Web, Work 7 Comments

library books
library books :: timetrax23

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.

My responses…

Meme, Mozilla, Open Source, Work No Comments

As promised…

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:

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.

Tagging
Icons by N.Design Studio. Designed By Ben Swift. Powered by WordPress and Free WordPress Themes
Entries RSS Comments RSS Log in