Want to help? Encouraging community contributions

In a timely confluence with Mozilla’s new Steward initiative, I’m preparing to get some community contributors engaged with some of the projects we work on in Release Engineering. A fair amount of our production infrastructure has to be locked behind VPN and sekrit passwords (we have 400+ million users to protect) but there are more and more RelEng side projects. We provide tools to the larger developer community and solve interesting scalability challenges with our unique (and massive) automation systems that can be worked on by any interested person in their own local test environment and then integrated into our /build repos. My personal goal is to try and get 2 or 3 regular community contributors to come work with us on tackling these.

In order to solicit contributions I have been working with David Boswell. We added Release Engineering to the mozilla.org/contribute ‘areas of interest’ page and I have created the beginnings of a RelEng-specific contribution page. The first two areas that I think would be a great introduction to working with RelEng code & tools are the TryChooser and our upcoming Autoland system. For the latter, our intern Marc Jessome is sticking around this fall as a contributor to carry on the amazing work he put into this system over the summer. He’ll be continuing to debug the code and improve the portability of it so that we can get it into a beta testing stage by the end of October. As that work is being done we also need someone to help us write the API functionality that will allow sheriffs and developers to write tools that utilize this new hands-off landing queue. We’d also be happy to have people work on the issues that come up when we take Autoland to the next level – auto-landing on a production branch. To do this we’ll want some automated backing out, bisection, and the ability to wait on getting patches reviewed before continuing.

Another great area for someone interested in helping out Firefox developers is working on the TryChooser syntax and features. There is a whole tracking bug dedicated to try_enhancements and most of those bugs are ones that can be worked on in a local staging environment. It’s a chance to get your feet wet with buildbot and our custom scheduling setup. Some of these smaller bugs would be short on time commitment and high on developer appreciation if you fix them. That can be a winning combination for a new contributor, I speak from experience on that 🙂

So, if you’re reading this post and you or someone you know is interested in dipping their toes into becoming a Mozilla contributor and these projects make you curious then come find me and we’ll get you set up with a staging environment so that you can start fixing real world tools and automation bugs in no time.

Try results to the bug(s) of your choice upon completion

The TrySyntax helper and TryChooser wiki docs have both been updated to reflect the new option when pushing to try where you can now ask to have your complete summary of results (and a link to the tbpl page for your revision) posted as a comment to the bug on completion. Here’s a live example to check out:

Sample comment in a bug when using –post-to-bugzilla in your syntax.

Now you have more control over how you get your try results and how noisy a try push is.

Please send comments and issues to the bug tracking this work. Thanks for trying it out!

A quick morning rant about “gender” and data collection

This morning I read that Google+ is going to make your name and “gender” required to be public if you want to participate. This bothers me for several reasons:

Web sites and forms notoriously say “gender” when they mean “sex” and only put M/F or Male/Female as options. When this type of choice is required but called “gender” it erases many people who do not feel that those options cover their gender since that is actually something way more mutable than your assigned sex at birth. Solutions: Call it “sex” which is really what those two categories are or don’t make something that is not in fact binary into a required choice of two options.

Google are so proud of being all scientific and data driven and I’m frustrated that they would not take the opportunity on their new potentially game-changing social platform to re-vamp data collection. Don’t they have the processing power to allow people to put in whatever they like as “gender” and let the power of the search sort things out in the end? If a small number of people want to put “jedi” or “dog” let those people find each other! Who cares if there are some people who don’t feel like Male/Female defines them? Why Google? Why do you want to act like two boxes can cover the breadth of human experience as it relates to gender in this world? Why can’t you innovate on the small things as well as the big things that affect human interactions?

I’d really like to see a shift in how we collect data where there is more trust that the user knows who and what they are and that they want to share this information at their comfort level and that those on the other side, let’s call them advertisers (cause isn’t that what it all comes down to?), be the ones to deal with the outliers and uniqueness of human experience instead of trying to bash everyone into a two-party system.

Sidenote: When I have collected data recently for PyStar and allowed the gender field to be a text box I have found that the expected percentage (98%) of people entered “typical” information like woman, girl, female and that those who needed to express a different response appreciated the ability to do so by entering something else. Leaving this field to user input choice did not result in a messy, chaotic list of random words or unidentifiable descriptors. I fear not that most people will suddenly start to be something else when given more autonomy on forms.