Release-Mgmt: My First Beta from the ‘other’ side

Hello and welcome to my continued documentation off my learning curve in Release Management, something I’ve now been working at for 6 weeks.  Last time I was reeling from the new-to-me meeting/email/bugmail firehose.  Now I’ve got that more under control, having created many more filters and folders in Thunderbird as well as having a chance to do more work on the automated tracking emails script.

To continue to spread out the knowledge and tasks for release managers across more than just one Alex, last week I ran my first beta (Firefox 12 beta 4) and now I’m going to tell you what that involved because the bugzilla API is down.

Monday

Monday is about getting the queries down as much as possible.  This means making sure anything with Tracking?, approval-mozilla{beta,aurora,esr10}? is triaged and nudged further towards its final destination on the trains. We’re also needing to watch out at this point for riskier fixes, things that really need some bake time with actual users need to be landed for a beta4 since beta5 is more for low-risk regression back-outs and security fixes that need to land just in time for beta 6 (what is usually re-built as the appropriately branded final release).  At this point in the week there might be about 80-90 bugs we need to get sorted and at the end of the day only about 6 bugs were in the ‘really want this in beta 4′ list.

Tuesday

For this particular beta, we had been asked if it would be possible to give the ‘go’ to build earlier than usual because there was a fairly popular holiday weekend coming up (Easter) and our QA lead for this release was in Canada where Good Friday is a statutory holiday. The QA lead asked if we could go to build earlier so that a Thursday release of the beta would be possible. We confirmed with RelEng that this was do-able and agreed to do our best to get the ‘go’ out at an earlier time.  The plan was for everything to be landed by 2:30pm (Pacific) in order to have a changeset ready to fire off to Release Engineering by 5pm.

Going through the ‘burn list’ from Monday (6 bugs) mostly entailed tracking down people to land patches. There has to be a cutoff time for landings since it takes about 4 hours to get all the builds and tests for a push to the hg repo to report back completely. Note that improvements to build times are being worked on, case in point: faster Mac builds (newer hardware and using OS X 10.7)  take ~2.5hours off the normal Mac build times.

For one of the bugs we weren’t able to reach the dev and a volunteer committer found that the patch didn’t apply cleanly so that bug had to miss the train.  The others got in and I sent the ‘go’ to build Firefox 12 beta 4 at approximately 5:45pm (45 minutes later than desired).  All the results weren’t in yet for this changeset but I wanted to get a shot at making the request for earlier builds to QA so I took the risk that the builds/tests would be OK and we’d be already building when we confirmed that.  Had the builds/tests *not* turned out we’d have to scrap the chance at moving up the release window and one of our QA leads would have worked on a holiday to meet our ‘normal’ Friday release window.  So I took the leap (and this ended up being fine, though I wouldn’t do this again without good reason as it was a stressful call to make and it’s not a good practice to get into).

Right after the ‘go’ email was sent hg.mozilla.org went down and we lost 3 hours of build time.  This is not a normal result of giving the ‘go’ to build.  It was probably just because Hal was new to doing releases and I was new to running a beta so at least one thing had to come along and shake our confidence.

Wednesday

There’s not much (beta-running) to do on Wednesday except wait for Desktop & Mobile QA to do their thing.

Thursday

Mobile & Desktop QA send their results out – either signing off on the builds/updates or calling out issues. At this point QA signed off so at that point I could request the Release Engineer to push the updates to the beta channel (and upload a new beta apk to the Google Play Store). An hour or so later both QA leads signed off on the updates for the release that’s now live to our beta users.  After that, there’s just some product details to change for our websites to include beta 4.  We don’t do release notes per-beta which is good to know for when I run a beta 1.

Friday

Normally we’d be doing the push to beta channel on a Friday, so what would have been different was:

  • getting everything landed to mozilla-beta could have gone until later in the day
  • the ‘go’ to build email wouldn’t have resulted in immediate builds, they could start on Wednesday at the beginning of the Release Engineer’s day
  • QA needs two full nights of testing, so we’d get sign offs from QA on Friday morning instead – hence the push to beta channel (and store) on Friday afternoon

Nothing too crazy for my first beta.  I think beta 4 is a good one to start on – it’s not the “OMG last call!!1!” beta before a release and it’s not beta 1 where any fallout from our merge of mozilla-aurora -> mozilla-beta shake loose. Having done a beta release now,  I have a much more complete mental map of how the 6 week release cycle plays out for Release Management:

Multiply by the above by 6, sprinkle extra bug & meeting communication cycles to weeks 1 and 6, throw in twelve channel meetings, approx 30 more iterations of various queries triage to keep our tracking lists up to date and to know what’s really needing attention vs. what’s taking care of itself.

A ton of email/irc/automated notifications all with the goal of keeping tracked bugs moving forward and you’ve got your 6 week result: A fabulous new Firefox release.

Thanks for reading, more about automatic emails & wiki updates soon.

Trying to Resist

Table with trays of cookies and a large chocolate cake on it.

Today at Confident Coding (women learning JavaScript) I am having to work really hard to stay true to my SuperBetter Challenge to only eat sugar on Sundays.  Tomorrow seems really far away when I’m faced with trays of chocolate chip cookies and a large chocolate cake.  This is practically torture.

Except that it’s not.  It’s the privilege of being in the San Francisco tech community where weekend events come with free food, wi-fi, and great opportunities to learn and network – and there happen to be free cookies a lot of the time. This is one of the ways I try to stick to my self-prescribed challenge to only consume sugar on Sundays.

Distract. Delay. Drink Water.

The D’s above were in some tips for quitting smoking and let me tell you, they work now too.  I walk away from the tray of cookies.  I tell myself that I get to have whatever I want tomorrow, and I have a drink of water.  I’ll get through this day. It’s not the last day there will ever be cookies on this planet.  Usually avoiding something for 10 minutes is enough to get a good few hours free of temptation.  I’m almost there.

SuperBetter: Travel and keeping up with my challenge

This is the first in what I hope will be several blog posts about my SuperBetter challenge, to cut sugar out for 30 days (month of March) and then to switch to only having sugar on Sundays for the next two months (at least).

Most of my sugar-free March went really smoothly.  I have gotten a lot of practice at doing my ’30 days without sugar’ exercise so I have developed plenty of coping mechanisms.  This time around I hardly needed them.  I mostly got through with sticking to mealtimes, being vigilant about preparing ahead for meals, and drinking lots of water.  I think that this is because since my last attempt, I have actually reduced the amount of sugar I keep around me significantly.  However, there’s a big glaring spot in my life where sugar is ALWAYS present – at the office.  Our office has a wall-o-snacks for the taking (this is some Silicon Valley thing I have never experienced before).  I’d wager at least 60% of the snacks are high in sugar, another 20% medium sweet and then there’s a handful of savory things like pretzels, cheese sticks, and V8 — that’s my triad of workplace snack right there :)

The snacks aside, no-sugar March was cruising along and then Jenny and I went to Mexico for her spring break.  We went to Tulum, which is down at the bottom of the Carribean side of Mexico, a place of Mayan ruins and lots of snorkeling.  Mexico (the parts I’ve been to anyway) is a great place to avoid sugar because they don’t seem to do much in the way of deserts.  Sure, if I wanted to I could have bought candy at the store before we headed to our out-of-the-way palapa on the beach but since I didn’t, there wasn’t any temptation at all.  When you have a meal there it’s just the meal – no desert is offered.

The first four nights of the trip were excellent and full of rest and adventure in equal amounts.  I think I really pushed my record for how much time I spent reading in various hammocks.  On the fifth night though, I woke up to an unpleasant illness that wiped me out and left me hollow and dehydrated the next day.  Unable to eat (or really want to try eating) any more of the food provided at our resort, I really had no choice but to have a bit of Fanta orange soda so that I’d at least get a little energy.  This was a bit of a bummer to me because not drinking soda is something I’ve really conquered in my life.  I’m not going to be too hard on myself though, I was sick and in a strange land.  If I could have been at home I could have made myself dry toast that wasn’t WonderBread or I could have had some chicken broth for energy instead of a soda.  The next couple of days were a little bit loose with sugar too because I like to be nice to myself when I’m sick so when we went to the Mayan ruins the next day and the parking lot craziness included a Dairy Queen…well, I’m not the kind of person who easily ignores ice cream :)

In the end, I made it to March 29th without having sugar and then when we got home I re-committed to my epic win where I now only have sugar on Sundays.  It’s Wednesday now and I’ve got a Canadian chocolate bar in the cupboard waiting for me on Sunday.

If anyone is interested, here are a couple of my tips for traveling when I’m trying to work on my eating:

  • Bring snacks you like and can eat.  I bring dried fruits, jerky, and if I’m eating sugar I bring Clif bars as a breakfast option in case there’s nothing good where I’m staying.  They are also useful if I’ll be in hotel with a gym so I can eat something right away after working out and avoid impulse purchases of breakfast pastries.
  • Have a reusable water bottle with you. Fill & drink it empty often, especially on the plane. First of all, it keeps you hydrated (and flying is super dry) but also it helps you feel full and less likely to impulse-shop in the airport gift shop or duty free both of which taunt you with massive amounts of chocolate and candy.
  • Buy a salad (or a sandwich if no salads are appealing) in the airport to take on the plane. Most of the airline food will have sugar in it or sugary parts to the snacks included.  It’s incredibly hard to resist eating while bored/full on a plane because it’s already such an altered state and planes don’t really sell salad.

That’s  all for this post, thanks for reading.

 

 

More reasons to support the Ada Initiative

This week there’s been a tremendous amount of tech community churn with companies being called out for blatant sexism/women-as-sex-objects in their company promotional material.  Sqoot organized a hackathon in Boston and made a very big mistake in their call for participation which kicks off with the assumption that hackers would all be men, then continues with a misguided attempt at an apology that only suggests they are sorry I don’t have the same sense of ‘fun’ that they do (they have updated the apology to this, which I still find lacking).  This morning I woke up to the delightful twit-splosion about Geeklist.  I notice that I had never heard of either of these companies prior to their exposure from feminists calling them out which leads me to think about the long term impact for these kinds of internet altercations.  Much like how having what goes into a MacDonald’s burger exposed or seeing video of how WalMart treats its employees has shaped my physical world consumer habits, I suspect that hearing about/experiencing sexism (or a multitude of other poor behaviours) from a particular company will help steer my internet participation whether I’m already familiar with them or not.

What these events should remind us of is that there are people working on this stuff. Individuals, to be sure, along with bloggers and the tweet-verse but also actual companies like, for example The Ada Initiative.  They are experts at working alongside organizations, tech conference organizers, and open-source communities to help set up training, hiring processes, and organizational policies that would have helped both Sqoot and Geeklist avoid this kind of publicity in the first place by addressing their assumptions at a lower level.

If your company hasn’t got a Code of Conduct (and Mozilla is currently hard at work on creating ours this week after our own conflict a couple of weeks ago), if things are just being brushed aside right now or your employees are told to ‘lighten up’, then trust me: you’ve got a ticking time bomb in your organization’s future.  Not having something in place is not the way to deal with the tricky details that come with the admirable goal of a diverse workplace/community.  Sure, getting those things in place, making sure policies have teeth, and organizing some sensitivity training may not end all possibilities of people getting hurt or ending up in confrontations but I believe that setting the tone and getting a few ducks in a row is a wise undertaking for most companies with more than 2 employees and it most certainly won’t HURT. Once you have something in place, consider future occurrences of conflict opportunities to iterate.

Get in touch with The Ada Initiative today and figure out what your company doesn’t have in place yet that will give it the future you really want.  I’m pretty sure avoiding having your brand dragged through the mud in the eyes of approximately half your potential market isn’t in your business plan.

PyCon 2012 and a second wind for PyStar

Pystar flaming 160 150px

Yesterday when PyCon concluded (and I sadly did not win a NAO robot), I drove home with a sense of renewed energy for continuing to work on building the python community I want to be a part of.  I had a tremendously good time at this year’s PyCon. It continues to become a more diverse space and a place where I feel connected with people who inspire and motivate me.

I was happy to (finally) meet Dana face to face, and thrilled to see several women who had attended PyStar events also now attending PyCon. It’s one of the reasons we left last year’s PyCon with the dream  of PyStar in our hearts.  After the talk about the Boston Python Workshop (which was wonderful and thanks to Asheesh for the shout-out) I was thinking about what makes PyStar unique and whether there is a need for PyStar now that many other alternatives exist.  Hard to believe that only a year ago it felt like there was nothing for women in Python and now there’s shirts stating “Python is for Girls” for sale at the expo hall.

So, with all these groups springing up (and the BPW continuing to grow) do we need PyStar? My gut says immediately “yes” because the more groups focusing on bringing women into geek/programming space and having it be safer and comfortable the better.  There’s more to it than that though.  The groups are all doing great with their various organizers and events.  PyLadies, Ladies Learning Code, and Women Who Code are all holding sold-out events, getting lots of attention, and we’re all working hard to get more women connected to a community of programmers where they can learn and develop skills in a ‘safer’ space than historically has been available to women. The Boston Python Workshop is doing a great job of promoting Boston (as well as Python and Workshops) but I realized that for me, the reason I got excited (and am excited again) about PyStar was exactly because it was non-geographically named and because the name itself is for “all”.  I’m very happy to be in the mix with all those groups and yet I recognize that I still want to try to nurture and shape PyStar into its own thing.

I am interested in continuing to explore how to work on this project with a distributed team and to have PyStar events spring up in various communities and be customized to specific needs. Just because SF is heavy into startups and web apps doesn’t mean that San Antonio, Texas will be – maybe they’ll be more into big data and hardware hacking.  I like the idea of PyStar developing and hosting a wide variety of curriculum for python-driven projects in a central repo that can be cherry-picked as needed by anyone in any city who wants to lead a workshop day/weekend/afternoon. I especially want to figure out how to repeat what I did in Paris last summer, where I managed to organize a PyStar for when I was going to be there visiting. That certainly required some existing connection to the town (Mozilla/WoMoz) but the idea of traveling and setting up shop anywhere a hacker group/women’s community/library can host – that’s exciting to me and carries forward the DIY/punkrock way I’ve always known how to get things done.

In the talk at PyCon, one of the BPW’s stated goals is to try to build up within existing user groups. I see their logic, and it’s sound, but I was not a member of the BayPiggies (the Bay Area PUG) when I first was inspired to start running PyStar events in the Bay Area and I still don’t see the need to be. There are several places where I can announce upcoming workshops, Baypiggies have a mailing list I’m on, and I can promote PyStar events and make sure other groups are in the loop about what we’re doing.  I think this more than satisfies being eligible to be part of the larger Python community, and yet there’s room for more than one Python-loving group in any community. I’m not always looking to insert myself into an existing group – there is something to be said for creating new things and building them with a certain tone/mission in place at inception. That’s what I get out of PyStar, it doesn’t have a legacy or a way things have always been done – the spirit of PyStar is one of distributed organization, shared responsibility, and communal education.

Here are my specific goals for this upcoming year of PyStar:

1. More curriculum on the PyStar site – workshop material that is discoverable by level (beginner, intermediate, pro) and by time commitment (half day workshop? full day? multi-week?). A new person  interested in organizing a PyStar event should be able to see an easy-to-follow list of what to do to set up their own event based on time and level. This can be accomplished through more research on finding existing curriculum and adapting it, more events where we can test and fine tune those curriculum, and also having curriculum hack nights with PyStar organizers and volunteers (multi-city) where we focus on developing material to fill gaps in our topics

2. Have PyStar SingPath tournaments both locally and with other PyStar outposts. While the one I did at PyCon 2012 was a nerve-wracking experience, it was ultimately a confidence-boosting event for me. I encouraged a few women to come try it and it seems to be a pretty fun way to maintain the energy as well as test your new skills between workshops. We can tailor the tournament to be _very_ friendly (prize/badge for all, just for participating). I read/heard something recently about how leaderboard style of competition is not that motivating for women and that beating your own previous results is much more fulfilling.  We can definitely work that into our tournament styles by awarding prizes for most improved and other metrics that a person can get by just doing better than they did in previous tournaments.

3. Incorporate Open Badges into the PyStar curriculum so there is measurable outcome for completing projects and implementing the handing out of badges through the PyStar site. Gregg and I are already talking with Mozilla about their Open Badges project and will continue to keep an ear to the ground on how to implement this into the PyStar site. It would be nice to have a meeting with all interested PyStar organizers to brainstorm on what our badges could be.

4. Find non-profits who need small projects (simple website, automation) done and have no budget – match them with PyStars who would like to learn. Possibly have a connection section on the PyStar site?  Have PyStar leaders be ‘project managers’ and bring a project to fruition through regular PyStar meetups? This is a longer term goal, but one I like to keep floating out there and gauging people’s reactions to. Usually the reaction is “great idea! lots of work!” :(  My vision here is something along the lines of a a template for ‘how to build a (info, fundraising, blogging) site for a small non-profit with a newbie webdev team’ curriculum.

5. A stronger focus on intermediate level programmers. Not to the exclusion of beginners, but to be sure there is room to grow within PyStar This comes up a lot in SF/Bay Area and I know it’s different in each city.  In SF/BayArea it seems really important because there needs to be something to hook in the women who have programmed in other languages or who are CS majors who seem to lack the confidence in themselves now that they are out in the workforce – with many of these participants, it doesn’t take much to remind them how far they are from a newbie – I would like to focus on them a bit more because a) no one else seems to do so b) it provides more volunteer potential and alum/badges c) mentoring opportunities for newbies and job networking for the intermediate level programmers among each other

6. Continue to develop strong connections with PSF, BPW, PyLadies, and __insert_group_here__ organizers. – I should have proposed a BOF at PyCon for organizers to get together and share plans — I would really like to work alongside these other groups in a sustainable way, we all have admirable goals and could share some resources and people-power.

7. PyStar gear & promo materials, fundraising. Set up a cafepress store to sell some PyStar goods and also try to get a few donations to set up an account for PyStar that would allow us to a) pay for the domain name I just renewed b) potentially buy other domain names for side projects we come up with when we work with non-profits  c) cover the costs for creation of handouts, cards, other promo materials to give out at events promoting PyStar

Get involved!  The project currently lives in github and organizers/contributors can reach each other through our mailing list.  If you want to host an event, help with curriculum, or otherwise work on making safer spaces for learning Python happen in your own community, get in touch.

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.

Autolanding your patch(es) to Try via Bugzilla

We’re ready for a soft release of the first step in our very experimental autolanding system. Experimental meaning: we reserve the right to pull the plug, take it down for tweaks, and some information may be lost when bugs arise.  You can check the if the autoland system is up and running by going to http://bit.ly/autoland_status

This is the Try branch only portion of what will become a system to automate and more easily manage multiple branch landings.  Marc Jessome, our returning Release Engineering intern, and myself have this as a Q1 goal.  There are several issues to be resolved with this system and the link above will keep you appraised of what the goals and known issues are. We will be working hard over the next two months to make this a secure, reliable system for landing patches with minimal developer time spent pulling, pushing, and watching tbpl.  The hope is that it will also become a useful tool for Release Coordinators to track that a fix lands across several branches as needed.  Future features will include a bugzilla extension to securely interact with this system and remove the need for whiteboard tag changes and a RESTful API so the whole process could be initiated through the command line.  We appreciate constructive feedback but please hold off on scope creep suggestions :)  

Here’s how it works right now:

  1. Attach patches to your bug Note: if you (the attacher) do not have permission to push to Try, get an r+ from someone who does
  2. Use this documentation to determine the appropriate whiteboard tag and enter it in the bug so our autolanding poller will pick up on your request
  3. The autoland system, which tracks all bugs with autolanding requests, will queue up your patchset and then pull it from the queue, apply the list of patches in your bug (or those in the whiteboard tag) to a clean pull of mozilla-central tip, commit each patch as the patch author, and finally push to try as Autoland User
  4. A comment will be posted in your bug with the results (hopefully successful) of the push attempt, and the whiteboard tag will read [autoland-in-queue]
  5. After all builds complete, their results get posted back to your bug (just like with the current ‘–post-to-bugzilla Bug #’ flag in trychooser) and the [autoland-in-queue] whiteboard tag will be removed

There is a threshold on how many bugs the autoland system will push and track at a given time.  We are curious to learn about usage and load on this system so please give it a try and inform us of any issues in IRC: #build or #developers channels are the best places to find myself (lsblakk) or Marc (mjessome) and chat us up about this initiative.

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.

OccupediA – Women Contributing to Wikipedia (the first of many such events)

Last Thursday night about 8 women arrived at Noisebridge to learn how to contribute to Wikipedia.  Several things led to this gathering:

  • An article in the New York Times back in October drew attention to the lack of women contributors to the Wikipedia knowledge base and that got me thinking.
  • Having organized other spontaneous “women get together and learn stuff” events I figured I could take the same approach to Wikipedia contributing, get some women together to create accounts, generate content, learn how to stop vandalism and see what would stick.
  • Recent participation in activism around the Occupy Wall Street movement also inspired me to try and reach out to communities I am in who are not as technical, to encourage people to come first with knowledge and interest in topics Wikipedia could benefit from and let the tech come second.
  • A month ago Elsa and I were talking casually about all the the above mentioned things and we decided to just go for it and pick a date, throw it up on the Noisebridge (local SF hackerspace) calendar, and see what we could make happen.

We took over a small makeshift classroom space at the back of Noisebridge. It had one lamp as the primary source of light because the fluorescent holders above were missing their tubes.  A man was near the back working on a dress for fashion school, several other hackers were up front working on their various projects.  Noisebridge was a wonderful place to have this event. It feels like anything is possible in a space like that.

I was happy with the turn out – we had a mix of artists, educators, and tech workers. Also as a bonus one of the attendees, my coworker Boriss, was a seasoned Wikipedia contributor who was able to really detail the ins and outs of the different levels of participation.  I can’t stress enough how amazing it was to have her and her knowledge there because there are lots of misconceptions about Wikipedia (I definitely had some) and her first-hand knowledge was inspiring to me.

So the beginning of the meetup went well enough, and as you might expect.  We introduced ourselves, talked about why we had come to the event and what we were hoping to get out of it. We started in on learning how to set up an account if one didn’t already exist and we looked at discussion/history/edit and other basic navigations of Wikipedia space.  There were a lot of questions about what belongs in Wikipedia, neutral tone, citations.  The conversations were lively and I found them quite enjoyable.

Here’s what I didn’t expect: Getting folks interested and excited about Wikipedia becomes REALLY HARD in practice.  Unlike learning Python where the participants can hammer out some code on their own computers in minutes and feel accomplished, there is a lot more complexity to Wikipedia.  There is a lot of confusion about their UI, their purpose, who can do what and when. Very quickly it seemed that the women who had come to the event feared adding anything new to the knowledge base and they were also incredibly intimidated by the UI of the site. It wasn’t even clear enough how one would create a new article when none existed.

From this event I learned a lot about organizing and about the intentions of future events like this and I did a little braindumping while we were meeting so I could remember to list them later in this very post.

Things that would help newcomers:

  • Having a “new to wikipedia” moniker next to their nickname for the first N activities on the site (we have this on our Mozilla bugzilla) so that hopefully older and wiser participants would be extra nice to them
  • Find a way to make some of the simpler tasks that help Wikipedia (typos, reverting vandalism, categorizing articles) into a game that a new arrival could play that would start easy and then move more toward the real-life workflow of working on Wikipedia – as a way to warm them to the UI
  • Encourage newcomer to write a straight-up article and have a place for these things to be dumped for inpection/linkage/categorization and otherwise Wikipedia-fying the knowledge dump.  My partner is an English professor and can certainly write good content for Wikipedia but everything about the site is intimidating. There should be a page where she could copy/paste or upload a document of her article and then let people who know wiki syntax and the other requirements an article needs come along and finish it up
  • Make it way easier to find the “adopt a user” program that I hear exists but no one would know to find that from the Wikipedia home page

I will continue to organize these events, perhaps once a month. More reports as they happen.