Contribution opportunity: Early Feedback Community Release Manager

Did you make a New Year’s resolution to build out your software development skillset with a focused contribution to an open source project? Do you want to work with a small team where you can have a big impact?

We’re once again looking for someone committed to learning the deepest, darkest secrets of release management when shipping a big, open source software project to half a billion users. Our small team of 3 employees already has one contributor who has been a consistent volunteer for Release Management since 2013 and has worked his way from these tasks to taking on coordination and growth strategy for the Extended Support releases. Our commitment to contributors is that we will do our best to keep you engaged and learning, this is not grunt work, it’s deep participation that matters to the organization and to the products we ship.

You’ll need to consistently commit a 1-3 hours a week to helping analyze our Nightly channel (aka mozilla-central or ‘trunk’) and raise issues that need prompt attention. The very fabulous volunteer who takes on this task will get mentoring on tools, process, and build up awareness around risks in shipping software, starting at the earliest stage in development. On our Nightly/trunk channel there can be over 3000 changes in a 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 burnout which can lead to communication irregularities with the volunteer and make them feel unappreciated. For this community release manager position I will dedicate 1-3 hours each week to actively on-board and guide this community Release Manager contributor in order to ensure they get the skills needed while we get the quality improvements in our product.

Here is the “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 half a billion 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
Can commit to at least 6 months (longer is even better) of regular participation – this will benefit you by giving you time to really get hands-on experience and understanding of release cycles

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 a mission-driven org)
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: select attendance at team & company work weeks – access to engineers, project managers, and other functional teams – get real world experience in how to work cross-functionally
Provide work references about how awesome you are, various swag, 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 video chat. The best part is you can be anywhere in the world – we can figure out how to work a schedule that ensures you get the guidance and mentoring you’re looking for. Reach out to me in IRC (lsblakk), on Twitter (@lsblakk) or email (lsblakk at mozilla.com).

Look forward to hearing from you! Let’s roll up our sleeves and make Firefox even better for our users!

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!

Ascend Project Kickoff

Last year I approached Debbie Cohen, our C-level People person, and made a proposal. With all these Hacker School/Dev Boot Camp/Hackbright accelerator programs popping up, I had an idea to create an open source version and specifically target participants who come from underemployed, LGBTQ, Latin@, and African American populations – aka: people who are terribly underrepresented in tech but also very much more so in Open Source. The idea was that instead of people paying to come learn to become developers in the capitalist, Startup-focused, feeding-frenzy the Silicon Valley promotes we could instead seed other towns, other communities with open source and create an in-depth technical contribution training program that more mirrored the experience I had with Dave Humphrey at Seneca College. Imagine my surprise when Debbie clearly, and without hesitation said to me “Great idea! Do it!”. I’ve been building up to something that is more sizeable through running local events, hack meetups, participating in community building in several ways so I saw this proposal as the next step for me, as an organizer. This time I’m going to do something that is bigger than what I could do alone. I will have Christie Koehler working with me as well as several community building team members in advising and mentoring roles.

The populations I want us to reach out to have resulted in certain adjustments to the typical setup of those for-profit accelerators which I see as being key to the potential success of our cohorts. Attendees in the Ascend Project will benefit from taking this course in the following ways, which are intended to remove many barriers to participation in Open Source:

a $50 per day honorarium will be provided to encourage regular attendance and help ensure participants can afford to focus on being present to learn & develop
laptops will be provided to use during the course and upon completion, graduates will get to keep theirs
food (breakfast and lunch) will be provided every day
where needed, childcare stipends are available to participants who need additional care in order to put in the time this course will request of them
transit passes for the whole 6 weeks

The purpose here is to not only acknowledge that we know we’re missing people in our open source communities but that we’re willing to put our money and time where our mouths are to go and explicitly invite people who like to solve problems to come and see what it is like to get to just focus on learning, developing, fixing a bug, getting hooked, being a part of a bigger community with a mission for global good. I see this as a solid way to counter the manner in which many of these populations are pushed away from participation in computer science and open source contributions.

We can’t expect every person who might be a strong, longtime, and impactful contributor to Open Source to find us based on passion alone. That leaves all the systemic issues in society to decide for us who gets here. If we can remove some barriers and provide an environment where participants in a program get a chance to feel confident, trusted, strong, and *wanted* then we can see how that might blossom their abilities to learn and contribute to an open source project that has a ton of pathways for potential input and impact.

The project is currently still in the kickoff phase so this is the first public post. Mostly I’m braindumping, trying to work backwards from September when the course will start, and getting my head around who will do what so we get everything ready in time. I’ve got a budget for the first pilot, which will take place in Portland, OR in the Fall of 2014, and it’s almost approved. Next up I will be designing the curriculum while Christie works on partnerships locally in preparation for our call for applications. We’ll be doing our best to reach far outside the typical degrees of separation to get word out and to attract applicants. I’ll be in Portland next week to meet with local orgs and gather information on where we can promote the project.

Applicants will go through several steps before we whittle down to our final 20. There will be an expectation that they can complete the highest level of a free, online Javascript course and the Mozilla PDX office will hold drop ins with computers available to help applicants have the time to do this with the right equipment and a mentor or two nearby. Following that stage, we’ll ask for an essay or video that briefly describes a ‘hard’ problem the person had to solve, if they were successful what worked and if not what didn’t. Staying away from specific, alienating technology language seems key here. We need problem solvers and self-starters, not people who know syntax (yet). That group will then be the pool from which the final participants will be selected from, with specific ratio targets for populations that I mentioned earlier.

The first session, as a pilot, will have certain ‘training wheels’ on it. Mozilla has a great space in Portland. Portland has a wonderfully large open source community I fully expect to tap into for networking and partnerships. We’ll be using this first pilot as a way to test the participant selection process and the curriculum itself. I really want to be setting people up for success. This is measured by committing at least one patch to production code (in any area of Firefox) before the end of the course. Our first course will focus on Mozmill automated testing because we can get our participants to that level of success with independently-written JS tests for several of the Firefox products.

Following Portland we’ll be reviewing, updating, improving, and then taking the next pilot to New Orleans in January of 2015 where we can test “what happens if we don’t have an office, a large community already in place?” with our tightened up selection process and curriculum. The two pilots should give us lots to go on for how to scale up an initiative like this going forward and hopefully it can become something that happens more frequently, with more teachers, and in many more places (like in some of our Firefox OS launch markets).

That’s the gist for now. I’ll be posting more frequently as we hit milestones in the project and also am happy to take people up on offers to review curriculum.