A Weird Ritual

I stumbled across the short form creative brief by way of a tweet from @jmspool and I had to share it. It reminds me of something we built at dojo4 when I was CEO there, but it includes a Very Important Addition.

Technology and design work is expensive, far too expensive to do without some anticipated return (unless you work in a sector that allows you to light bricks of technology dollars afire on a hot summer day “just for the ambiance”).

When I was at dojo4, upon signing a contract with a customer, I tried to capture a couple sentences about their anticipated return on a 3″ by 5″ notecard. I pinned the notecard to a corkboard where everyone could see it (and I mean everyone: our employees, our guests, our other customers). We called the notecard the Project Compass.

The project compass was intended to be a guide, an arbiter in times of uncertainty. Whenever a question arose about project scope or direction, we could look at the project compass for clarity. A typical project compass might be “Redesign the website and add a feature allowing customers to create and manage their own profiles.”

Astute readers may notice the above compass doesn’t describe a return on investment at all. That’s quite common, unfortunately. It is HARD to achieve clarity about a project’s anticipated return. Often, a project’s sponsor has already done some initial analysis and design and is giving implementation experts the output of the initial analysis (“Redesign the website”) instead of the input (“Increase signups and improve retention”). Sometimes the sponsor can’t articulate what they hope to achieve. Just as often the implementation team can’t hear it.

At dojo4 we assumed imperfection in our project compass. Every project required a compass to move forward, but we agreed (and said out loud) that the compass might change. We even asked @anthonydimitre to draw us a classy graphic explaining exactly how this process would work:

dojo4's Project Compass, circa 2011

dojo4’s Project Compass, circa 2011

We usually dove into implementation as soon as a compass was written and pinned to the corkboard. For the minimum-viable-product startups dojo4 worked with, “implementation” was practically synonymous with “changing the compass”. But “implementation” also always meant “charging hard toward maximal features in minimal time”.

The little black “No” in the middle of the illustration above is what we envisioned happening if the project was discovered to be out of alignment with the compass. We’d look at stories and check them against the compass and change one or the other as necessary. But delivering code at breakneck pace to customers with rapidly changing goals was totally orthogonal to thoughtfully reviewing and making adjustments to paper-based project artifacts. So, our project compasses often went stale.

This is common in every kind of project everywhere. Sometimes it is a problem; sometimes not. When a project sponsor and all the project’s implementers have fantastic rapport and constant engagement, they can happily forget whatever they wrote in the brief three months ago. They’re grooving. But sometimes, the project sponsor and the implementers will carry divergent ideas of the project’s purpose all the way to launch day. I know at least a few people who’ve changed careers after pulling a week of all-nighters to deliver something that nobody wants.

That was precisely what the project compass was designed to help us avoid. But a corkboard full of stale project compasses didn’t help anything. Which is why the short form creative brief caught my eye. The document itself resembles the project compass — more verbose, still quite brief. But unlike the compass, the short form creative brief is imbued with longevity through a “weird ritual at the start of every meeting”:

One of the team members, always a different person, would read the exact same document out loud, word for word. The document, about three–quarters of a printed page, contained a tiny creative brief about the design they were working on. Reading it out loud was how they started every design meeting, whether it was a brainstorming meeting or a design review….[then] the project’s leader would turn to the group and ask the same question, “Everyone agree that this is what we’re working on today?”

Many times this exercise has no obvious impact: Everyone simply nods and the meeting moves forward. But occasionally, someone asks for clarification. They ask because they’re new to the project; or they ask because they’ve been assigned a task that doesn’t seem aligned; or they ask because they sponsored the project and no longer agree with something in the brief. When someone asks, the group discusses and updates the brief as needed.

Ritual is the perfect word for this exercise because the magic only happens if you do it religiously. You read the brief every time. You read the brief even when it feels silly to read the brief. Even — no, especially — when the meeting is about something urgent or tense. Because reading the brief puts the project’s critical facts right where they belong: At the forefront of everyone’s mind, in consensus terms freshly aligned with the effort actually underway, for the entire duration of the project.

I suspect the shape of the brief (or compass) is not nearly as important as its frequent review. Of course, it should contain enough information to explain why project participants keep meeting and working together, instead of playing pinball or hoarding shoes or visiting every county in Texas. That could be one terse sentence. The important thing is that the brief continues to explain where the group is headed, even if the group changes direction.

At Mozilla we use etherpad for planning meetings and taking notes during meetings. I have begun adding a “theme” to the top of etherpad agendas as a gentle way to remind people of the big reason we’re having yet another weekly meeting. For example, on Mozillians.org right now, the big reason we’re having yet another weekly meeting is to discuss the Curated Groups feature that we’ve been working on all quarter.

After reading up on the short form creative brief, I think I may take a moment at every meeting to speak our current theme out loud, too. Does everyone agree that this is our focus right now? Are there any questions about what it means?

Things Made In Times Past

I have a folder on my hard drive full of pictures and stories and songs I’ve made over the years. You might call them B-sides. I made most of them before self-publishing was so easy to do.

Most of these digital artifacts are just awful, not worth sharing at all, but some of them are mildly entertaining. However, practically nobody has ever seen them!

Well, I can fix that. Here is the first in a series of Things Made In Times Past. I present it here for your mild entertainment.


Jessicaaa

I was inspired and delighted by the blog Twitter: The Comic and thought I’d try my hand at it. I found a tweet that conjured up a series of images. I drew it in Adobe Illustrator.

sheboygan_scan

I submitted my drawing to the curator of Twitter: The Comic, but he wasn’t inclined to publish it. In addition to its glaring artistic flaws, it probably isn’t funny enough. It’s not a funny tweet, but it is remarkably evocative. In just a handful of words the tweet conveys an entire, haunting narrative. And the narrative is true: @sheboyganscan, the source of the tweet, is a running account of police scanner traffic in Sheboygan, Wisconsin. Where, apparently, this kind of thing happens:

Refactoring the Mozillians.org authorization scheme

One of the platforms I work on at Mozilla is Mozillians.org. Mozillians.org is Mozilla’s multi-constituent identity repository (or “phonebook”, as some prefer to call it). It is a simple profile-and-group management tool that serves data via a responsive UI and a read-only REST API. It houses about 4,000 user profiles: People who contribute to Mozilla in some way, whether staff or volunteer; people who consider themselves to be Mozillians.

Screen Shot 2013-10-14 at 2.34.07 PM

The post below is an analysis of Mozillians.org’s authorization system, which I believe is broken, and a rallying call to fix it.

Summary

Mozillians.org has become a mature platform and a valuable source of information about people who contribute to Mozilla’s products and mission, and it is likely to be important to Mozilla’s ambitious contributor goals over the next decade. But Mozillians.org has outgrown the authorization paradigms it started with. Therefore, in order to prevent data safety issues and questions about product integrity, we must design and implement an authorization system that accommodates current and future data and users. We should apply this system evenly to both the UI and the API.

Overview

Mozillians.org supports two classes of user account: unvouched and vouched. Anyone in the world can create a new account; that account will be unvouched, and it has very limited rights in the system (just a step above an anonymous browser). In order to be vouched, an unvouched user must find a vouched user who will vouch for them. In practice this means asking in IRC. Once a user is vouched, they have full permission to search and browse all Mozillians.org data and can also vouch other users.

Mozillians.org also supports two classes of API consumer: Mozilla Corporation and Community. Mozilla Corporation API consumers can access almost every attribute of most users and groups in the system. Community API consumers can only access the vouched/unvouched flag of a user whose email address is already known to the consumer. As initially conceived, accessing the API as a Mozilla Corporation consumer would require the requester to be paid staff and the URL of the consuming application to be a mozilla.org URL.

Problem

Vouching has lost much of its practical meaning, since we have no shared understanding or documentation of what vouched means or when vouching is appropriate. Some users are vouched immediately upon asking for it, while others must demonstrate some record of contribution. In practice, getting vouched is unevenly applied and poorly explained. Once vouched, accounts remain vouched forever. Mozillians.org’s current membership includes users who contribute daily or monthly; users who contributed in the past, but no longer contribute; and users who have never contributed beyond creating a Mozillians.org account.

Corporation/Community API authorization has lost much of its meaning, too. The criteria for being a Corporation consumer are not clearly stated in a policy document, and the data provided to Community consumers are not rich enough to meet the needs of most Community requesters. These factors combined encourage an ad-hoc approach to API authorization (for example, this bug).

While the erosion of meaning in our authorization paradigms has advanced, so have the quality of the data we solicit and the promises we make about its protection. In the past year we added numerous fields to user profiles, and we have plans to add more. We also added per-field privacy controls to profiles, a measure intended to give individual users more confidence about sharing private identifying data. These are definitely working well in the UI, but we have not yet applied per-field privacy controls to the content of API responses.

These are data safety and product integrity risks that we must address.

By granting easy access to the platform (either by vouching or granting Corporate API access), Mozillians.org exposes personal information that might not be shared if the actual exposure was clearly understood by users of the platform. We implicitly suggest that a trust network exists, but that network has an uneven (and low) barrier to entry; we implicitly suggest that API consumers will adhere to certain standards, but we do not strictly enforce these; and we explicitly declare that certain fields will be exposed to smaller groups, but we don’t yet apply these rules in the API. These are data safety and product integrity risks that we must address.

Solution

One obvious response to the problems described above is, “Stop vouching people who aren’t obvious contributors, and stop granting Corporate API access to Community API consumers!” But that response looks backward, not forward.

Mozillians.org has incredible potential as the single source of identity information across Mozilla’s varied constituencies — staff and non-staff, technical and non-technical, contributing daily or contributing just once, Foundation and Corporation. It is perfectly positioned to serve critical data about people to applications we haven’t even dreamed of. Look no further than the MozillaIndia Leaderboard (the subject of the bug linked above), which shows the most active bugzilla.mozilla.org contributors in India by mashing up bugzilla data with Mozillians.org data.

The ClawIt doesn’t take much imagination to realize that any number of contributor tools and outreach efforts will benefit from more Mozillians with richer profiles. From simple ad-hoc mailing lists to ad-hoc group-based authorization; from mashups like the MozillaIndia leaderboard to a unified Mozilla events system; from identity unification in bugzilla.mozilla.org to Dr. Claw, the Mozilla Schwag Bot©, which automatically sends t-shirts to contributors when they achieve certain badges; from 4,000 Mozillians to 1 million Mozillians: It all depends on more inclusion and more API access, not less.

It all depends on more inclusion and more API access, not less.

This blog post marks the start of the conversation. It is accompanied by a tracking bug in bugzilla.mozilla.org and a discussion thread on the developers mailing list. I’ve turned off comments here, but would love to hear other perspectives on the mailing list.

Ultimately, we may need to replace vouched/unvouched with something else, and we will certainly need to reconsider how API users authenticate and authorize to get API data from Mozillians.org. It’s going to be a fantastic technical and organizational challenge.

What an exciting time to be a Mozillian!

Update: In response to subsequent feedback on various channels, I proposed a framework for solving this, plus a concrete solution.


Appendix A:

If you are a Mozillians.org user and are concerned about the safety of your data, please don’t delete your account! You can take some simple steps to restrict access to your profile while we work through this bigger question:

  1. If you wish, you can change what applications (if any) can access your profile through the API. Look for the “Services” section in the Edit Profile view. But beware: Services like Badges.mozilla.org, Air.mozilla.org and others may require API access to function.
  2. While API users are not currently restricted by per-field privacy rules, UI users are. You can change fields to be visible to either Public (anonymous) or Mozillian (vouched) users.
  3. Very few fields are required. You can choose what you share. As Mozillians.org’s authorization scheme evolves, please consider sharing more information. Dr. Claw, The Mozilla Schwag Bot© won’t work without your t-shirt size and address!

Appendix B:

Dr. Claw, The Mozilla Schwag Bot© was conceived during the composition of this blog post for illustration purposes. Developers needed!

Baby Sleeper Plans

bottomI promised last year to post the plans that I made when I built the baby sleeper that our baby slept on for the first six months of her life. Here they are! I made them in SketchUp, but WordPress.com doesn’t allow me to attach .skp files here so I’ve attached pictures instead.

This baby sleeper is designed to satisfy a handful of important requirements:

  1. It should fit commercially-available baby mattresses. We found a great organic mattress here sized 15″ x 35″, so that’s the size of this sleeper’s platform.
  2. It must prevent the baby from rolling off the sleeper onto the floor. So it has high walls on 3 sides.
  3. It should put the baby at the same height as her parents — the top of her mattress should be even with the top of the adult mattress.
  4. It must keep the baby mattress and the adult mattress right next to each other, touching. Any gap between the mattresses can be quite dangerous!

Adult beds come in all sizes and designs. We have a platform bed, and these plans are for our bed. Unless you have the exact bed we have, you will probably  need to modify this design. If your bed has a nice fat lip next to the mattress, one edge of the sleeper can rest on the lip. If your bed has a box spring, you will probably want to incorporate some flat slats of wood to go between your mattress and your box spring to help support the sleeper on the front. On the rear are legs that rest on the floor.

Construction details:

  • I made the entire sleeper box, platform and walls from scrap plywood. Every joint is glued. I used assorted deck screws from a pile on my workbench to pull the joints tight.
  • I made the legs from electrical conduit with a conduit socket threaded into a plumbing fixture attaching the legs to the the sleeper (see picture above). I wrapped the bottoms of the legs with an old bike tube to protect the floor. I added some felt pads to the front supporting edge, which sits on the lip of the platform bed.
  • I sanded the sleeper very smooth first with sandpaper and then with steel wool. I filled in big gaps with wood patch. I finished the sleeper with several coats of a tung oil finish, well rubbed. I let the finished sleeper off-gas in the sun and wind for several weeks.
  • In the photo above you will see some holes I drilled in the bottom of the sleeper: These are for stout rope which I used to tightly bind the sleeper to the lip of our platform bed. The photo below shows how tight a fit it was.

attached to bed

Here are some general instructions that may help adapt these plans to another bed:

  1. Measure from the floor to the top of your mattress. In our case it was 15 7/8″.
  2. Subtract from that measurement the height of the baby mattress you bought (for us it was 1 1/2″). The resulting number is the height that the platform must be off the ground. In our case it was 14 3/8″.
  3. Measure from the lip of your bed, or from the top of the box spring, to the top of your mattress.
  4. Subtract from that measurement the height of the baby mattress you bought. The resulting number is the distance between the platform and the bottom of your front edge support. The front edge support is either the box that rests on the lip of your bed, or the slats that slide between your mattress and your box spring. In the drawings below this is 4″ plus the thickness of the platform board (5/8″) and the thickness of the board at the bottom of the box (5/8″), or 5 1/4″.
  5. Measure from your front edge support (the lip of your bed or the top of your box spring) to the ground. The resulting number is the height that your sleeper’s legs will be, minus the thickness of any supporting materials. In our case the legs were 8 1/2″ after I subtracted the thickness of the extra support plank running along the rear edge.

This sleeper was a great way to keep our baby very close at night without putting her in bed with us.

Our baby enjoyed the baby sleeper that I built from these plans, but I cannot guarantee that you or your baby will. By viewing these plans you agree to accept all responsibility for any outcome resulting from your use of them; you agree that your family’s well-being is entirely beyond the control of any party involved in the creation or publication of these plans and instructions; you signal your understanding that these plans are provided here as-is with no warranty and are shared under a Creative Commons BY-SA 3.0 license. If you cannot agree to these terms and you want a great baby sleeper, buy one.

plan-sideplan-front

Woodwork: A baby bunk.

In my free time (which has increased some, but not as much as you might imagine), I am building baby furniture. Here I am sanding some birch-veneer plywood that is part of the co-sleeper I built.

One can order co-sleepers online. In the U.S. one company has a real monopoly on these, and I hear they’ve even trademarked the term “Co-Sleeper”. Unfortunately, their products don’t have much visual appeal. To me they resemble the kind of cheap desks you might buy at a big-box office supply store or maybe a TV table from Target.

Across the pond you can order beautiful co-sleepers: modern, sleek, minimal. Maybe some Scandinavian design, no plastic casters. But their price is in British Pounds or Euros, which means they cost about 2x what we would pay here for a similar item. And they must be shipped at great expense.

There are a handful of nice looking products made in the U.S. (or at least sold by U.S. companies. Here’s a nice looking one. And these folks are definitely the real deal.

But after reviewing all the options, I decided that I could build a co-sleeper and would enjoy doing so. This is a nice way to get into woodworking. Babies don’t put a lot of load on furniture, and this is a simple object to make. Also, it’s an opportunity to experiment with wood finishes — if the finish doesn’t turn out perfectly, no big deal. And finally, I saved enough money doing it myself to buy the table saw I need to do it.

(The latter trade reminds me of a coding adage I’ve learned over the years: Invest heavily in the framework you use to build things so you can build more things.)

All of the materials — screws, wood finishes, and planks — are scavenged from earlier projects, so the entire project cost is the table saw and my time. And as far as my time is concerned, I consider it practically recreation to spend an afternoon in late September sanding and cutting in the back yard. The leaves are turning, the sky is blue, the sunlight is warm and golden, the shade is cool.

Here are more images and my SketchUp plans for this baby sleeper.