Head on over to www.lukasblakk.com for all future writing. This blog will stay up as long as Blogger keeps the lights on, but everything here has been transported over to the new site, so don't worry - I have backups!
Thursday, February 23, 2012
Wednesday, February 1, 2012
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:
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:
- 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
- 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
- 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
- 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]
- 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
Thursday, January 26, 2012
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:
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.
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
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.
Tuesday, January 10, 2012
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:
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:
I will continue to organize these events, perhaps once a month. More reports as they happen.
- 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.
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.
Subscribe to:
Posts (Atom)