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!

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.

Tomahawk does many things right

Not too long ago I first heard of Tomahawk at one of our Mozilla Monday meetings – they’ve been working with our WebFWD initiative which supports open web projects that are moving the web forward. Tomahawk definitely fits the bill for what the future of the web should be: music just plays. Social, distributed, easy access to tunes through all the open APIs available – I can’t even begin to say how happy I am to be finally able to use this software.

I say ‘finally be able to use it’ because when I first heard of Tomahawk and ran to their site to download it, I stopped in my tracks.

Their original logo was a stereotype cartoon of a North American Indian male, wearing headphones. I’ll let you do your own research if you want to learn why such a depiction isn’t culturally sensitive because that’s not actually the point of this post. The point is that the people behind Tomahawk did constructive criticism a solid. When, as a potential user, I saw this logo and took action by emailing them asking them to consider changing this inappropriate and stereotyping imagery as their masthead and application icon they said other people had contacted them as well, so they were aware and they were WORKING ON A NEW LOGO.

They didn’t get defensive, they didn’t say “we don’t see a problem here”, they didn’t try to justify their choices and protect their precious artwork. They were already working on a solution, continuing forward momentum, adapting as they went, and being civil about it to boot. Who knows how many people contacted them? I might have been the thousandth and yet there was no hint of snark or beleaguered engineer who just wants to write software and not deal with all this soft, people-facing stuff in the response I got from Jason Herskowitz. Thank you for that, Jason and Tomahawk. I really hope this level of maturity catches on in the startup culture.

To give you an idea of how quickly they rotated on this; I emailed on May 14th and the new logo went into place today. That’s slightly more than a month to revamp their site and update their installer and god knows what else (maybe business cards? stationary? do people still use that?). This change isn’t trivial, but neither is the impression that original logo makes about a company. I will proudly go forth now and rally support for this product that I have no doubt is stellar. I’ve been using it for the last 10 minutes since getting the email that the new logo was in place and let me tell you: setup was a breeze. I can also share this experience as a positive one with regards to taking the time to contact a company and point out a culturally insensitive aspect and seeing effective, mature, and expeditious resolution on that issue. This is still rare enough to deserve an entire blog post. I look forward to a future where this sort of thing is a more common dialogue and is always met with positive change and continued forward momentum instead of stop-energy and defensiveness.

Here’s the plug now: Get Tomahawk! It’s open source! It will work with many, if not all, of your current web music accounts! Support the open web and companies that move it forward!