Being a decision maker - Part Two

In my last post I was exercising my search engine choice for kicks.  Choosing a search engine is easy,  you type in the URL and get directed to the home page of your favourite search engine's site.  If you prefer one and want it to be your default search engine,  Firefox has a handy pull down menu where you can manage your search engines and set your engine of choice.

This is just one of the many ways that Firefox, and Mozilla, promote choice. Another way we do it is by providing the world's best browser in over 70 languages, and on multiple platforms.  We give users the choice of a browser that is built with them in mind.  For security, accessibility, and extensibility users can count on Mozilla's Firefox to be doing its best to improve the areas that make the open web work.

The Microsoft Browser Ballot screen has started to roll out this week and there are people who are most likely not expecting, nor informed about what it means to make a choice as it relates to the web browser.  It's important that we not forget that many people don't know what a web browser is.

I recently posted about how I suspect the design of the ballot screen will scare away people before they even get a chance to make a choice.  For those that make it to the second screen (where you are presented with the 5 top browsers by market share) there is another obstacle: lack of information.  The screen doesn't tell you why choosing your browser is important.  It doesn't tell you which browsers are more secure, which ones work with screen readers, which ones can be extended to add custom functionality.  These are important factors in making a choice.  Otherwise "choice" is really "pick the pretty logo and see what happens".  Or perhaps "choice" is "stay with what you know, cause change is scary".

Which web browser you use may seem trivial thing at first but when you look under the hood - it matters that your know the browser you choose will work with your assistive technology. It matters that your identity is safe, that a site's legitimacy is explorable before you make an online purchase, and that you can customize your web browser to maximize your efficiency.  I've had several academics tell me they rely on Firefox add-ons to help them cite, bookmark, and make notes in the browser as they prepare class materials.  Your browser can make viewing the web a comfortable, seamless, and efficient experience.  Don't you want to have the information to help you make the choice that's best for you?

I hope that John Lily's letter,  and other blog posts in the coming weeks will reach a wide audience and help supplement the lack of information that the ballot screen contains. Just as it would be odd to let a stranger pick your car out for you - with no information about your driving habits, family size, gas budget, style preferences - you should try as much as possible to make an informed choice about the tools you use on your computer to do your work and live your digital life.

It really does matter. Have fun exploring your options.

Being a decision maker - Part One

While helping a friend with a wordpress site, I googled for image gallery plugins and was met with:

I've never seen this before so of course I started to search for the site in other search engines:

Interesting, kind of suggests that this site also uses Yahoo.  That's impossible. Now how about Alta Vista, Dogpile, Lycos, and Ask.com?

 

Nope, no special greeting.  I saved the "best" for last, Microsoft's Bing:

Ok, wait a minute.  Decision maker?  Why is everything else just a friendly greeting? Decision maker makes it sound like I've done something radical by using Bing.  I'd love to know if Technically Personal is generating this box or if it's coming from somewhere else.

Browser Choice Screen slight of hand?

Just reading over Microsoft's "What to Expect" post about the upcoming browser choice ballot. I tried to imagine I was a windows user seeing this for the first time.

Two things about this screen bother me right away. One is that the "Ok" is just a link, not the usual, and obvious call-to-action BUTTON. It's also on the left and I usually look to the right (or center) for things like "OK", "Next", "Continue", or "Agree" type action buttons. I notice that on the next screen (the actual choice screen) "Select Later" is also on the left so maybe it's just my own habits and not a mind-game Microsoft is playing with me.

Second, they 'unpin' IE from your task bar and then the last line of screen 1 is "Before proceeding, please confirm that you are connected to the internet." If I didn't know for sure that I was connected to the internet, I'd probably want to open IE to check. I find this user experience confusing and wonder how much work Microsoft's team did in trying to make it intentionally so. The scenario I picture is my friend's mom Janice. Janice still saves web pages to her desktop instead of bookmarking them so I don't think she's the majority use case here, but I thought of her anyway. I think she would fairly represent a certain group of computer users that are competent at doing daily tasks on their machines but are nervous about making changes to their systems.

I imagine that Janice sees this screen and has no idea about the ballot's history so she takes the time to read the first screen. What? Features? What is a feature for a browser? I connect to the internet with IE, what features do I need? You've unpinned my shortcut to IE? Where do I go to open it now? I need to be connected to the internet? How can I check that? How do I open IE now that you've taken away my shortcut? Janice clicks on the "here" link to find out how to re-pin IE to the taskbar and who knows what happens next (Microsoft's post doesn't show this) but I suspect that browser choice is put aside and this screen will not be run again.

What has Janice learned about browsers, choice, security, compliance, open standards? Nothing. She unfortunately is now maybe more afraid of running a Windows update than before, and life goes on.

Anyway, it's just one scenario that came to mind. I know we're going to see some really interesting stories, comments, and choices being made as this ballot reaches more and more people. I'm looking forward to watching this all go down.

FOSDEM 2010 Video - Women in Open Source and Free Software

Click to Play

A quick 'n dirty vlog featuring some of the women attending this year's FOSDEM conference. I was really glad to see so many women attendees, a much higher ratio than any FLOSS events I've been to so far. It was challenging for me to get over my initial shyness about talking with them but I'm glad I did. As my friend Bevin has said "No one ever died of awkward". That in mind, I just put myself out there on the Sunday of FOSDEM and was pleasantly surprised to discover how eager women were to talk about their involvement. I hope to continue to do this kind of documenting at future events. I'd also encourage you, dear reader, to do the same if you can. We can compile a ton of testimonies from women in open source and free software describing what they do and why.

FOSDEM 2010 Reflections - Part One: Why I went

This was my first time attending FOSDEM and my first time in Europe as an adult. Being able to attend this conference was very exciting because I got a whole new perspective on the Mozilla project's community outside of North America and I met many folks in the l10n community which helps remind me that there are people attached to the RelEng Buildbot columns. In my time at Seneca, my internship, and now as a full time employee of Mozilla I mostly interact with employees and contractors so it's really great to be around folks who aren't paid to do this and yet love it as much as I do.

It wasn't until the second day of the conference that it really started to sink in how the driving forces of community were very different across the ocean. People I met told me how they were involved with open source for political reasons, and one pointed out that he could watch TV or do something that mattered, so for him contributing to Mozilla was a way of doing something important. If more people in America put down the remote (or game controller) and followed suit, imagine how many new contributors we could have! I loved hearing that for some of our European contributors, their time spent on Mozilla projects isn't volunteerism; it is essential to their daily lives.

I suspect that coming from countries that have at some point been governed by autocratic or dictatorial leaders has spurred many free-thinking people to want to personally work on openness and freedom in many areas, but especially in areas relating to technology, where web browsers become an important tool for managing identity and privacy. It's activism, it's political, and it's one of the reasons I'm here too.

My early roots of activism looked a lot more like this:




Invigorating but prone to burnout. Being crushed up against riot shields and poked with billy sticks loses its appeal fast especially when police crowd control tactics get more and more violent with every protest. So now my activism is more about finding positive, measurable, and constructive ways to help people. Hopefully free of riot gear and pepper spray.

Enter WoMoz. For folks who don't know, WoMoz is a new group in Mozilla aimed at increasing the visibility of women at Mozilla as well as increasing the number of women contributors. The main reason I attended FOSDEM was to participate in two days of planning sessions with other WoMoz members in order to lay a road map for the rest of this year. Up until now the WoMoz participants have only interacted through IRC, wiki, and mailing lists. It's nearly impossible to get a decent big picture that way, let alone get to know each other.

In the next couple of blog posts I'm going to write up my thoughts and ideas about directions that WoMoz can take and my goals for this project. I'll also post a quick 'n dirty video I've made featuring some of the women in open source that I met at FOSDEM.

So you want a new Talos suite, eh?

This quarter Alice and I have focused on trimming the list of pending test suites and where several new ones (419776, 524089, 515540, 506772) have been turned on in production.

The process for getting a new suite in has becoming a lot clearer, so we gave a presentation at the recent all-hands to help the developer know what to do on their end and what RelEng can do for them once their test suite is ready for staging.

Here's what a developer needs to do:

• Download and install Standalone Talos to test their suite in
  
• Once they have established that the test works on at least one platform, write a patch against talos in cvs
  
• File a bug against RelEng in the General component and provide the following information:
  
  • Contact person who will work with us on getting the test suite enabled
    
  • What the test does, what the expected output should be, long name, short description
  • Which branches and platforms you want the test run on

RelEng will create the buildbot patches that enable the tests, insert the tests into graph server, and work with the contact person while the tests are in staging to make sure the expected outcome is reached. Once the tests run as expected we can turn them on in production. Perfect world turnaround for this process is about a week and a half and involves a short Talos downtime. The rest of the time allotted to our presentation was spent discussing where we should be setting our sights for Talos improvements. This looks to involve two relatively large undertakings:

1. While it recently underwent some much needed improvements, the graph server still needs to be faster, more stable, scalable, and able to handle our ever-growing data sets. The blocker here is that no one really owns graph server and it's hard to know who should.
2. Talos is barely holding up under the current load of tests, hardware, and infrastructure. It also works in such a way that a lot of manual involvement is required to add new tests. It would be awesome for it to work more like unittests where once individual tests are checked in, they would go into production immediately. It would then be possible for a developer to not only write a unittest for any bug fix, but also a performance test to go along with it.

Now this brings up the problem of what performance we want to measure and how we want to approach performance metrics in the long run. Alice made a great point when she stated that folks who are not trained and accustomed to doing QA might be challenged by trying to generate tests that actually create a good metric for the performance they wish to be testing. It's entirely possible to have tests that seem interesting on the surface, when you drill down, don't provide any useful data for actually improving anything.

Do we want per-bug performance tests as we do with unittests? While it looks like this is a way to make a developer more accountable for their code, it's pretty obvious that this model wouldn't scale well at all with our current hardware and turnaround expectancy. Imagine as many individual pageload tests as there are mochitests...I suspect no one wants to see that.

Performance testing would be better and more useful if it was targeted at specific features or areas of the product where someone is actually tracking the improvement/regression ranges on them as they are developed. That's a key area of Talos - that a human is actually accessing the data, finding it useful, and making improvements on their feature/area as a result of this information.

While brainstorming with Aki on the potential of the graph server data, one idea really got me excited. Open up the data.

There's been a lot of hype lately about opening up data. In February of this year Tim Berners-Lee encouraged us to start thinking about open, linked data and how it could be the next round in how the Web helps us re-frame our world. In Canada the city of Vancouver opened up its data in the hopes of "improving liveability and governance" in the Metro area.

What if the Talos graph data was made available to the community and a challenge was created in the spirit of the marketing design challenges where we ask people to help us find new ways to view the data? I'd be really curious to see what kind of visualizations would come out of the larger community. RelEng doesn't have a very large community outside of employees, so this could be a great way to start working on creating one.

Upcoming improvements to Talos documentation and test suite creation

This quarter I'm going to be joining Alice in trying to improve the system for adding new suites to Talos.  The current system involves a lot of hackery on our side and slows down the ability for us to get Talos suites up and running as quickly as might be desired.

So with John's help to create a prioritized list of suite requests, we will be doing a lot of communicating with developers in the coming months to get them up and to improve the process and documentation at the same time.  Currently there are 10 new suite requests waiting that are known and there may be others.  

Part of the issue with adding new suites is that there is a lack of documentation and tools for developers.  Our new system will look more like this:

* A request is made for a new suite and a developer is attached to the request who will be the lead person for working with us to get the suite into production

* The dev will be able to use tools we provide (standalone talos, corral of staging-talos slaves) to do proof of concept on the suite so that it works and is ready to go up in staging when it's handed over to RelEng

* RelEng will enable the test suite in staging and verify that changes in staging work fine with the other existing jobs being run on the same machines. Once all is well, then rollout to production would happen

As we progress through the suite requests, this process should get easier for all parties and more streamlined.  We hope that by the time we reach suite #10 it will be much easier and faster for developers and RelEng to get the proposed new Talos suites into production.

I mentioned the developers will have tools provided by us. We need to do a bit of work to make these tools usable by developers and the first place to start is with our documentation of what Talos is and how it works.  Following this we will have discussed having boilerplate code for creating each of the two styles of tests startup or pageload.  Also, it might be beneficial to have a coral of Talos machines that can be loaned out to a dev for a limited time in order to test a suite during creation and debugging.  This coral could then be re-imaged and passed along to the next suite developer.

Here is the current documentation page.  Doesn't give you much to go on, right?

Well this is about to change.  Given my complete lack of Talos knowledge, I will be writing up what I learn about Talos as it's happening so that hopefully a more complete set of docs will exist for the Talos neophyte and folks who want to work with us to add new suites will benefit from this as well.

Here's the current list of the docs to be created based on what we think you might want to know:

* How Talos works and an overview of the development from past to present

* What preferences Talos runs with

* A description of each test suite, what each runs

* What the numbers mean

These are the things I don't know - is there anything you don't see listed here that you want to know more about?  Feel free to make suggestions in the comments.