|Got a question?|
| Email github-owners mozilla.org |
- 1 News
- 2 Recommendations and FAQ
- 2.1 Where should I ask additional questions?
- 2.2 How do I hook up a new 3rd party application to a repository in the mozilla org?
- 2.3 Reviewing owners and permissions
- 2.4 Can I be an Owner of the Mozilla Organization?
- 2.5 Can I be a Member of the Mozilla Organization?
- 2.6 Should I make a separate github organization or just create a repository in an existing one?
- 2.7 Forking vs Transferring
- 2.8 Do I need to be an owner to create repositories?
- 2.9 Are there requirements for when or how I should create a new team?
- 2.10 Is "mozilla" the only github "organization" related to Mozilla?
- 2.11 Are there other unofficial or Mozilla-related repositories hosted on Github?
- As of June 20, 2016, all members must have 2FA enabled. You have been notified if this impacts you.
Recommendations and FAQ
Where should I ask additional questions?
- Send an email to github-owners mozilla.org and we'll respond right away! We're also available on #github on irc.
How do I hook up a new 3rd party application to a repository in the mozilla org?
Note: There are now multiple 3rd pary application types. "Integrations" are the new approach and preferred.
3rd party applications can easily impact many other repositories than the initial one. For that reason, the following steps are strongly encouraged. Note that there are three ways 3rd party apps can be associated with the entire organization, or a specific repository:
- via a manually configured webhook. This type of installation is not automatically affected by the other approaches.
- via an "Integration", which is connected by "Installing" it into the target. (This is the new, preferred way.)
- via granting access via OAUTH tied to the installer's credentials. (The old way.)
Integrations are "Installed" into either the entire organization, or into individual repositories, and are not tied to the permissions of the user who does the installation. Each integration has a documented, granular, access to various of the repository resources. This is good.
However, the installation can only be done by an organization owner, who may have to do additional housekeeping. This is not so good, so please plan accordingly (you may need to coordinate with GitHub owners).
If this is the first time this Integration is being installed in the organization, a few extra checks and coordination are needed. An organization owner will need to perform these steps:
- Determine if the integration previously had an OAUTH version.
- If so, it is likely that installing the integration will disable all repositories in the organization using the OAUTH version of the application.
- Find all current repositories using the classic OAUTH application (this is non-trivial, scripts exist to help)
- Install the Integration for all current repositories, and the new one (organization owner permissions needed.)
- Please do not install integrations with organization wide scope without first discussing with GitHub owners.**
Additional Installations or Removals
If the integration has already been installed in the organization, the new repository simply needs to be added or removed from the list. An organization owner has to make this change.
OAUTH (classic) Applications
- Create yourself a new github user for this repository.
- Make them an admin of the repository(s) temporarily.
- Sign in as the new github user and setup the 3rd party application.
- Log back into your normal account.
- Try to reduce access of that user from an admin of the repository(s) to read only access.
- If (5) doesn't work, at least the 3rd party application will not have access to all of your normal github account's (including private repositories).
- Authorizing an application to work with GitHub utilizes the permissions your account has -- so, any repositories you have access to the application will have access to as well (including private ones). If you want to grant access to an application that no one else has used with the Mozilla organization yet you'll see a "Request access" button during the set up flow. You'll need to click that button to request approval. See below for an example:
- In some cases, the application does not need to be "approved" to function correctly, as it has read only access to any public repository. (Some applications only want write access to help you configure the application first time.)
- In other cases, the application does need write permission, and/or permission to read a private repository. In these cases, it is helpful to send the details to the owner's team, either by opening a bug or email.
Reviewing owners and permissions
As an owner or repository admin you're responsible for maintaining the list of people with access to your projects. Please be active and prudent about maintaining this list.
Can I be an Owner of the Mozilla Organization?
The Owners group on GitHub has complete administrative power and will be limited to a minimal number of people and reviewed regularly. If a person is an owner, they are expected to actively participate in the group and assist others as requested. Owners will be added as a need arises (for example, support in another timezone) as determined by the current owners.
Can I be a Member of the Mozilla Organization?
Good news! You do not need to be a member of the Mozilla organization on GitHub before you can contribute to Mozilla!!!! We have several sites which can help you find the best fit for contribution:
- General volunteering options,
- Or pick from these areas,
- Or jump right into fixing a bug.
- If you're already a contributor (THANK YOU!) looking for a place to have your work recognized (even if not coding related), please see the Credits FAQ for inclusion in the credits.
Once you're working on a project, the project leaders can help you get access to anything you need.
Team Maintainers & Project Leads
Project owners and team maintainers may find the following information helpful when asking for access for a new team member:
- With recent GitHub enhancements (2015), we encourage the following (rough) guidelines, which strongly prefers using github teams. As a reminder, all members of the Mozilla organization on github agree to be bound by Mozilla's Commit Access Requirements, and should follow the intent of the Mozilla's Commit Access Policy as much as practical.
- "Outside Collaborator": repository admins can grant outside collaborator to any GitHub account. "Outside Collaborator" is roughly analogous to "Level 1a" access to Mozilla-hosted repositories.
- "Team Member": team maintainers can add GitHub users to a team, if they are already a member of the organization. If you are not yet a member of the organization, the team maintainer should request your addition to their team, as a form of vouching. "Team Member" is roughly analogous to "Level 2" or "Level 3", with the distinction being the content of the repositories managed by the team.
Note: As of January 6, 2017, we will start cancelling any invitation to the organization which is not accepted within 2 weeks of the invitation.
Note: As of June 30, 2016, all members of the Mozilla organization on GitHub MUST have 2FA enabled.
Note: Automation accounts are also required to have 2FA enabled. Scripts should use access tokens with minimum permissions to accomplish the task.
The best way to ask for a Contributor to be invited to the organization is to open a bug including the contributor's GitHub login, and the team(s) they need access to. A team maintainer or manager should approve in the bug.
Should I make a separate github organization or just create a repository in an existing one?
This is a personal preference. If you have a large enough project or organization feel free. We suggest you use the strategies and recommendations here as a model to manage the details.
Forking vs Transferring
Do not "fork" a repository into a Mozilla organization. Doing so gives every team in the org rights to it.
If you have created a repo on your own account (for example, myuser/myrepo) and it should live under the Mozilla organization, here are the steps:
Note: As soon as you transfer, your repository will be in "limbo" (only you will have write access) until you get the assistance of an org admin who can make the changes. Please plan in advance if timing is critical.
- If you're not a member of any team, talk to an org admin.
- Under the repo admin, transfer ownership to the Mozilla organization. If you don't see this option, return to step 1.
- Choose which teams should be given access. All chosen teams will have only 'read' access at this point.
- Ask an org admin to grant team permissions higher than read ('write' and 'admin' are the other choices). (Team maintainers do not have the ability to change a repositories status.)
- Fork the repo from Mozilla (mozilla/myrepo) back to your account (recreating myuser/myrepo). While the transferred repo becomes the root of the network on GitHub (e.g. all forks are now forks of mozilla/myrepo) other users may be pointing to your repo by URL. (Optional, github will redirect old URLs for transfers, but you probably want a local repo if you use the PR workflow.)
Do I need to be an owner to create repositories?
No. If a person has read/write access to another repository in that organization they can make more repositories in that organization. However, it's preferred that you create repositories in the context of a team. Teams are created here, if necessary. Once you have created a repo, you can configure it to give rights to members of particular teams.
Are there requirements for when or how I should create a new team?
No. When requirements were proposed they all seemed too rigid and time consuming. Instead we recommend staying flexible and using good naming and documentation for projects (similar to naming CSS classes or variables).
On large teams we recommend you separate teams for read/write and repository administration.
No, there are plenty of Mozilla-related "organizations" on github. As a rule of thumb, initiatives that create a large number of sub-repositories will create their own "organization". Here is a (probably incomplete) list of them:
|mozilla-it||Mozilla IT's repositories||?|
|bugzilla||Bugzilla (the product, not bugzilla.mozilla.org)||#bugzilla|
|drumbeat-badge-sprint||Drumbeat Badge Lab||?|
|mdn||Mozilla Developer Network||John Whitlock|
|mozbrick||Mozilla Brick (web components library)||?|
|mozilla-b2g||Mozilla Boot2Gecko / Firefox OS||?|
|mozilla-cit||Mozilla Community Ops||Tanner Filip (tanner) or Yousef Alam (yalam96)|
|mozilla-comm||Calendaring and Messaging related projects||?|
|mozilla-cordova||Firefox OS Support for Apache Cordova||?|
|mozilla-iam||Mozilla's identity and access management||?|
|mozilla-platform-ops||Mozilla Platform Operations||Platform_Operations|
|mozilla-raptor||Mozilla Raptor / Firefox OS Performance||Eli Perelman (eliperelman), Rob Wood (rwood)|
|mozilla-releng||Mozilla Release Engineering||#releng|
|mozilla-services||Mozilla Services||mozilla-services owners|
|mozilla-svcops||Mozilla Cloud Services Ops||Daniel Thornton (relud)|
|Mozilla-TWQA||Mozilla Taiwan QA||?|
|MozillaScience||Mozilla Science Lab||?|
|MozillaSecurity||Mozilla Platform Fuzzing Team master repo with many fuzzing tools under it.||?|
|MozillaWiki||MozillaWiki (wiki.mozilla.org)||Christie Koehler (ckoehler), Gordon P. Hemsley (gphemsley)|
|mozillayvr||Mozilla Vancouver @MozillaYVR||Brian Clark (bclark), Stephanie Hobson (shobson)|
|mozfr||Mozilla Francophone||Pascal Chevrel https://mozillians.org/fr/u/pascalc/|
|rust-lang||The Rust Programming Language||Aaron Turon (aturon)|
|servo||Servo (browser engine written in Rust)||Lars Bergstrom (larsberg), Jack Moffitt|
|tabulapdf||Tabula project (extract data from PDF files)||?|
|webcompat||Web Compatibility Team||Mike Taylor (miketaylr)|
|mozilla-l10n||Mozilla l10n-drivers team||Pascal Chevrel https://mozillians.org/fr/u/pascalc/|
|taskcluster||TaskCluster Team||Greg Arndt|
|MozillaCH||Mozilla Switzerland||Michael Kohler (mkohler), freaktechnik (freaktechnik)|
|mozmar||Mozilla Marketing||Benjamin Sternthal (bensternthal), Paul McLanahan (pmac)|
|mozilla-payments||Implementation of Web Payment APIs||Caceres Marcos Caceres|
|mozilla-jetpack||Resources for Mozilla's Add-on SDK||?|
|web-ext-experiments||WebExtension API Experiments||Andy McKay (andym)|
Why, yes! In no particular order:
- https://github.com/kinetiknz/nestegg/ : WebM demuxer
- https://github.com/xiph/opus/ : Modern audio compression for the internet.
- https://github.com/webmproject/libvpx : Mirror only. Please do not send pull requests.
- https://github.com/campd/fxdt-adapters : Firefox Developer Tools protocol adapters
- https://github.com/bbondy/codefirefox : Video and exercise based tutorial site for coding Firefox and other Mozilla related technology
- https://github.com/nickdesaulniers/where-is-firefox-os : A map showing where in the world Firefox OS phones are being sold.
- https://github.com/jdm/bugsahoy : A landing page to make finding relevant bugs easier for new Mozilla contributors.
- https://github.com/w3c/web-platform-tests : Test Suites for Web Platform specifications
- https://github.com/w3c/wptserve : Web server designed for use with web-platform-tests
- https://github.com/w3c/wptrunner : Cross-browser and multi-platform test runner for web-platform-tests. Used in mozilla-central and servo.
- https://github.com/w3c/testharness.js : (no description)
- https://github.com/jdm/asknot : Ask not what Mozilla can do for you but what you can do for Mozilla.
- https://github.com/jeffbryner/MozDef: Mozilla Defense Platform.
- https://github.com/jgraham/webdriver-rust: WebDriver library for Rust.