Skip to content

Organization

Dan Ibanez edited this page Aug 31, 2016 · 2 revisions

The SCOREC presence on Github is centered around a Github Organization. The heirarchy contained therein is something like this:

Organization:

  • Repositories
    • core
    • core-sim
  • People
    • cwsmith
    • onkarsahni
  • Teams
    • Owners
    • Developers
    • PHASTA
    • Albany

Organizations contain repositories, but they also contain a set of People (Github user accounts) associated with the organization. The People can be grouped into Teams. Each Team is simply a subset of the People, and a single user can be part of multiple Teams.

Github has a feature-rich system of Permissions. At SCOREC, we typically set Permissions between Teams and Repositories, not between individual users and Repositories. For a given Team and Repository, that team may either read, write, administrate, or know nothing about that repository. We tend to avoid giving Administrative permissions to a Team.

Github also now offers branch restrictions, which basically means that one can choose more fine-grained permissions of which Team can push to each individual branch of a single Repository. We make use of this in our Automation setup.

Every Organization has a special Role that can be given to a subset of People; they are called the Owners, and have essentially unlimited permissions to administrate the Organization. One important use of this is that Owners can invite people to the Organization itself and then to Teams within the organization.

At SCOREC, we also have a Team called Developers which is for people working at SCOREC who need to make changes to PUMI, our core collection of code.

Besides those two Teams, most other Teams at SCOREC represent a collaboration with another group (e.g. PHASTA, Albany) or a group withing SCOREC working on a particular project. These teams are typically used to give read access to private repositories, and possibly write access to project-specific repositories. In this way, we can manage access on a per-project basis, and simply remove the project Team when its lifecycle ends.

Clone this wiki locally