Steward

Clint Talbert, Lukas Blakk and Henrik Skupin

Note: There are different automation teams at Mozilla (Build Automation, Tools and Automation, QA Automation) and the goal is to provide a simple entry point for people interested in automation and then provide more information to people about the full range of contribution options after they get some initial experience with Mozilla.

Identify Community

Q: Can you identify all of the contributors on your team (both paid-staff and volunteer-staff)?

A: The Automation and Tools community goes by the moniker a-team. You can check us out on mozillians. Folks tagged with the Release Engineering keyword on Mozillians are the people to talk with about getting involved with Build and Release Automation.

Suggestion: Use the mozillians.org contributor directory to help. Communicate through your team's channels and encourage people to sign up and group themselves with a common team tag. If you assign a group tag to all contributors on your project, the Mozillians dashboard will track the size of that group and will also allow you to easily export the contact information for group members. You can export these contacts to ensure all your contributors are signed up.

Define Contribution Opportunities

Q: Can you point someone interested in contributing to your project to a list of available contribution opportunities?

A: The A-Team needs people that work on javascript, python, and web design to help out with a bunch of projects. You can see our areas where we could use help and our current and past projects to see what types of things we do.

Release Engineering needs people to help with python scripting to help automate more of our build & release process, we'd love help with data visualization to make it easier to find patterns in our ever-growing builder pool and build logs, and if you're new to build & release we need help with many simple bugs that don't require account permissions to get involved and will teach you a lot about massively-scaled release infrastructure and the developer-facing tools we provide and plan to build as we continue to get bigger and support more projects Mozilla developers take on. The Try Server/Trychooser is a great place to start, so is Autoland. The details are outlined in our contributors wiki page. A beginner in Python could learn a lot working on some of our automation scripts and digging into buildbot code. We have instructions to help contributors set up local staging environments to be able to run the build & release automation to test their contributions.

Suggestion: Look at what your team's needs are and what gaps you have in staffing to come up with a list of contribution opportunities. Capture those on a wiki page, in bugs, as role descriptions in Jobvite or whatever makes sense for your community.

Map Contribution Paths

Q: Are there clearly understood steps someone can follow to go from knowing nothing about your project to successfully contributing?

A: Yes, we are marking bugs with "goodfirstbug" and each of those bugs has a mentor. You can find that mentor on IRC for more details. We also have a new contributor page that details much of what kinds of setup you'll need to be productive on the team and understand the lingo we use. Most importantly, if you have questions, just ask.

For Release Engineering bugs, perhaps take a look at our "simple" bug query. A great place to start is to read the documentation on setting up a local test environment in our Contributor wiki, give it a try and see if you can set up a local master & buildslave instance. If you have any problems, come chat and ask questions in the #build channel on IRC. Having a local master/builder instance will go a long way towards fixing many Release Engineering bugs. We also can provide data dumps of our scheduler and status databases if you're someone who's interested in playing with data and creating dashboards/APIs/and visualizations.

Suggestion: In addition to just documenting these steps, look for a simple 5-minute task that someone can take to get started (for example, signing up for Bugzilla if they are interested in coding) and also figure out where in the process you can add a mentor to help people.

Establish Goals and Metrics

Q: Can you measure participation or contributors today? If so, what metrics can you track? What goal or metric would you like to achieve for Q1? Alternatively, what metrics would you like to get in place for Q1?

A: We track IRC communication between people not on our core list of contributors in our channel as an indication of the number and involvement of outside contributors in our projects. It's a very rough metric, but if someone is on IRC and interacting with us, that's a very good sign. We also track the amount that our core contributors are blogging because blogging brings us more visibility across the Mozilla project.

As a measure of success for Release Engineering, we would track how many bugs in our component get filed by/assigned to/fixed by contributors. We would also encourage blog posts by anyone who works with our code base and projects as we love having more people discussing the types of problems we work on as well as the hows & whys of the various solutions that are implemented.

Suggestion: Write down what you think would be helpful to track even if it isn't possible to get that data today. We'll work on implementing dashboards when we know what data we want.