My Progressive Benefits Dream for Mozilla

Recently I was approached by a co-worker to add my name to a petition about restoring the parental leave for Mozilla’s US employees.  At some point between 2009 and 2012 our leave plan changed without there being (to my knowledge) any formal announcement, transparency around the decision, or discussion of the impending change with employees.

As I was crafting my response to the request I thought this would be a good blog post since it states quite clearly what I hope Mozilla could strive for as a company with regards to how it provides benefits to employees.

Thanks for including me in this thread.  I’ve given it some thought and I’m seeing two very distinct issues here:

1) That Mozilla cut a policy without explanation, it looks to be by accident, and I agree completely that the old policy should be restored until a new one is put in effect with intention (and hopefully transparency)

2) That Mozilla needs a competitive and progressive leave policy going forward – this is something I am happy to help champion with adjustment to the current parent-focused language

I have recently been working on improving our benefits from another angle – trying to get our benefits to explicitly cover transgender surgeries – and I see the issue of being able to take paid leave as being very helpful to that ask.  Right off the bat, I wouldn’t want to support having gender-distinct parental leave durations, as this creates a problem for families who do not follow heterosexual patterns (eg: a man or men adopting a child gets less leave than a man/woman or woman/woman or even a single woman).  However, I would encourage us to think bigger and propose that paid leave should be a benefit available not only to parents.

If we really want to support diversity, I recommend we ask for (and get a lot of people on board with) a leave benefit that can be used to care for an elder, undergo surgery, adopt/birth/foster a child, write a book, pursue education, renovate a home, or anything that requires undivided focus away from work and enriches your life.  Imagine if your benefits at Mozilla allowed you 8 weeks (happy to shoot for more) of paid leave and the reason was up to your discretion.  What a measure of excellence we could have above current plans offered by other companies by recognizing a wide range of life-altering events that demand our attention.

Pushing our company to be more appealing to, and welcoming of, women and other marginalized groups is incredibly important to me and I want to see us grow our benefits and company culture in ways that encompasses more diversity. We should appeal not only to women for whom maternity leave is a priority, but also to women whose lives follow other paths, and show that Mozilla cares about the overall health and growth of all their employees with flexible plans that benefit the widest possible groupings of people.

For the short term I’m happy to put my name on this request to reinstate the plan that was never publicly revoked and call out the poor process there (lack of transparency and no announcement of potential change, no input from employees) but I also appeal to you and to others who participate in this request to consider joining forces with me (and some others who put in the request for transgender surgery) to draft a request for 2014 to create a Personal Leave policy and provide a benefit that enhances the well-being of all employees at Mozilla.

That’s the long and short of it.  I want us to be willing to discuss and consider our benefits in ways that do not single out certain choices or circumstances over others.  It may be how 3rd party brokers and the benefit providing companies create markets for their wares (reminds me of pink/blue toy marketing) but if we want to really have an ‘enviable’ culture and we truly value diversity in our recruiting efforts we should think outside of the boxes that have been created for us by the profit-driven insurance sector.

Creating a Mozilla workshop for beginner Hacking of Mobile HTML5 Games

Participants in the Mozilla Hacking HTML5 Mobile Games workshop at the 2013 Dare 2B Digital conference.

Dare 2B Digital is an annual South Bay conference that brings 300 young women ages 12-16 together to encourage them to consider STEM fields in college by coming together for a full day of inspiring talks and workshops showcasing women’s work and relevance in technology.  For the past three conferences I have signed Mozilla up as a sponsor and created a workshop that is run 3 times that day and reaches about 80-100 attendees.  Last year I created kits for participants to learn about soft circuit hacking and lighting up felt foxes, the year before I taught Universal Subtitles and Popcorn before it was even a 1.0 product yet. I’m always trying to keep our workshops current and, if possible, on the bleeding edge of whatever Mozilla is working on. The participants get a taste of one exciting aspect of what is happening RIGHT NOW in open technology.

In the past year I’ve been really inspired by Mozilla’s outreach around web literacy and at the same time there’s been all this work done around our upcoming Firefox OS for mobile devices that will allow apps to be built entirely of the web and installed/sold/shared outside of the silo-structures such as Apple’s App Store and Google Play.  At MozCamp Asia in November of 2012 I watched the Mozilla Taiwan reps showcase a fairly simple card matching game they had made of browser icons and they turned it into a Firefox OS installable app in only a couple of hours.  All of these snippets and ideas led to my proposed workshop for the girls being about hacking their own version of the browser-pairs game and installing/playing it on a Firefox OS device.

Now this was all before the Firefox OS phones even existed, and it was also before I went away on a 3 week vacation to Vietnam over the holidays.  I mentioned it to my co-worker Margaret before leaving and she said she’d be up for working on it with me but when I returned from vacation I lost about a week just on jetlag & minor flu-like symptoms then another on my birthday and having my family in from out of town.  Next thing I knew it was February 1st, the workshop was on February 9th, and I had NOTHING ready and there was no public Firefox OS device yet, either.

So I called up Ruth who organizes the conference and tried to beg off this year.  Would it be so bad if Mozilla didn’t do a workshop this one time?  Thankfully Ruth very calmly returned my panicked email with a phone call and asked me what I needed to get this workshop on track.  What did I need? Mostly just to buck up and finish what I started, me with my big mouth. The pieces were all out there.  I had code (thank you Mozilla Taiwan!), Chris Heilmann had recently posted some inspiring slides about HTML5 and mobile for Firefox OS App Days, and Hackasaurus has plenty of youth-focused resources.

Hastily, I organized a couple of lunch time meetings during the week leading up to the workshop with Margaret and we hashed out who would do what.  We made an exciting discovery in our first meeting, which was that we could host the game from a github page and this meant every girl in the workshop could hack on her own customizations of the game in github’s web interface code editor and see their changes reflected on a mobile device immediately.  No need to deal with the minutia of web hosting, no server-side code, and minimal development setup – the freshly imaged laptops we borrowed from Mozilla IT would be good to go in minutes!

I drove to Redwood City on the day of the conference with: 20 laptops, 15 Firefox OS test driver devices (thanks to my co-workers who let me borrow their phones!), and some slides about why hacking HTML5 is the future of mobile apps. One thing we realized as we were setting up was that there would be some delay between when the participants created their GitHub accounts and when they would see their github pages live with our demo code.  We ended up front-loading that and having them start right away as they arrived at the top of each time slot then going into the presentation after they had forked the repo which had the gh-pages branch set to default.  We later learned (through Margaret’s chatting with GitHub support) that it was likely the delay could be caused by not having edited anything yet on the gh-pages branch so in later workshops we had the girls follow along with Margaret and change the <title> of their index.html and commit the change.

Getting paired up, creating GitHub accounts and FORKING!

The presentation portion was about 10-15 minutes and started out with asking the girls to shout out what comes to mind when I say the word “HACK”.  Answers included “death row” and things along the lines of breaking or sneaking into someone’s computer, mostly things associated with dark or criminal activities.  A few did mention things like ‘nerd’ or ‘creative’ too.  When I showed them my examples for the talk we had a brief discussion about not asking for permission, being curious, creative, and taking ownership. After that we talked about Apple/iPhone and Google/Android.  Most of the girls had one or the other we explored how non-interchangeable they are, how much it might cost to be a developer for one or the other, the need to play by someone else’s rules in order to get your ideas out there.  My favourite part of this talk is repeating over and over how using open web technologies and the web itself is all about NOT ASKING PERMISSION.  You put your stuff up, tell people where it is, and they can go use it.  It can (and should) be that easy.

After the talking was done the young women had about 45 minutes to hack on their github sandboxes and test out making customizations to their matching game. We modeled it after Mozilla’s Thimble project which uses comments in the code to explain various areas of the code and gives ideas on what to change. Our take was to suggest they try (in increasing levels of difficulty):

  1. changing the background color/images (of the page, game box, card backs)
  2. changing the images on the cards when flipped
  3. change the music (few got to this part in the allotted time)

We saved 15 minutes at the end to do demos of what people did to their code and to come up and tell us what they did to achieve their end results.  Some of the customizations led to a newly themed game like pigs, magic, twilight, book covers, and other things the designers liked. A few girls went further and took snapshots of themselves on the laptop camera and used their own action shots in the match game, one girl had her own laptop and drawing tablet so she drew her own card faces and intro screen background, and another girl removed the card backs to make it look like the game box was all black – when I started to click during her demo and cards flipped I was surprised since I had thought the game was broken but she laughed and said it was on purpose.  It’s hilarious to me that she made a simple match game into a much harder challenge by hiding the discover-ability of the game.

LOTS of hacking going on here. Margaret and Larissa help out with question.

All in all the three workshops went smoothly, everyone got to do some hacking and see their results during the time we had allotted, and all the girls left with a new github account and code they can keep hacking and learning on over time.  During the course of the workshop we went around helping and answering questions and taught them about commit history, rolling back changes, and also using “Inspect Element” to figure out where to look in the code to make changes.  I should mention that at the beginning of every workshop I asked “Who here has touched HTML/CSS before?” and there were never more than half the hands in the room raised.  This comes up every year in the workshops I run. Some girls are getting this knowledge from parents, friends, self-teaching, and now things like CoderDojo (as one participant bragged) but there’s no indication that any of them are learning this in school where they spend a majority of their time. The thought that some girls are being left behind on this is sad to me, and I want to do all I can to help change that. Every single one of these young women left our workshop with a new spark in their eyes having now had first-hand experience with the power of creating web apps that can run on ANY WEB-ENABLED DEVICE. It was powerful to see.

So many new hackers of open source, mobile games.

So, what’s next?  I think this workshop should become another Webmaker and/or Hackasaurus project that can be taught anywhere, to anyone who wants to have a first-time experience with mobile app development.  We’re 80% of the way there, I’d say what’s left to do is:

* Code clean up (especially CSS) so that everything in the repo is clearly marked for its purpose and with comments on how to mess around with it. Specifically comments in the Javascript and exploration of that code – we didn’t touch this at all in our 1:15 hr workshops.

* Spend a bit more time, if you have it on basic HTML/CSS editing, using Inspect Element, and having cheat sheets printed up for participants.

* Have options for what to do next – getting off of github pages and hosting your own app, possibly with some server-side code.

It won’t take much to turn this into something more generic and useful for introducing people to the power of Firefox OS and HTML5 app creation and I look forward to continuing to develop this sort of material whenever I can. Thanks to the Desktop Support staff who prepped laptops for the conference, SF co-workers who lent their phones, and most of all to my coworkers who lent their time and their expertise: Margaret, Larissa, and Amy*.  Without all of you this would not have gone smoothly and because of you it was the best day of 2013 so far.

 

* At lunch we had a little Q&A with the 30 or so girls from the first workshop. They got to ask all of us questions about what we do and how we got there.  The four of us had such different paths & connections to technology. I love that we got to show these young women a variety of ways to engage with tech and to be in open source.

Release Management gets an Intern!

Thanks to the GNOME Outreach Program for Women, we’ve got ourselves an awesome January intern who will be doing her first Open Source contributions all the way from Australia.

Lianne Lee stood out as the strongest of several applicants to the Release Metrics Dashboard, which was one of the two Mozilla projects that Selena Deckelmann and I threw together in order to try and lure people to our devious schemes for moar metrics. Lianne’s application was thorough and used all the technologies I wanted our intern to have familiarity with (python, git, javascript, creating data visualizations)

Firefox 17 triage over 6 weeks

She did a great job of showing one of the things release managers do over the six weeks a Firefox version is in Beta. The spikes in the above graph align with our constant triaging of tracking-firefox17? flags and how the number of bugs flagged for tracking decreases after the first few betas have shipped. When we get to beta 4 we’re starting to get more reserved about what we’re willing to track (it usually has to be pretty critical, or a low-risk fix to a many-user-facing issue).

Firefox 17 Tracked Bugs

This next graph shows us what we already know – but it’s very nice to SEE: our bugs tracked for a particular release continually go down over time, gradually.  Remember, this is while new bugs are being added to tracking regularly, so the fact that the trend keeps going down helps us know we are staying on top of our work and that engineers are continuing to fix tracked bugs as we close in on a 6 week ship date.

Now that we know Lianne has got what it takes, we’re going to set her on a more ambitious project – to create an engineering dashboard both for individuals and for teams, that would give them this sort of info on demand.  Want to see where you’re at (or where your team is at) on a particular version?  The engineering dashboard could show you in priority sequence what should be top on your list and also what bugs your team has unassigned that are tracked and should be assigned pronto (or communicate to RelMan that the bug should not be tracked).

This will be a huge improvement over email nagging (don’t worry, that’s still going to be around for many more months) because it will give us some quick, visual cues about how we’re doing with Firefox priorities and then we can also keep these measurements over time to compare release-to-release what the temperature of a particular version was. We hope this will allow us to keep fine tuning and working towards more stable beta cycles as we move forward.

Lianne will be with us from January 2 to April 2, 2013 and in her first week she’ll be evaluating a bunch of existing dashboards we know about to see what the pros and cons of each are and to do reconn on the technologies and visualizations people use.  We’ll use that to help us develop the v1.0 of this project’s deliverable and make sure it’s left in a state that RelMan intern 2.0 can pick up next summer.

Please comment if you have dashboards you like, you loathe, or you just want us to know about.