Starting a new year often makes me think about reviewing and reorganising, which is exactly what we’ve recently done with our GitHub teams. Until now we had two teams: one granted members administrative access to all of our repositories, and the other gave read access. This means if we wanted to grant a particularly active and trusted contributor with the power to merge pull requests and push directly to our repositories then we also had to give them total administrative control over those repositories! Needless to say there are currently very few contributors that therefore have this ability. Since our review we now have three teams with admin, write, and read access.
Web QA Enthusiasts – This team (previously known as Web QA Community) is our read-only team. Any members of this team can open issues, assign issues to themselves or have issues assigned to them, and edit their own comments. Anyone is welcome to become a member of this team and we intend to regularly add any active contributors. In fact, you may have recently been notified that you’ve been added to this team – if so, welcome!
Web QA Apprentices – Our apprentices are regular contributors that we’ve granted write access to our repositories. Any Web QA staff member can propose a new member of the team, and if there are no objections then they’ll be added. We intend to review active contributors each quarter to see if anyone would like to propose new members. We’ve also decided that we’ll annually review the members and unless there are objections anyone in this team that has not been active in the last 12 months will be removed. This will help us to keep the membership limited to an approved few of our most active contributors. If you’ve recently been removed from this team then this is likely to be the reason. The first new member of this team is Justin Potts, who has contributed significantly to several projects. Thank you Justin, and welcome to the team!
Web QA Sorcerers – The sorcerers are the administrators of our repositories. Membership is limited to Web QA staff members. This allows us to give write access to our projects without worrying about giving away administrative control. We’ll be regularly reviewing membership to ensure that we keep a tight control of this team.
If the names are familiar that may be because we’ve reused them from our Web QA badges. I should point out however that earning a badge does not mean automatic membership of the team with the same name. Find out more about our badges (and how to earn them) here.
Another part of this review was making sure our teams had a synchronised list of repositories. Each team has the following core repositories associated, which will be reviewed on a regular basis to ensure we do not add unrelated repositories. Note that inclusion in the following list does not indicate that the project is actively contributed to – some are in fact dormant.
addon-tests, affiliates-tests, bidpom, bouncer-tests, browserid-tests, flightdeck-selenium, input-tests, marketplace-tests, marketplace-tests-gaia, mcom-tests, mdn-tests, moz-grid-config, mozillians-tests, moztrap-tests, mozwebqa-bot, mozwebqa-dashboard, mozwebqa-examples, mozwebqa-test-templates, oneanddone-tests, pytest-mozwebqa, qmo-tests, remo-tests, snippets-tests, socorro-tests, sumo-tests, webmaker-tests, webqa-infrastructure-requirements, wiki-tests.
Reviewing the team members and repositories was made much easier by using the GitHub API and Octokit.rb. Here’s the script I created, however you would need to have the appropriate authentication and permissions to run this against Web QA’s teams.
If you’re interested in contributing to any of the Web QA projects (and potentially being our next enthusiast/apprentice) the best place to find out more is the team’s page on QMO – our site for all things quality.