Dare 2B Digital 2012 – Wrap up post

Fox with firefox logo

Better late than never, I will recount Mozilla’s participation in the 2012 Dare 2B Digital conference back in February down in San Jose.  This year we were hosted at the eBay campus and instead of being out in a hallway demoing and playing with open video and universal subtitles (2011) this year Mozilla was all about making, in a large space shared with Microsoft, encouraging the girls to work with a variety of hardware, circuitry, robotics, and creating 3D printer designs for a MakerBot.

Before I go into the details of the kits and the day of the event, there are some very important people to thank:

Tremendous amounts of props must be first given to Emily Lovell whose soft circuits teaching guide I discovered at the 2011 Grace Hopper Celebration of Women in Computing.  Her exercises, diagrams, and lists of resources were at the core the kit I designed to teach the girls about parallel circuits through assembling a felt fox and attaching LEDs to the eyes that are powered by conductive thread and a watch battery.  Thank you to Mozilla for sponsoring the Dare 2B Digital conference again this year, it is such an important space for us to be in as it gives us a chance to promote open source to a young audience that is still undecided about college majors and it’s our chance to encourage them to at least consider a technical career path. I hope that having an early, positive, creative experience with Mozilla and open source technologies provides the girls with an awareness of alternative ways of engaging with technology. Mozilla Reps provided the budget for these kits to be made – not only for the workshop attendees, but also enough kits to put one in every take-home bag for all conference participants.  It is certainly my hope that many girls who couldn’t make it to the workshop due to lack of space will still attempt to make their foxes at home with a parent or sibling.  Finally, I cannot thank enough the various Mozilla employees and other friends who helped me assemble 350 kits for the actual event – my vision for this event could NOT have been done without their generous donations of time and their assistance on the day of the event helping the girls complete their kits. Thank you especially to day-of volunteers: Kate, Vicky, Alex, Christina, the Super Awesome Sylvia and her parents James and Christina,  and the add-hoc assembling factory workers: Mariko, Heather, William, and the entire UX team at Mozilla.  My girlfriend Jenny also helped me assemble some of the first kits at home while I cut all the felt sheets into smaller sizes for the foxes. My most sincere gratitude to you all, it went off without a hitch…except for the handful of batteries that exploded…but that was my fault 🙂

Now for some detail about what was involved in this project in case you want to replicate or improve on it.

A lot of felt foxes

The idea was pretty simple. The kit would be a takeout food box that contained everything needed to make a parallel circuit on a felt fox.  I ended up designing the felt fox myself after attempting to make something work with Lisa Higuchi who does amazing work but as I found myself running out of time I just created a simple pattern that could be held together with felt glue and then sewn/wired up in about an hour – which was the length of the workshop.  The soft circuit guide had the information needed for ordering supplies so in the end the kit’s component list looked like this:

  • 100 9×12 sheets of copper brown felt (400 fox faces)
  • 100 9×12 sheets of white felt (400 fox eye areas)
  • 30 9×12 sheets of black felt (450 nose/eye/inner ears)
  • 10 spools of conductive thread from Adafruit
  • 400 3v batteries
  • 400 battery holders
  • 800 yellow LEDs
  • 400 red takeout boxes
  • 5 bottles of felt glue
  • 400 small ziploc bags
  • 400 needles
  • 1200 pins (intended for holding the felt pieces together for sewing, they ended up being superfluous because of the glue)
  • 400 manual/pattern sheets

 

Shot of the pattern and instructionsThe felt firefox kit contents

I literally threw together a manual and a pattern at the 11th hour, as the UX team was coming to help me assemble the kits one night after work.  The manual leaves out a lot of the detail as to HOW to make the felt fox. Fortunately it includes a picture of a completed fox, so hopefully a resourceful teen at home can determine how to make her fox kit work. I have definitely learned from this experience to make creating the instructional materials a much higher priority next time.  The pattern was done in haste with a sharpie, me tracing around the parts of my prototype fox, I’m actually pretty OK with how that part turned out. When we assembled the kits we put all the small components into a ziploc bag and put said bag, one square each of white/brown/black felt, and a folded up instruction sheet into each takeout box.  The takeout box was a really robust container for kits and yet kept things light. I had no trouble carrying the 350 kits, in various bags and boxes, to my car to take down to SJ on the day of the conference.

The kits are in the bag stuffing lineEarly in the morning on Saturday February 12th, 2012 I drove the 350 kits down to the eBay campus and kept ~70 kits in our Maker room, leaving the rest with the D2BD volunteers who were stuffing bags with swag for the girls: Make magazines, usb bracelet, stickers, notebooks, a water bottle, and (among other things) a Mozilla felt fox circuits kit.  Then back in our room I had two of the Mozilla volunteers for the day make their own foxes so they’d be ready to help the girls when the first round arrived a few hours in.  Kate and Christina did a wonderful job of creating their first parallel circuits and spent the rest of the day being professional felt fox makers 🙂

Helpers make their foxes

As with last year, I found that out of the three workshops we did that day the first was a bit rough, the second quite smooth and the third was a cakewalk.  We can learn so much in one day about how to improve the process and the set up.  The first thing learned was that we had a bottleneck situation on scissors and glue.  5 bottles seemed like a lot to me but when split between two tables with at least 10 girls at each that was no longer the case.  I had brought in all my scissors from home, which turned out to be a lot (6) for a home, but not enough for the workshop.  We did scare up a few more pairs and optimized for workshop two by keeping the pre-cut paper pattern pieces for the next group of girls to minimize scissor time needed.  Another surprise: some girls did not know how to sew.   This was something I hadn’t thought of ahead of time since I learned to sew at a pretty young age.  This fact leads me thinking that because of time constraints, 1.25 hrs per workshop, using ‘squishy’ circuits might have been a stronger learning experience here.  The sewing is probably more appropriate for a half-day workshop or even full day if possible.

Customization of the fox pattern

Customizations happened.  I loved that girls immediately took to hacking the fox pattern as designed by me; adding bows, crowns, and eyelashes to their foxes.  It made me glad I hadn’t found time to pre-cut the fox parts.  The back of the fox head is easy to draw a circuit path on and see/experience polarity – using sharpies on felt was a great way of going over the concept of a circuit, right on the material about to be used.  I am really happy with the overall teaching experience here.  Several girls showed incredible tenacity in the face of adversity.  One young woman in particular, having a very hard time with the sewing, went out and got her lunch and then brought it back to the table to continue her work – she re-did the sewing and managed to get it working.  The whole time she was silent and focused and I really wish I had pointed out to her that her attitude was the most impressive, hire-able skill I can think of.  I’m sure she’s going to do well in whatever field of study she pursues.  One young woman cracked me up when she became frustrated with threading her needle, exclaiming “This is why women revolted!”.

In conclusion – the event was a tremendous success – both the conference as a whole and the Mozilla workshop flourished this year. The conference does a great job of pulling feedback from participants, as they must hand in a form to get their swag bag at the end of the day.  We see in the feedback that we did a wonderful job of getting the young women excited about and considering career paths in technology. In the summary from the feedback forms “87% thought the robotics workshop (Mozilla/Microsoft) was great or good”. Also 100% of respondents would recommend this conference to a friend or another parent.

I really look forward to dreaming up something next year to top this.  I have no fixed idea yet because part of the fun of doing this conference/workshop is waiting and seeing what exciting new open technology would be a good fit at the time. I’m definitely going to keep the issues from this year in mind when formulating a plan for next year, and pay attention to minimizing participant wait times in order to increase overall satisfaction with the project.  When I initially came up with this idea, I was worried that it didn’t have a strong tie to Mozilla’s mission, but as I continued to develop and finally executing it I felt more and more like the way we work on projects like this is such a product of how we work on keeping things open on the web.  It was thanks to the web that I found the guide which helped me with planning, it was thanks to the spirit of the open web that people I work with (and some with whom I don’t) came out and volunteered to help make this happen. Getting your hands on a building block of technology, modifying it to make it your own, sharing the results – that too is the open web, and it’s what the day provided for all the young women in our workshops. I look forward to seeing what the future holds with these potential hackers in it.

Group shot with completed foxes

Lukas helping with fox making

 

 

 

 

My first three weeks in Release Management

Three weeks and four days ago a request was floated out to me. Would I consider helping the release management team for a little bit? You see, we’ve had this unfortunate ‘trend’ in Release Management at Mozilla. Whenever a new hire is brought in to join in the fun of release management, the former team member would see their opening and often quite quickly head off to another gig. This 1 to 1 to 1 to 1 ‘team’ size leads to a single release manager taking on an incredible load and working alone, to boot. These two factors might very well lead someone to throw in the towel, no matter how awesome Mozilla and its mission and when you only have one release manager, that’s a terrible edge to ride. So, back to the question: Would I be willing to get in there and help out, attempt to lighten the load, learn how it’s done and let our 6-months-in release manager, Alex, perhaps start to ease off his 100 hour weeks?

Answer: Gladly. I can honestly say there is _nothing_ more motivating to me than being asked to help someone, especially if I think I can actually do it. I mean, I would certainly try to help someone beat off a streak of tigers but I would die pretty fast regardless of my high level of ‘motivation’, and being dead isn’t too helpful is it? In this case, being that I’m very familiar with how releases get out the door, I figured I had a good head start and could pick up the rest as we went along.

Three weeks ago I began a journey into learning how exactly the “other side” lives. Until then I had been blissfully ignorant of most things related to getting our product ready to ship. Sure, I remember before Firefox 4 went out and Shaver was promising people he would squeeze oranges for them if squeezed oranges would help them _get_stuff_done_ but mostly I was unaware of what went on at all those meetings, how bugs get chosen for different releases, and how we get a product to the point where a Sam/Beltzner/LegNeato/Akeybl could say to Release Engineering “go to build on Firefox Version N, build #1”.

No longer am I blind. Bonus? Now I know what the people I’ve known for 5 years _actually_do_.

Here’s what I have discovered so far:

  • Bug queries are my new best friends. We spend a LOT of time looking at various triangulations of bug data – approval required for {beta,aurora,esr10,1.9.2}? are we tracking it for {11,12,13}+? is it a security bug that needs to get into 3.6.next? blocker? topcrash? regression? I now have at least 4 or 5 bug list tabs open at any given time.
  • There’s a lot of communication involved in getting a bug to the finish line. Comment in the bug, wait for response, no response? Send an email. Email response? Great, now back into the bug with you for more history. No response? Ping in IRC. We will do whatever it takes to get a status update, find out if we should really be tracking something, discover blockers, ask about security risks of landing, or otherwise get the information needed to make the most informed decision about including/excluding a patch from a particular release. In the past couple of weeks, when I wasn’t in meetings or looking at bug lists, I built on Christian‘s bztools a couple of scripts that allow us to enter a bugzilla query, sort the bugs into buckets by manager and then send out a single email to each manager of the bugs’ assignees asking them to take a look at what we’re tracking for Firefox Next. Let’s start those discussions early and keep the bugs alive with whatever steps are being taken next.
  • Meetings are much more plentiful now. Two Firefox related meetings per week, two channel meetings, one ESR/1.9.2 triage, and a couple other 1×1 meetings to do RelMan planning. Add to that my 3x/week meetings with Marc to continue project managing Autoland and my week’s windows for writing code are significantly diminished. We have been trying to brainstorm ways of structuring meetings, calendaring, automating, anything to help reduce meetings/make them more effective. Watch for more changes to roll out as we continue to iterate on what’s working and eliminate what’s not. This seems to be the area we should focus on improving more than anything. It’s also the area where I am weakest, having a background in feminist collective process but not much in the way of boardroom and software production meeting styles. However, I am positive we can keep trying to improve one thing per meeting (like setting up a template or using the fabulous new bugzilla extension for our wiki) and keep chipping our way to being a lean, action-focused meeting machine.

My teammate Aki and I were talking almost every evening during the first week. He’d be curious as to how it was going ‘over there’. On the first day I reported back how crazy it seemed and how we spent so much time on bug queries and asking developers to talk with us about how things were going. He said “it sounds like you need three people, one per release branch”. A couple night later, I again filled him in on how things were going and about the email nag tool and about ESR and he said “now it seems like a team of 7 would be more ideal. One per branch (now including ESR), two on tools, one on vacation – then they all rotate”. I think it’s hilarious, and currently seems far-fetched that this team could ever get that big. It sure would be nice though. There’s some interesting problems to solve here. In fact, today in a meeting with Axel and Armen about l10n & releasing we pretended engineering effort was not short in supply and imagined what a fully automated release could look like.

Total hand-waving of what we could do automatically: tracking bug queries of release blockers, landing approved patches and watching for results, requesting l10n milestones for a release, sending the go to build when the last blocker is landed and the tree is green on that build, requesting a push to mirrors once QA signs off.

There’s so much fun to be had here 🙂

My very first contribution in week one was to get us a ‘release-mgmt@’ email so that we could start to act (and be perceived of ) as a team. Seems like a small thing, but as we continue to use it, I hope that we’ll keep building a sense that there is more than just one person nagging you to get your bug landed/nominated/tracked/backed out. I hope it will start to feel like there’s a team, encouraging you, trying to help you whenever possible, and working to keep the trains moving on time.

Growing the company, structuring volunteerism: My response to David Eave’s community lifecyle audit

Last Wednesday David Eaves presented the results of the multi-tiered contributor lifecycle audit (watch the video).  A few points really grabbed my attention and as someone with a background in arts & education non-profits I feel the need to share my experiences alongside my reactions to this talk.

David pointed out that as we are growing, we can hire people to solve problems, so what exactly do we need volunteers for? Survey results showed that contributors often don’t feel their contributions had much impact on the project and that as our paid staff pool grows in size, there is less clarity about what exactly a volunteer’s importance is to the critical path of Mozilla’s mission.  I wish we had this data prior to the 1+ year push to releasing Firefox 4.  My hand-waving hypothesis would be that as we were cramming to get a product out the door we forgot to be leaders of volunteers and instead unconsciously pushed them aside so that things could get done on a schedule.  It was a stressful time, but now that we’ve moved on to regular, rapid releases perhaps we paid staff can all take a step back and really assess how we incorporate the work of volunteers into our individual areas.

For many Augusts I have worked at a women’s music festival in the woods of Michigan and at that festival there is a kitchen that has pumped out 3 vegetarian meals a day for 5 days to 4000-8000 attendees depending on the year.  This festival relies on a core group of ‘workers’ who are in fact volunteers but let’s pretend that group of 500-600 people is like the paid staff of Mozilla.  The main kitchen work crew gets about 30 workers to run the kitchen.  You might think to yourself “but 30 people cannot produce enough food for 4000-8000 women” and you’d be very right.  The way it works is that all attendees of the festival are asked to do two 4 hour workshifts during the week they attend the festival.  The majority of workshifts center around the main kitchen and creating the meals which range from burrito night to pasta putanesca to nutloaf (a vegetarian version of meatloaf). All these meals involve preparation of pounds upon pounds of vegetables as well as cooking of pasta, beans, sauce.  Did I mention this was all in the woods, over a massive firepit?  Yup, so 30 women are in charge of making that entire process work and they do so by wrangling hundreds of volunteers per day into shifts around each meal and constantly leading and dividing up the work so it can be done by many hands yet results in one huge meal – 3 times a day!

So let’s go back to people who are volunteering not feeling clear about how Mozilla works and whether their time and effort has impact.  How can we make sure that the smallest task makes that person feel like they’ve contributed?  Some areas of Mozilla do this very well to name a few; AMO, SUMO, QA, and Personas. These teams manage tons of volunteers and have tasks with measurable outcomes (tests run, filing bugs, approving an add-on, answering a question in the knowledge base, shrinking the queue of pending Persona submissions) and sometimes they can use scoreboards or themed days to get volunteers mildly competitive for the respect of their peers and accomplish larger goals in a short burst. I’d encourage people interested in having volunteers participate in their team’s work think about how to make sure their volunteers have tools to measure their impact from the get-go.  In Release Engineering I would measure the number of bugs that we have yet to fix, many of them labelled “simple” or “old”.  If I had volunteers doing RelEng work I could keep track of their progress and post reports (as blog posts) of who fixed what when and how as the number of bugs shrank.

Another interesting result from the survey: older folks (34-55!) aren’t on-ramping as much as younger ones. At first I wondered how much of this was about access to the muscle memory of being a student.  I think it’s fair to assume that many students/youth can have a lot more time to contribute to projects like Mozilla as certain adult responsibilities may not be required of them yet. Over the past week though, I have started to visualize another take on this. In the arts & social justice organizations I have been involved with there have been plenty of adult volunteers but those organizations have a different need for volunteers. The music festival I mentioned would not happen if it wasn’t for volunteers.  The fact that the volunteers want the community of the festival to exist for them every year becomes the carrot drawing women of all ages to come to the woods of Michigan and build a music festival every year.  People quit jobs, take unpaid leave, and make plenty of other sacrifices of their time to participate in creating this community. The thanks for this 2-4 weeks of donated work is an amazing live/work experience camping with 5000 women on private land, having workshops, parties, and dances all in a very natural, safe, and ad-free environment and watching incredible performances all day and night for 5 days. 

In a different example, let’s look at a the Toronto International Film Festival.  Volunteers have to make it through the rigorous screening and application process in order to ‘get’ to volunteer for the festival. They are rewarded with behind-the-scenes access to the festival, sometimes a quick run in with a movie star, and free tickets to festival screenings.  The festival shows entirely world-premiere films so this is a huge deal for a volunteer.  Several films will see theatrical releases after the festival but seeing the premiere, often with the star in attendance and with a director Q&A post-screening really sweetens the experience. The volunteers also get thanked before every screening with a cute trailer from the sponsor for the volunteer program and there’s always a fantastic party post-festival as the final thank you. 

At Mozilla we do thank our volunteers with tshirts and sometimes bringing them to summits, MozCamps, or other parties. For older volunteers though, I wonder if that’s enough.  What does it take to get someone in the 34-55 range to donate their time?  I’m really interested in this one since I fall in that demographic as well.  For me, I need the time donated to do at least one of the following things:

  • be social, meeting new people in the community I chose to volunteer in is a big part of why I’d do it in the first place
  • provide a networking opportunity (similar to above, but might apply to folks on the job market a bit more accurately)
  • get me free access to an event I wouldn’t attend if it wasn’t
  • be something my friends are also doing so we are visiting with each other while doing something interesting
  • be for a very good cause so I feel good just helping that cause regardless of the tasks I perform

Let’s look at that last one.  The good cause is certainly in the eye of the beholder but I can honestly say that sometimes I have no idea why I would want to encourage a friend who volunteers for hospice care, homeless shelters, AIDS awareness, or other non-profits where the staff is small and the operating budget miniscule to come and contribute to Mozilla.  In the circles I travel in outside of my job Mozilla seems right up there with Google, Apple, and of course Microsoft.  Sure, a lot of people don’t know we’re a non-profit. I tell people that all the time and while it’s of interest to them, it doesn’t generate an “Oh! Can I volunteer there then?” kind of response.  We compare ourselves sometimes to the Red Cross or Boy Scouts – large organizations with volunteer bases – but I think we should start to re-think ourselves more like the film festival or the music festival.  We pay competitive salaries to our employees, we throw amazing events, and we don’t have to write grant applications every year to the government (like in Canada) or to private funds (like in the US) to ensure we can keep operating on a shoestring budget.  So even though Mozilla is a GREAT cause, I don’t think that’s the bait for the on-ramping of volunteers – especially non-students and people in the 34-55 age range.

What’s going to encourage 34-55 year olds to engage with Mozilla?  In my opinion it’s going to happen with targeted events where they can do something in a few hours that leaves them feeling connected and fulfilled and even better if it makes something in their life easier.  A while back, in Toronto, we did a day of service and set up an info table at the local library so people could come and ask anything about Firefox and even though by some ironic twist the library’s internet died we still had an amazing day just conversing with people and answering questions about Firefox, the web, security, and even general computing questions.  According to David “having good experiences in the project helps one to want to find others and pull them in” and “age and gender have no impact on the willingness to on-ramp, but the longer you volunteer with Mozilla, the less you on-ramp”.  My approach with trying to on-ramp then, in light of this, would be to look at getting a lot out of that short interaction. Help someone help themselves on their computer. Teach them a few keyboard shortcuts or how to install an add-on that helps them do what they already do faster and with more confidence.  Then encourage them to come back and teach someone else what they learned.  This can spread like a pyramid scheme and it’s no longer about getting a single volunteer to stick around for a long time, it’s just about having a good experience and carrying that forward. Potential volunteers can be motivated by the mission and/or by practical considerations it’s important to remember both have tremendous value to the Mozilla project.  I think it’s important to encourage 34-55 year olds by believing it’s OK for a contributor to do a one-off in a few hours as long as they walk away happy.

In conclusion of this very long post, I want to circle back to measuring. If we are going to make community a core part of what we do then we need to measure it we currently do not have an institution-wide measurement of contributions, volunteer performance cannot be evaluated, there is no structure for including volunteer engagement during strategic or operational planning.  Until we require Directors to create annual and quarterly goals that
include measurable goals around volunteer growth, retention,
participation, and effectiveness we will only see people (like myself)
trying to do this “off the corner of their desks” which means it’s not a
part of your paid work and thus less likely to be sustainable and
effective. The Toronto International Film Festival is a great example of what we could do here.  They have paid staff who organize the volunteers each year. They have a clear path for volunteers to follow to be accepted – training sessions are mandatory.  Each year returning volunteers are given roles depending on performance from previous years.  The record kept of each volunteer’s performance allows paid staff to request certain volunteers for specific tasks based on that information and a volunteer’s history with the organization.  Teams of volunteers will sometimes have “Captains” who are also volunteers but with more experience and they are thus given more responsibility.  Each area of Mozilla that can accommodate volunteers should keep an eye out for their current or potential “Captains”. David also suggested that, while we avoid it, we should really look head on at guidelines for when to rely on volunteers and when to not – this seems to fly in the face of open source “free for all” mentality but if we compare ourselves to other non-profits like TIFF there is proof that having some structure for volunteers allows staff and teams to develop stronger relationships and the work gets done smoothly, which was really the point all along.

Don’t forget to throw them fabulous parties, share with the world the importance and impact of their contributions, and remember you can never thank a volunteer too much.