Meet the New Test Pilot

Effective immediately, we've renamed the Idea Town program to Test Pilot.

The original Test Pilot was an opt-in "labs" project around measuring what people actually did with the browser in small experiments, but hasn't been used in over a year and has no future plans. We'll be using the name and some of the assets to accelerate our original Idea Town plans.

At first glance the two projects appear similar but have key differences. I originally wrote a list to clarify what the new Test Pilot program was but decided it would be most useful if everyone could see it. Below is a rough description of the new Test Pilot.

  • Test Pilot is an evolving set of stepping stones for getting an idea from a concept stage to landing in Firefox itself in an expedient way, being measured and verified along that path.
  • Test Pilot is not a prototyping team.
  • Test Pilot team members are amplifiers of people participating in the program. When a person or group submits an idea to Test Pilot they are starting a process in which they should expect to be involved until a conclusion is reached.
  • Test Pilot team members help participants progress through the Test Pilot process in whichever ways are needed - from boiling an idea down to get at a measurable core concept, documenting an idea thoroughly, iterating on designs and prototypes, assisting with coding, communicating with appropriate teams around Mozilla, and helping uplift a successful idea to its next stage in life. An analogy could be made between Test Pilot team members and consultants.
  • Test Pilot's intention is to facilitate providing decision-makers with quality, focused data in a short period of time.
  • Test Pilot works very closely with the Mozilla community (including paid staff).

I'm working on our migration plan but the Test Pilot wiki page is up and contains links to getting involved and staying up to date on further changes.

Long live Test Pilot. Again.

Next Stop: Idea Town

This is just a quick post to highlight some logistical changes:

After nearly a decade of working on AMO I'm passing the module ownership and engineering management to the very capable Andy McKay, who has also been working on it for many years. With this transition, I think, it's the first time that the AMO website and the add-ons support in the platform are all reporting to the same manager. I expect this will mean a much more streamlined experience and I'm happy to see the add-ons program is getting a lot of organizational support in 2016.

At the same time, I'm also passing my engineering responsibilities on the Firefox Marketplace to David Durst, and, let's be fair, he's been doing them all for a long time anyway. David will continue supporting the Marketplace for the TVs which just launched this month, as well as wherever the new connected devices program takes Mozilla.

I'll be transitioning to the Idea Town team as the engineering manager, working closely with the Firefox team and the community to get ideas from concepts to landing in the browser in record time. Look for more info on what that means soon!

Thanks for your support while we all transition.

Enabling Encryption in Weechat

Here are some step by step instructions for enabling encryption using crypt.py in weechat.

First, ensure the crypt.py script is installed. The easiest way is from within weechat itself:

/plugin load script
/script install crypt.py
/script autoload crypt.py

You should see some simple messages saying crypt.py was installed and enabled for automatic loading.

Next you need to generate an encryption key. This just needs to be named with the channel you want to use the key with (I use #channel below). For example:

cd .weechat
openssl genrsa -out cryptkey.#channel 4096

We might as well make sure only we can read it:

chmod 600 cryptkey.#channel

At this point typing any text in #channel will automatically be encrypted (use a second client if you'd like to verify it). For example, I typed:

1811 clouserw │ testo

And the other clients in #channel see:

1811 clouserw | +qRy3GsV2sPRlJSdP1IqqV|

The next step is to distribute the key to the other people who will need to decrypt the chat. Take a minute to consider the best way to do this as the chat will only be as secure as this key.

Lastly, you can optionally add an indicator to the status bar by adding 'encrypted' to weechat.bar.status.items. This command will tell you your current value:

/set weechat.bar.status.items

Copy that value and add 'encrypted' where you'd like it to show up. Mine is:

/set weechat.bar.status.items "[time],[buffer_count],[buffer_plugin],buffer_number+:+buffer_name+{buffer_nicklist_count}+buffer_filter,encryption,[lag],[hotlist],completion,scroll"

which looks like this:

[18:16] [32] [irc/freenode] 30:#channel{3}⚑ (encrypted)  [H: 3, 4]

That's all there is too it!

Marketplace and Payments Systems Diagrams

A couple years ago Krupa filled up a whiteboard with boxes and arrows, diagramming what the AMO systems looked like. There was recently interest in reviving that diagram and seeing what the Marketplace systems would look like in the same style so I sat down and drew the diagrams below, one for the Marketplace and one for Payments.

Marketplace:

Payments:

Honestly, I appreciate the view, but I wince at first glance because of all the duplication. It's supposed to be "services from the perspective of a single service." Meaning, if the box is red, anything connected to it is what that box talks to. Since the webheads talk to nearly everything it made sense to put them in the middle, and the dotted lines simply connect duplicate services. I'm unsure whether that's intuitive though, or if it would be easier to understand if I simply had a single node for each service and drew lines all over the diagram. I might try that next time, unless someone gives me a different idea. :)

Lastly, this is the diagram that came out first when I was trying to draw the two above. It breaks the Marketplace down into layers which I like because we emphasize being API driven frequently, but I'm not sure the significant vertical alignment is clear unless you're already familiar with the project. I think finding a way to use color here would be helpful - maybe as a background for each "column."

Or maybe I'm being too hard on the diagrams. What would you change? Are there other areas you'd like to see drawn out or maybe this same area but through a different lens?

Goodwill Updates - A Firefox OS Feature Idea

A common aspect amongst the regions Firefox OS targets is a lack of dependable bandwidth. Mobile data (if available) can be slow and expensive, wi-fi connections are rare, and in-home internet completely absent. With the lack of regular or affordable connectivity, it’s easy for people to ignore device and app updates and instead opt to focus on downloading their content.

In the current model, Firefox OS daily pings for system and app updates and downloads the updates when available. Once the update has been installed, the download is deleted from the device storage.

What if there was an alternative way to handle these numerous updates? Rather than delete the downloads, they are saved on the device. Instead of each Firefox OS device being required to download updates, the updates could be shared with other Firefox OS devices. This Goodwill Update would make it easier for people to get new features and important security fixes without having to rely on internet connectivity.

a concept drawing

Goodwill Update could either run in the background (assuming there is disk space and battery life) or could be more user-facing presenting people with notifications about the presence of updates or even showing how much money has been saved by avoiding bandwidth charges. Perhaps they could even offer to buy Bob a beer!

Would this be worth doing to help emerging markets stay up to date?

PS. Hat tip to Katie and Tiffanie for the image and idea help.