Confirmed users
358
edits
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
Aside from some [https://hg.mozilla.org/services/ legacy projects] in mercurial, all of the code for the Cloud Services team lives in [https://github.com GitHub]. There are over a thousand Mozilla-related repositories in total, but no over-arching corporate policy on How Mozilla Should Use GitHub, so it can easily get a bit confusing - this document exists to help you make some sense of it all. | Aside from some [https://hg.mozilla.org/services/ legacy projects] in mercurial, all of the code for the Cloud Services team lives in [https://github.com GitHub]. There are over a thousand Mozilla-related repositories on there in total, but no over-arching corporate policy on How Mozilla Should Use GitHub, so it can easily get a bit confusing - this document exists to help you make some sense of it all. | ||
It's all guidelines, not actual rules. Do what works, but please review the below as well as the top-level [[Github]] info page. | It's all guidelines, not actual rules. Do what works, but please review the below as well as the top-level [[Github]] info page. | ||
| Line 14: | Line 14: | ||
* Projects that are mostly infrastructure-related, or are heavily specific to Mozilla's internal needs, should go in "mozilla-services". Examples include [https://github.com/mozilla-services/circus Circus] and [https://github.com/mozilla-services/heka Heka] as well as various puppet configuration repos. | * Projects that are mostly infrastructure-related, or are heavily specific to Mozilla's internal needs, should go in "mozilla-services". Examples include [https://github.com/mozilla-services/circus Circus] and [https://github.com/mozilla-services/heka Heka] as well as various puppet configuration repos. | ||
* Projects that will be of more general interest to the Mozilla community, or that are more clearly | * Projects that will be of more general interest to the Mozilla community, or that are more clearly aligned with Mozilla's mission and brand, should go in "mozilla". Examples include the [https://github.com/mozilla/persona Persona] and [https://github.com/mozilla/fxa-auth-server Firefox Accounts] application servers. | ||
You will not have to look hard to find counter-examples to the above. Don't fret. Just do what you think is sensible. | You will not have to look hard to find counter-examples to the above. Don't fret. Just do what you think is sensible. | ||
== Teams and Permissions == | == Teams and Permissions == | ||
Access control to repositories in an organization is managed by ''teams''. Please review the [https://help.github.com/articles/permission-levels-for-an-organization-repository Teams Permission Model]. | |||
All Cloud Services Engineers should be members of the following teams: | |||
* https://github.com/orgs/mozilla/teams/services | |||
* https://github.com/orgs/mozilla-services/teams/cloudservices-engineers | |||
If you're not a member (and getting a 404 when you visit the team page is a good indication that you're not) please contact an owner (see below) and they can fix it up. | |||
We also have the following project-specific teams. If you're working on these projects, make sure you're in the appropriate team: | |||
== Security == | == Security == | ||
Make sure you have two-factor auth enabled on your account. This goes double if you're an Owner. | Make sure you have two-factor auth enabled on your account. This goes double if you're an Owner. | ||
If you see something, say something. A good example is people who are no longer involved with a project, but are still members of a team. | |||
== Getting Help == | |||
If you run into an issue, contact an "owner" who has superuser privileges over the org and they'll be happy to sort it out. One of the following folks would be a good starting point: | |||
* Ryan Kelly | |||
* Brian Warner | |||
* Toby Elliott | |||
== TODO == | |||
Everyone should be able to create a new repo in either org. The "all of cloudservices" teams should be adjusted to enable this. | |||
We should seriously consider a "mozilla-archive" org into which we can move obsolete and unmaintained projects. | |||
Document what we need to know about accepting pull-requests, wrt copyright assignment and licensing and what-not. | |||