I’ve been in Release Management for 1.8 years now and in that time we’ve grown from one overworked Release Manager to a team of 4 where we can start to split out responsibilities, cover more ground on a particular channel, and also…breathe a bit. With some of the team moving focus over to Firefox OS, we’ve opened up a great opportunity for a Mozillian to help Release Management drive Firefox Desktop & Mobile releases.
We’re looking for someone committed to learning the deepest, darkest secrets of release management who has a few hours a week consistently available to work with us by helping gather early feedback on our Nightly channel (aka mozilla-central or ‘trunk’). This very fabulous volunteer would get mentoring on tools, process, and build up awareness of risk needed for shipping software to 400 million users, starting at the earliest stage in development. On our Nightly/trunk channel there can be over 3000 changes in the 6 week development cycle and you’d be the primary person calling out potentially critical issues so they are less likely to cause pain to the user-facing release channels with larger audiences.
A long time back, in a post about developing community IT positions, mrz recalled a post where I stated that to have successful integration of community volunteers with paid staff in an organization there has to be time dedicated to working with that community member that is included in an employees hours so that the experience can be positive for both parties. It can’t just be “off the side of the desk” for the employee because that creates the risk of burnt out which can lead to communication irregularities with the volunteer and make them feel unneeded. For this community release manager position I will be able to put my time where my mouth is and dedicate hours in my week to actively shape and guide this community Release Manager in order to ensure they get the skills needed while we get the quality improvements in our product.
So here goes with an “official” call for help, come get in on the excitement with us.
Are familiar and interested in distributed development tools (version control, bug tracker) typically used in an open source project of size (remember when I said 400 million users? Ya, it’s not a small code base)
Want to learn (or already know) how to identify critical issues in a pool of bugs filed against a code base that branches every 6 weeks
Have worked in open source, or are extremely enthusiastic about learning how to do things in the open with a very diverse, global community of passionate contributors
Can demonstrate facility with public communications (do you blog, tweet, have a presence online with an audience?)
Will be part of the team that drives what goes in to final Firefox releases
Learn to coordinate across functional teams (security, support, engineering, quality assurance, marketing, localization)
Have an opportunity to develop tools & work with us to improve existing release processes and build your portfolio/resume
Mentor and guide your learning in how to ship a massive, open source software project under a brand that’s comparable to major for-profit technology companies (read: we’re competitive but we’re doing it for different end goals)
Teach you how to triage bugs and work with engineers to uncover issues and develop your intuition and decision making skills when weighing security/stability concerns with what’s best for our users
On-site time with Mozillians outside of Summits & work weeks – access to engineers, project managers, and other functional teams – get real world experience in how to work cross-functionally
Invitations to local work weeks where you can learn how to take leadership on ways to improve pre-release quality and stability that improve our Firefox Desktop/Mobile releases
provide references, t-shirts, and sometimes cupcakes
I’ll be posting this around and looking to chat with people either in person (if you’re in the Bay Area) or over vidyo. The best part is you can be anywhere in the world – we’ll figure out how to work with your schedule to ensure you get the guidance and mentoring you’re looking for.
Look forward to hearing from you! Let’s roll up our sleeves and make Firefox even better for our users!
In a couple of days you will, en-masse, get your first peek at the high level agenda of the 3 day MegaMozillaFest you’ll be cannon-balling into this coming October. As someone who feels very fortunate to have been part of the planning processes (more multiple threads than you can shake a stick at) I thought I’d take some time during my layover en-route to Toronto and fill you in on what got us here in the hopes that:
I can shine light on how much hard work and sincerity went into the organization so that participants can get a lot out of this experience
You can see how many different voices and teams come together to plan an event at this scale
You’ll become as excited as I am (or close) for the journey we’re about to go on together this fall
It started, for me, back in June when 70 ‘delegates’ were brought together at the Mozilla Paris office to begin the conversations that were intended to bubble up the big issues and tensions that our community needs to address at Summit.
Wait. It started before that.
For delegates going to the Paris Planning Assembly, we were asked to go out and interview people in our ‘functional areas’ and query them about the story of how they got engaged with Mozilla, what they perceived our challenges and opportunities to be, and where they see Mozilla going in the next 10-15 years. I reached out to our Homozilla list, WoMoz, and also to the Firefox Team – a nice, diverse group of people to try and drag up some feedback to bring.
Sidebar: We often get asked to seek feedback from others in preparation and most recently I did this for a TRIBE workshop. From doing those interviews in person I now plan to commit to doing all sorts of info-gatherings in person/vidyo rather than over email. It’s too easy to send out an email blast and then just pick up what comes back to you. I get so much more from talking with a person face-to-face (video chat counts) and as you’ll see later in the post about Summit planning, it’s important to go a little further trying to encourage feedback than just a one-way missive over email that can be easily ignored or missed.
I got less feedback from people than I would want or expect. It’s a part of our culture to be cycling rapidly on our work and that results in a general air of being overwhelmed and too busy to do anything out of the usual routine so I largely attribute the low response rate to that. For my part I could have framed the questions differently, reached out to individual people instead of group lists, held a vidyo ‘office hours’ to talk with people in person, and followed up more (ie: nagging, a RelMan’s #1 skill).
Minimal feedback aside, I went to Paris feeling very much like I could bring a certain voice to the discussions as someone who wears many hats in our organization and who’s been involved with the project since 2006. Also, as a former unpaid contributor, intern, then full time hire I can imagine some of the realities of what it’s like in the shoes of many Mozillians.
I’ve alreadywritten a bit about what happened at the Paris Summit Planning and how it impacted me so I’ll sum up by sharing that when we left Paris the “what’s next?” action was that we each put our names to one of 5 groups where we could be called upon later for ideas/session planning/accountability for that area: People, Process, Product, Strategy, Purpose
Those groups then got turned into three track themes and were assigned two track leads who would work with Steering Committee members on refining the sessions for each as well as with the other delegates from Paris who had signed up to be accountable for those topics. The entire breakdown of this process is handily in a wiki page, but here’s the high level of who’s involved so you know who I’ve been working with for the past month or so:
Purpose & Strategy – Track Leads: myself and Michelle Thorne, Steering Committee: Mitchell Baker and Mark Surman
Products & Technology – Track Leads: Dave Herman and David Ascher, Steering Committee: Jay Sullivan and Brendan Eich
People & Process – Track Leads: Michael Coates and Zbigniew Braniecki (Gandalf), Steering Committee: Debbie Cohen and Jim Cook
The above listed people, along with Dino Anderson and Dia Bondi (and then a whole host of people behind the scenes like Kate, Mardi, and outside contractors) shepherded us through the last month while we did 3 iterations on an agenda in order to get the results you’ll all see this Tuesday. We held a TON of meetings with each other, in our small Track groups, and with our body of delegates from Paris. In our group, Purpose and Strategy, we kept circling back to the Nature of Mozilla (NoM) and how to best transmit that message so it can be held as the core of every Mozillian’s understanding of who we are, why we are, and what we do. We’d have to ask ourselves: Do our sessions have NoM aspects to them? If not, this isn’t the time. The very core of what makes us Mozillian is the key to this experience because it’s at the heart of how we will move into the future with our new projects as well as continuing to properly steer our existing ships in the waters of the open web.
During this process of multiple hour-long or more meetings each week with some serious thinkers & planners at Mozilla, several things happened for me:
I worried sometimes that we had become too narrow, that as such a small group we weren’t getting enough input, yet at the same time I saw new, and very engaged people at the table taking on leadership roles and bringing up strong points. I had to trust that this part of the planning process (similar to with the Paris planning) was for the best and that we’d get the right pieces cobbled together – always with the larger group who will attend & participate in the final product foremost in our minds.
It was reinforced for me many times over how it is for me to participate in meetings that are over 30 minutes long. I’m really going to need to work on that for my own professional development and opportunities in the future. I’m most definitely open to suggestions on how I can ‘game’ my own self to be better at meetings. In TRIBE we learned about the forms of listening and I’ve been aware of/practiced active listening for 2 decades but there’s something about meetings – the group factor, the agendas, getting off topic. Perhaps some training in facilitation might help understand this area better.
At the beginning of our meetings Dino asked all the Track Leads to speak a little about how we work best and I stated that I always prefer *doing* and am at my best with a list of clear steps to take. While I still enjoy talking/dreaming big, at the end of a rousing brainstorming I need that list of “now what?” and it had better be clear what is expected from me next. This planning process was definitely done in a way that met & exceeded my needs in that area. I applaud all the people who are at the top of the accountability chain for the Summit on their skillful communications and guidance throughout the last few months.
I felt incredibly fortunate to be a part of the creation of this next milestone in our shared Mozilla experience. We were *creating* a journey for (almost) all Mozillians to share. Having these touchstones within a project is so important. Being at the table to dream up and then turn into actuality the plan for complete engagement, alignment, and inspiration of what will get us all to the next billion web users is a heady task and I truly believe we’re very much on the right track to providing a creative and engaging space in October that will change all of your lives in good ways.
At the end of our last agenda review, I was filled with excitement about our schedule: Science & Culture Fairs, lots of Open Sessions, something called ‘Speedgeeking’ which I suspect will be like lightning talks, and then the overall story we’re going to learn about but also build into over 3 days. I’m sad that I’m missing almost 2/3 of Summit due to a prior commitment to the Grace Hopper Conference Open Source Day but I’ll join many of you on Saturday evening in Toronto and go deep Sunday so I can get the most out of it.
I hope this explanation of the process helps you understand how many people put in a lot of time to create what you’ll be participating in. Please join us with an open heart to the goals of this gathering – whichever location you end up in – know that we brought in as many of your voices as we could, that we want more than anything for you to get as excited about Mozilla’s future as we’ve been while dreaming about how we’re all going to build it together, aligned and re-energized. See you in October!
If anyone else at Mozilla has a project that can be done in 3 months time (or at least give the contributor a sense of accomplishment and get them very engaged as a Mozilla contributor) feel free to add a project (and a mentor) to the wiki. Applications are being accepted via GNOME until May 1st.
One of my favourite things about this program is that it allows someone to ‘intern’ with Mozilla without the requirement of being a student. If you can help tweet/share the project, that would be much appreciated too. This project has been growing exponentially every session and is making a significant impact to FOSS community and culture.
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 taughtUniversal 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.
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):
changing the background color/images (of the page, game box, card backs)
changing the images on the cards when flipped
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.
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, 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:
* 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.
Poll individual Bugzilla bugs for an autoland token (currently using whiteboard tags, future Autoland has an extension & webservice that makes polling the entirety of bugzilla no longer needed). When an autoland request is found, the serviced does an automated landing to try for you of all non-obsolete patches attached to the bug if they can be landed cleanly on tip of mozilla-central and either the patch author or a feedback provider have appropriate hg permissions, otherwise it reports back to the bug what the issues were. Upon completion of the try run, a comment is left in the bug stating the results and if a final repo destination (or destinations) was specified (the hg permissions must match up between requester/reviewer and the destination repo(s)) the service can continue on to autolanding the patch(es) to the destination repo. A comment would be left on the bug when the push to final destination(s) is done. There would be no reporting back of final build results, that would be handed back over to human eyes on TBPL.
What is Autoland’s status now?
In April of 2012, right before Marc’s second internship ended, we launched a very experimental public-facing version of Autoland and announced it a bit so we could get more people testing it. This had varying degrees of success. We got more bugs ironed out but also discovered that Autoland’s daemons for hgpushing and bugzilla polling tend to fall over a bit too often. When we moved Autoland off it’s staging VM to a more permanent home we lost the status page that would tell us (and developers) what the modules were doing and that really made the workings of Autoland quite opaque. With Marc leaving at the end of April and my switch over to help with Release Management in Feb 2012 I had kept meeting regularly with Marc and driving the project to completion as much as possible but hadn’t been able to pull my weight on coding for the last 3 months of our time together. This left us with an Autoland that stopped working and no one available to continue to massage it into being the robust system we needed it to be. I took mention of Autoland out of our trychooser page, try server docs, and have generally tried to downplay it’s existence while still keeping a plan on the back burner for how we will resurrect it as soon as there is some time.
What does Autoland need to be publicly usable again?
A status page that can show what modules are running or down, display what’s in the queue, and give a quick visual to users if Autoland is up or down as a result.
Nagios alerts on the Autoland modules that let me (and other people interested in helping to maintain Autoland) know when things fall over.
At least one person, if not several, who can access the Autoland master VM and ‘kick’ it as needed
This is what’s needed for a short term solution. I know that we have some bugs with our hg pusher module as well as some trickiness in our message queue that, once fixed, would make the overall system more robust. We need people using the system to be able to catch more of those bugs though, so in the meantime having as close to on-click restoring of the system would be a huge win here.
What does Autoland need to be truly ‘production’ ready?
Security review on the code and the BMO extension so that we can move away from whiteboard tags and let people use the BMO extension instead — this gives much cleaner input to Autoland of what is being requested.
More VMs to run hgpusher modules on so that Autoland can handle a larger load. Each VM can run 2 hgpushers max so we’d want to be able to grow our pushing farm as the usage of the system increases.
Being able to push to repos other than Try.
There is no clear plan to be able to get the system beyond Try landings, but I see automated try landings as still being a huge help so I’d be super happy just to see that part get back to a working state. This project is no longer a RelEng priority now that I’ve permanently moved to Release Management and Marc has gone on to other internships and more schooling. I can’t promise anything time-wise, but I wanted to provide some clarity into what is needed and put out the “patches welcome” call. I see Autoland as being a great option for a community-managed project and I want to keep working on it when time permits. If you are looking to become a Mozilla contributor and are interested in automation and web APIs – this might be a good starter project for you. Please get in touch.
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.
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.
In a timely confluence with Mozilla’s new Steward initiative, I’m preparing to get some community contributors engaged with some of the projects we work on in Release Engineering. A fair amount of our production infrastructure has to be locked behind VPN and sekrit passwords(we have 400+ million users to protect) but there are more and more RelEng side projects. We provide tools to the larger developer community and solve interesting scalability challenges with our unique (and massive) automation systems that can be worked on by any interested person in their own local test environment and then integrated into our /build repos. My personal goal is to try and get 2 or 3 regular community contributors to come work with us on tackling these.
In order to solicit contributions I have been working with David Boswell. We added Release Engineering to the mozilla.org/contribute ‘areas of interest’ page and I have created the beginnings of a RelEng-specific contribution page. The first two areas that I think would be a great introduction to working with RelEng code & tools are the TryChooser and our upcoming Autoland system. For the latter, our intern Marc Jessome is sticking around this fall as a contributor to carry on the amazing work he put into this system over the summer. He’ll be continuing to debug the code and improve the portability of it so that we can get it into a beta testing stage by the end of October. As that work is being done we also need someone to help us write the API functionality that will allow sheriffs and developers to write tools that utilize this new hands-off landing queue. We’d also be happy to have people work on the issues that come up when we take Autoland to the next level – auto-landing on a production branch. To do this we’ll want some automated backing out, bisection, and the ability to wait on getting patches reviewed before continuing.
Another great area for someone interested in helping out Firefox developers is working on the TryChooser syntax and features. There is a whole tracking bug dedicated to try_enhancements and most of those bugs are ones that can be worked on in a local staging environment. It’s a chance to get your feet wet with buildbot and our custom scheduling setup. Some of these smaller bugs would be short on time commitment and high on developer appreciation if you fix them. That can be a winning combination for a new contributor, I speak from experience on that
So, if you’re reading this post and you or someone you know is interested in dipping their toes into becoming a Mozilla contributor and these projects make you curious then come find me and we’ll get you set up with a staging environment so that you can start fixing real world tools and automation bugs in no time.