Category: all

Catchall for posts.

Artisanal Contributors

Part 1: Start In Person

Ascend had very few ‘rules’ but there was one which was non-negotiable: it’s an in-person program. We didn’t do distance learning, online coursework, or video-based classes. We did bring in a couple of speakers virtually to speak to the room of 20 participants but the opposite was never true.

This was super important in how we were going to build a strong cohort. Don’t get me wrong, I’m a fan of remote work and global contribution as well as with people working from wherever they are. This was a 6 week intensive program though and in order to build the inter-dependent cohort I was hoping to1, it had to be in person at first. Those cruicial early stages where someone is more likely to ‘disappear’ if things were hard, confusing, or if they couldn’t get someone’s attention to ask a question.

It’s been over 5 years since I graduated from my software development program and over 8 years since I started lurking in IRC channels2 and getting to know Mozillians in digital space first. I wouldn’t have stuck with it, or gotten so deeply involved without my coursework with Dave Humphrey though. That was a once a week class, but it meant the world to be in the same room as other people who were learning and struggling with the same or similar problems. It was an all-important thread connecting what I was trying to do in my self-directed time with actual people who could show more caring about me and my ability to participate.

Even as an experienced open source contributor I can jump into IRC channels for projects I’m trying to work on – most recently dd-wrt for my home server setup – and when I ask a question (with lots of evidence for what I’ve already tried and an awareness of what the manual has to say) I get no response, aka: Crickets. There are a host of reasons, and I know more than a beginner might about what those could be: timezones, family comitments, no one with the expertise currently in the channel, and more. None of that matters when you’re new to this type of environment. Silence is interpreted as a big “GO AWAY YOU DON’T BELONG HERE” despite the best intentions of any community.

In person learning is the best way to counter that. Being able to turn to a colleague or a mentor and say what’s happening helps get you both reassurance that it’s not you, but also someone who can help you get unstuck on what to do next. While you wait for a response, check out this other topic we’re studying. Perhaps you can try other methods of communication too, like in a bug or an email.

Over the course of our first pilot I also discovered that removing myself from the primary workroom the Ascend participants were in helped the cohort to rapidly built up strengths in helping each other first3. The workflow looked more like: have a question/problem, ask a cohort member (or several), if you still can’t figure it out ask on IRC, and if then if you’re still stuck find your course leader. This put me at the end of the escalation path4 and meant that people were learning to rely both on in-person communications as well as IRC but more importantly were building up the muscle of “don’t stop asking for help until you get it” which is really where open source becomes such a great space to work in.

Back to my recent dd-wrt experience, I didn’t hear anything back in IRC and I felt I had exhausted the forums & wikis their community provided. I started asking in other IRC channels where tech-minded people hung out (thanks womenwhohack!) and then I tried yet another search with slightly different terms. In the end I found what I needed in a YouTube tutorial. I hope that sufficiently demonstrates that a combination of tactics are what culminate in an ability to be persistent when learning in open source projects.

Never underestimate the importance of removing isolation for new contributors to a project. In person help, even just at first, can be huge.


  1. Because the ultimate goal of Ascend was to give people skills for long-term contribution and participation and a local cohort of support and fellow learners seemed like a good bet for that to be possible once the barrier-removing help of the 6 week intensive was no longer in place. 
  2. By the way, I’m such a huge fan of IRC that I wrote the tutorial for it at Mozilla in order to help get more non-engineering folks using it, in my perfect world everyone is in IRC all the time with scrollback options and logging. 
  3. Only after the first three weeks when we moved to the more independent work, working on bugs, stage. 
  4. Which is awesome because I was always struggling to keep up with the course creation as we were running it, I didn’t realize that teaching 9-5 was asking for disaster and next time we’ll do 10-4 for the participants to give the mentors pre and post prep time. 

Release Management Tooling: Past, Present, and Future

Release Management Tooling: Past, Present, and Future

As I was interviewing a potential intern for the summer of 2015 I realized I had outlined all our major tools and what the next enhancement for each could be but that this wasn’t well documented anywhere else yet.

By coming to Release Management from my beginnings as a Release Engineer, I’ve been a part of seeing our overall release automation improve across the whole spectrum of what it takes to put out packaged software for multiple platforms and we’ve come a long way so this post is also intended to capture how the main tools we use have gotten to their current state as well as share where they are heading.

Ship-It

Past: Release Manager on point for a release sent an email to the Release-Drivers mailing list with an hg changeset, a version, build number, and this was the “go” to build for Release Engineering to take over and execute a combination of automated/manual steps (there was even a time when it was only said in IRC, email became the constant when Joduinn pushed for consistency and a traceable trail of events). Release Engineers would update a config files & locale changes, get them attached to a bug, approved, uplifted, then go reconfigure the build machines so they could kick off the release build automation.

Present: Ship-It is an app developed by Release Engineering (bhearsum) that allows a Release Manager to input the configurations needed (changeset, version, build number, partials to be created, l10n changesets) all in one place, and on submit the build automation picks up this change from a db, reconfigures the build machine, and triggers builds. When all goes well, there are zero human hands between the “go” and the availability of builds to QA.

Future: In two parts:
1. To have a simple app that can take a list of bug numbers and check them for landing to {branch} (where branch is Beta, Release, or ESR), once all the bug numbers listed have landed, check tree herder for green status on that last changeset, submit to Ship-It if builds are successful. Benefits: hands off even sooner, knowing that all the important fixes are on the branch in question, and that the tree is totally green prior to build (sometimes we “go” without all the results because of human timing needs).
2. Complete End-To-End Release Checklist, dynamically updated to show what stage a release job is at and who’s got the ball in their court. This should track from buglist added (for the final landings a RM is waiting on) all the way until the release notes are live and QA signs off on updates for the general release being in the wild.

Nucleus (aka Release Note App)

Past: Oh dear, you probably don’t even want to know how our release notes used to be made. It’s worse than sausage. There was a sqlite db file, a script that pulled from that db and generated html based on templates and then the Release Manager had to manually re-order the html to get the desired appearance on final pages, all this was then committed to SVN and with that comes the power to completely break mozilla.org properties. Fun stuff. Really. Also once Release Management was more than just one person we shared this sqlite db over Dropbox which had some fun quirks, like clobbering your changes if two people had the file open at the same time. Nowhere to go but up from here!

Present: Thanks to the web production team (jgmize, hoosteeno, craigcook, jbertsch) we got a new Django app in place that gives us a proper databse that’s redundant, production quality, and not in our hands. We add in release notes as well as releases and can publish notes to both staging and production without any more commits to SVN. There’s also an API that can be scripted to.

Future: The future’s so bright in this area, let me get my shades. We have a flag in Bugzilla for relnote-firefox where it can get set to ? when something is nominated and then when we decide to take on that bug as a release note we can set it to {versionNum}+. With a little tweaking on the Bugzilla side of things we could either have a dedicated field for “release-note text” or we could parse it out of a syntax in a comment (though that’s gonna be more prone to user error, so I prefer the former) and then automatically grab all the release notes for a version, create the release in Nucleus, add the notes, publish to staging, and email the link around for feedback without any manual interference. This also means we can dynamically adjust release notes using Bugzilla (and yes, this will need to be really cautiously done), and it makes sure that our recent convention of having every release note connect to a bug persist and become the standard.

Release Dash

Past: Our only way to visualize the work we were doing was a spreadsheet, and graphs generated from it, of how many crasher bugs were tracked for a version, how many bugs tracked/fixed over the course of 18 weeks for a version, and not much else. We also pay attention to the crash rate at ship time, whether we had to do a dot release or chemspill, and any other release-version-specific issues are sort of lost in the fray after we’re a couple of weeks out from a release. This means we don’t have a great sense of our own history, what we’re doing that works in generating a more stable/successful release, and whether a release is in fact ready to go out the door. It’s a gamble, and we take it every 6 weeks.

Present: We have in place a dashboard that is supposed to allow us to view the current crash data, select Talos (performance) data, custom bug queries, and be able to compare a current release coming down the pipe to previous releases. We do not use this dashboard yet because it’s been a side project for the past year and a half, primarily being created and improved upon by fabulous – yet short-term – interns at Mozilla. The dashboard relies on Elastic Search for Bugzilla data and the cluster it points to is not always up. The dash is written in php and that’s no one’s strong suit on our current team, our last intern did his work by creating a Python Flask app that would work into the current dash. The present situation is basically: we need to work on this.

Future: In the future, this dashboard will be robust, reliable, production-quality (and supported), and it will be able to go up on Mozilla office screens in the dashboard rotation where it will make clear to any viewer:
* Where we are in the current release cycle
* What blockers remain for releas
* How our stability is (over/under acceptable rates)
* If we’re meeting performance expectations
And hopefully more. We have to find more ways to get visibility into issues a release might hit once it’s with the larger population. I’d love to see us get more of our Beta user’s feedback by asking for it on specific features/fixes, get a broader Beta audience that is more reflective of our overall release population (by hardware, location, language, user types) and then grow their ability to report issues well. Then we can find ways to get that front and center too – including to developers because they are great at confirming if something unusual is happening.

What Else?

Well, we used to have an automated script that reminded teams of their open & tracked bugs on Beta/Aurora/Nightly in order to provide a priority order that was visible to devs & their managers. It’s a finicky script that breaks often. I’d like to see that replaced with something that’s not just a cronjob on my personal VPS. We’re also this close to not needed to update product-details (still in SVN) on every release. The fact that the Release Management team has the ability to accidentally take down all mozilla.org properties when a mistake is made submitting svn propedits is not desireable or necessary. We should get the heck away from that asap.

We’ll have more discussions of this in Portland, especially with the teams we work closely with and Sylvestre and I will be talking up our process & future goals at FOSDEM in 2015 as well as following it with a work week in Paris where we can put our heads down and code. Next summer we get an intern again and so we’ll have another set of skilled hands to put on tooling & web service improvements.

Always improving. Always automating. These are the things that make me excited for the next year of Release Management.

New to Bugzilla

I believe it was a few years ago, possibly more, when someone (was it Josh Matthews? David Eaves) added a feature to Bugzilla that indicated when a person was “New to Bugzilla”. It was a visual cue next to their username and its purpose was to help others remember that not everyone in the Bugzilla soup is a veteran, accustomed to our jargon, customs, and best practices. This visual cue came in handy three weeks ago when I encouraged 20 new contributors to sign up for Bugzilla. 20 people who have only recently begun their journey towards becoming Mozilla contributors, and open source mavens. In setting them loose upon our bug tracker I’ve observed two things:

ONE: The “New to Bugzilla” flag does not stay up long enough. I’ll file a bug on this and look into how long it currently does stay up, and recommend that if possible we should have it stay up until the following criteria are met:
* The person has made at least 10 comments
* The person has put up at least one attachment
* The person has either reported, resolved, been assigned to, or verified at least one bug

TWO: This one is a little harder – it involves more social engineering. Sometimes people are might be immune to the “New to Bugzilla” cue or overlook it which has resulted in some cases there have been responses to bugs filed by my cohort of Ascenders where the commenter was neither helpful nor forwarding the issue raised. I’ve been fortunate to be in-person with the Ascend folks and can tell them that if this happens they should let me know, but I can’t fight everyone’s fights for them over the long haul. So instead we should build into the system a way to make sure that when someone who is not New to Bugzilla replies immediately after a “New to Bugzilla” user there is a reminder in the comment field – something along the lines of “You’re about to respond to someone who’s new around here so please remember to be helpful”. Off to file the bugs!

Why I was part of creating a thing called TransTech(SF)

Last night I helped hold the third local meetup of trans and genderqueer people who are interested in getting together to hack on our projects. This is the third event since the amazing Trans*H4CK  Hackathon (the first one of its kind!) that took place in October 2013.

When I heard through the grapevine that there was going to be a trans-focused, trans-organized, local hackathon I was beside myself.  Finally I would get the combination of identity and technology in one space that I have been dreaming of since going back to school as a mature student in 2004-5 in order to get a degree in Software Development.  My lofty goals in going back to school can easily be summarized in two ways: 1. I wanted to get a better job than being a brunch chef or a non-profit artist-run center, contract employee with no job security or dental benefits and 2. I hoped that whatever I could learn about technology and software would become tools I could bring back to my queer/trans/genderqueer/arts community and help anyone who wanted it at whatever level they ask for.  This has come to mean hosting websites for people, helping build websites for people and small orgs, and also doing some random consulting. It has also led, funny enough, to a certain amount of fixing people’s computers.  That’s nothing I learned in school, it’s just something I seem to have the right combination of lucky and chutzpah to try — ratio of success lies at about 85-90% so far (some things are unfixable, by me at least).

Anyway, I got into tech and got through a grueling 4 years of school with all its associated stresses.  No need to go into details because I finished that thing AND I got a pretty amazing job right out the gate.  Health benefits (specifically the much-needed dental)?  Check.  Ability to help my communities with tech stuff?  Yes….ish.

Turns out it’s not that easy to still be people’s go-to for tech help when you start working more-than-fulltime at a fast-paced company. Also when you move across the country from the majority of your closest friends and aquaintance community.  I made that decision though because I wanted to take the opportunity that existed for me to come here, to SF, and be in the heart of it all.  Little did I know at the time I was walking on stage at a very precarious time (that’s a whole other post).

Skip forward.  I’m lucky enough to have one woman (self-identified to me as a feminist on our first meeting) on my team of 8 people.  So I think tech is pretty awesome. Then she leaves, goes to another team.  Then I go to my first PyCon and swim in a sea of homogenous men I don’t know.  Then I meet a handful of really exciting people who put the words “Queer” and “Tech” on a scrap of paper for a DIY session in the basement of that hotel in Atlanta, 2009.  That is one of the *big* moments.  It’s when I started, with that group of people, to promote teaching Python to women. Based on the success of RailsBridge‘s workshops teaching Ruby on Rails to women (I went to one, Ruby and Rails are not my thing for now) and also the Boston Python Workshop which did a lot of the groundwork for adapting the RailsBridge-style weekend material to a Python version, I ended up starting PyStar with a few people. Our goal was similar:  make it possible for more women to feel comfortable learning Python in a non alpha-male space.  We had a few workshops in SF and Mountain View (Mozilla office space was easy to get and use for weekend workshops). There were groups creating workshops in Philadelphia (still, to this day, the most active city for this project) and in Minneapolis.  I even threw one together in Paris for a night when I was living there for 3 weeks and working from the Paris Mozilla office.

I’m sharing this with you, reader, because this is the backdrop for what comes next.  For me, teaching women to code was…OK.  Don’t get me wrong – it’s important work and I’m glad it’s happening.  For me though, I still felt kind of lonely.  Since the majority of attendees were middle/upper class, young, heterosexual women I wasn’t really connecting on the levels that I do with people who share other similar identities and life experiences with me.  Or at least ones I am more familiar with, if not my own.

I got a bit disheartened by organizing events that I no longer felt I truly connected with and I took some time to try and figure out how to best spend my time and how to be the activist I wanted to be.  Enter GeekFeminism, having several of the people I met through that hired on at Mozilla, PyCon drastically improving its ratio of women attendees (speakers, still being improved), and meeting Leanne.  Over the past couple of years, again keeping it short, I’ve managed to go to conferences and meet lots of people and dream big with them. The LGBT lunches at Grace Hopper have been fascinating.  Getting to attend AdaCamp – huge boost.  Finding people and connecting with them on all the things that are big problems we want to be a part of solving — the one is often comes down to is “How do we get more diversity in tech?”.

At Mozilla I end up making that a second full-time job that is not what I am paid to do (working on that).  Instead I got discretionary funding that I could use to help leverage women in open source which eventually grew into supporting anything with diverse populations that were not prominent or numerically well-represented in open source.  This looked like me being able to offer up the Mozilla office(s) if and when I could be there to hold the space.  It looked like being able to sponsor a variety of events with amounts less than $2k who were promoting, retaining, or otherwise engaging people in tech & open source more specifically.

One of the events I ended up directing money towards was Trans*H4CK because, as I mentioned at the start – I was so frickin’ excited that this was going to happen and I wanted to help it happen.  I reached out to Kortney and offered money, asked if (while I was planning to attend regardless) I could talk for 5 minutes about open source. I did that.  I went and talked and gave my, now usual, talk about why open source is important (think: View Source on webpages and how you might have benefited from being able to do that).  Then I hacked on stuff and met people and generally soaked up what it felt like to be in a space where I felt seen, whole, and just surrounded by people who were also being seen.  We exist, in numbers more than the one or two at your day job! What a fun weekend.

Then I wondered – why just one weekend?  This was in the Bay Area and while a handful of people traveled to the event most were local.  In the style of user groups and meetups, why not continue to have a monthly get-together of this particular blend of nerdgeektransgenderqueer fabulousness?  I proposed this to Kortney, offered up the Mozilla SF space to hold it, got food for the attendees, and we had one in November that was probably attended by about 20 people.  Pretty sweet.  There was a lot more socializing than actual hacking but that happens when people are still so new to getting to be around each other.  With the success of that, I wanted to hold more but I think the holiday period got in the way so the next one I helped put on, this time at the Double Union maker space, was February 18th, 2014.  It being closer to my house and not at the office I rarely go to anyway was awesome, btw. Also I bought snacks with my own money to bring. That night I thought: we need a regular night – say, the third Tuesday of every month, so that it can be something people just *know* is on and can show up to. No need for invites, mailouts, or headcount – keep it simple. I proposed this to the people at the meetup, and thought this was generally agreed upon.

With that in mind, and with a pretty busy schedule coming up, I wanted to get the March date on the Double Union calendar sooner rather than later so a couple of weeks ago I reached out to the membership list asking if the Tuesday night circuit class would be up for sharing the space with another trans hacking night (as that was the best date for me, as the organizer).  They were open to it and all seemed fine but another email thread started up about whether or not the trans hacking nights would be trans-only or not (if they should, even).  This is something, btw, that the TransTech community participants will be chatting more about so as to determine what guidelines and priorities to have when choosing space or setting up meetings. In that thread Kortney expressed concern about not being able to make the date and I said that I was trying to set up the every-third-Tuesday nights, as discussed at the February meeting.  No further response came and I went ahead with booking it (circuit group moved to another night to give us the whole space, thanks!) and setting up an invite.  Double Union still doesn’t publicize their address so the invite was needed to have a way to reach people who said they would attend.  My goal was to use this next meetup to set up open communication tools that could be used by any member of this nascent “we get together and hack on stuff with other trans/genderqueer people” community.  So we did that.

Last night I was at Double Union with some others and I set up a mailing list, a wiki, and IRC channel, and a Twitter account.  I shared all the admin/login details with the others because this isn’t *my* thing. This is, to the best of my knowledge and experience in open source, how we start communities that are as free of bottlenecks on getting things done as possible.  Then I put that information out there.  The goals, again, are to have spaces where trans and genderqueer people who are in technology (or want to learn to be) can meetup to work on their projects or even work on each other’s projects.  I hope we’ll also get to work on projects that help our communities, for example I’m trying to figure out how to help Homomobiles get an app as it drives me nuts to see people using Uber and Lyft when we have this opportunity to put even a sliver of our collective queer and trans money back to a queer and trans organization and help grow it.

All that to say:  There’s always room for lots of ways to bring people together. This is my expression of how I do it.  Mozilla, while being my employer, does not dictate what I do with my spare time and yet I am fortunate in being able to book our office space(s) when available for events.

I’m being told on Facebook and Twitter that this is stealing, that I’m stepping on Kortney’s toes and please believe me, I tried to do everything I could to avoid that. I intentionally sought another name out of respect for the way that I see Kortney branding and promoting Trans*H4CK and how he is doing great things with that.  I see TransCode (teaching coding), Trans*H4CK (hackathons and speaker series), and then TransTech (local community building, mentor/mentee finding, getting things done in a room with people you have that certain connection with) as all being part of the building blocks for continuing a trajectory of making and taking up space in technology for those of us who are outsiders, underrepresented, or just plain want to put our efforts into working with other social justice activists in building trans & genderqueer focused space.

If you’re in the Bay Area and want to know about meetups, be part of shaping this community, or otherwise lurk about to see what might grab your interest down the road then please follow us on Twitter and/or join our mailing list: https://mailman-mail5.webfaction.com/listinfo/transtech-discuss

Let’s support each other in always leveling up.

 

 

 

 

 

I’m looking at you, Gift Horse

a wall of snack food, mostly sugarey
I have to avoid this. All. Day. Which turns into “avoid the office”.

I’m going to say something that might be controversial, or hard to understand for some folks but it’s getting to the point where I’m starting to stay away from the office more than I’d like to so here goes:

The snacks. The never-ending supply that I would *never* eat otherwise. That I would not go to a corner store and purchase. I really wish they were gone. I wish that we, people who all make salaries above that needed for living decently, were accountable for buying and bringing in our own snacks as we chose. Keep them at your desk, share with nearby co-workers, I would love to see this. It would be so much better for me if the only things we had in the kitchen were fruit and veg. Milk for coffee, sure.

When I first started working for Mozilla, as a working class grew up broke kid, I was floored by all the free stuff & free food. I lived off it as an intern to save money. I appreciated it. It made me feel cared for. Now it’s like a trap. A constant test of my ability to make “good” decisions for myself 250 times a day. Often I fail. Failure makes me stay away from the office as an attempt to cope. Staying away from the office causes loss of connection with you all.

I suspect there might be feelings of being ‘punished’ if the snacks were less abundant (or even gone) because we’re used to all these ‘perks’ in our tech offices. It’s not something most offices (outside of tech industry) have and I would encourage a perspective shift towards accountability, recognizing the privileges we *already* have even without free all-day snacks, and thinking about what it means if some people have to choose to stay away.  Considering the origin of these snacks is from a startup mentality where workers were expected to be pulling really long hours without getting up, out, or going home.  Is that really what we want to promote and call a perk?

Contribution opportunity: Early Feedback Community Release Manager

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.

You

  • 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

We

  • 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!

 

 

Planning a Summit is hard, let’s go shopping

Hello fellow Mozillians (and curious onlookers)!

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 already written 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!

 

Women Hacking Glass – First SF community meetup

I’ve created an event for the first meeting of Women Hacking Glass in SF at the Mozilla public space.

Since I posted in G+ a few weeks ago things got busy and I didn’t have time to lean on Google like I’d planned to ask for hardware but then a pair of Glass practically fell in my lap when a coworker decided he didn’t want to be an Explorer any more so I wrangled a ‘donation’ to get his Glass in order to use them for community hacking with other women in the Bay Area.  I’m curious to see how the first meetup goes – what will we be able to create?  What kinds of feedback will we provide to the GDK developers who are working on the first version of a release?  What kinds of barriers will we hit with Mirror API?  I look forward to learning about everyone’s hopes and dreams for this exciting hardware and finding ways to hack our way to making them a reality.

Copy from the event invite:

Are you interested in learning how to make apps for Google Glass?  Don’t have the access to the hardware?

Come out to Mozilla SF and meet with other Glass Hacking gals to experiment with Android Studio, creating simple apps, getting access to Mirror API, and trying out your hacks on an actual pair of Glass that will be made available during WHG meetups for testing on.  Since there are very few people out there with the hardware, and few of those early adopter/explorers are women let’s work together to increase the numbers of women getting in on the ground floor for development (as well as being able to provide feedback to Google GDK developers) on this revolutionary new hardware.

There is a small (non-refundable) fee to prevent no-shows from taking up space – all money generated from this event will be donated to Mozilla Foundation via http://www.mozilla.org/donate

Prepare ahead of time:

* Have a google account

* Read https://developers.google.com/glass/quickstart/index and do as much of the pre-installation of tools/IDE that you can

* Think about your first app and what you want to learn to build

* Dream big, show up

For people who are interested in applying pressure to Google and showing them there are women interested in developing for Glass (the current Glass Developers group is easily 95% male) – go to http://www.google.com/glass/start/how-to-get-one/ and submit your request anyway, even though they say the waitlist is full.  My coworker can’t be the only person returning his pair and I trust Google will open more spots when they see a lot of interest.

Challenge: No more new clothes for one year

I need a place to record that on July 2nd I purchased the pieces for a tuxedo and took my lady out to the opera. At that point, and even before then, I’ve been realizing that I have _enough_ clothes, shoes, jackets, socks, underwear. There is nothing that I _need_ or am missing in my sartorial life. I’d like to spend less frivolously. I’d like to not contribute to the sweatshops that make a lot of our off-the-rack clothes. I miss thrifting outfits and I should really support the good causes that run thrift stores. For those reasons and others, I am going to try and make it one year without purchasing any more new clothing. I’ll unsubscribe from some of my favourite haunts so as to not get taunted by sales and new items. I think it won’t be that hard but we’ll see. July 2, 2013 was the last time I purchased a new clothing item. One year, here we go.

Trust Process

This is the first in a series of blog posts that will summarize my experience and takeaways from the Mozilla Summit 2013 Planning Assembly that took place in our Paris, France office on June 14-17, 2013.

✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈

We are a group of very smart people. Don’t ever doubt that for a second. We are a hit-the-ground-running bunch of doers who really like actionable items and clear instructions as well as accountability and deliverables. Oh and throw in some metrics and a post-mortem so we can iterate, please. This makes us very challenging for outsiders to work with, especially when trying to engage a sizable group in open process activities. Turns out we’ll ask a lot of questions to clarify instructions, search high and low for actionable items, and demand deliverables. We’ll interrupt process, we’ll doubt the value of the process, and we’ll assume even before attempting that it is too open-ended to be of value or to generate the tangible items we’re craving as the proof our time was well spent.

If we go too far down that path in this unconference style of meetup, we will lose out tremendously on letting ourselves be changed and engaged by each other.

Love it or hate it, asking each other “is this making sense to you?” or “are we doing it right?”,  that uncertainty IS a big part of process. Asking each other questions, being confused together, not knowing what’s coming next together is a form of bonding.

Bonding – which I shall refer to from now on as friendship – typically strengthens over equal parts of time spent together + common interests + shared experience. Sometimes you can fast forward a friendship by just overloading one of those areas. Having a particularly intense experience with someone (eg: riding a roller coaster), spending a lot of consecutive time (eg: traveling together), and connecting intensely on a common interest (eg: hacking) are all examples of ways to ramp up the development of a strong bond with another human. When attending a Summit we are provided a multitude of opportunities to have many of those three with a variety of Mozillians we normally might not interact with, and sometimes with ones we do – deepening connections is the ‘bonus’ to the work we get done when we assemble en masse. My most remembered experiences at Summits, All-Hands’, Moz Camp, and other larger gatherings with Mozillians have always been about the micro interactions which are not  part of the schedule. Walking to dinner, sitting on the bus, playing Rock Band – those are opportunities to look at the person or people around you and to try to make sure you’re getting to know even a little bit about them.

In the very earliest part of our process for the weekend of discovery and digging into the meat of what should drive our Summit planning a question came up about whether we could affect the decision to have the Summit in 3 different geo-locations.  Just that one little detail was something many people were tripping over and wanted to discuss and it was clear our dive into the weekend’s process would be held up until there were answers. What ended up happening was Mardi explained how logistically they had looked at previous Summits & large gatherings and had determined that 600 people seemed to be the largest number of Mozillians in one place where there still could be a ‘cozy’ feeling that allows for the kind of bonding previously mentioned.  Once Mardi said this, I was changed.  I, too, had wondered about the dispersal but now it made sense to me that the importance of connection between Mozillians had been placed before the need to put us all in one location and  I appreciated getting this new perspective on what the process had accomplished already.

Mitchell then spoke about how sometimes we get hung up on comparing one thing to another and are quite vocal if we find it wanting.  It’s important for us to have this gathering, this alignment exercise for the project as a whole, and if we don’t want to call it a ‘Summit’ because it’s not everyone in one physical space then call it something else in your head.  I found her point to be very inspiring and concluded that it’s important to go to this 2013 gathering – at whichever location – and BE there.  Do not waste time comparing it to other events, attend the event you’re at and reflect later. For me, this was when I knew I could trust the weekend’s activities would lead to great things and more changes of my tightly held beliefs I came into the weekend with.  There will be more about this in future posts.

Thanks, Process.