githubのorganizationアカウントの運営について


## Description
githubのorganizationアカウントについて調べた内容のメモ

## 0. 作り方
organizationアカウントは個人アカウントをベースとして作成される。

>組織アカウントの作成はきわめて簡単です。GitHub 上のすべてのページの右上にある “+” アイコンをクリックして、メニューから “New organization” を選びましょう。


>まず必要になるのが、組織名と、そのグループの連絡先となるメールアドレスです。 もし望むなら、他のユーザーを、共同オーナーとしてこのアカウントに招待することもできます。

これによって、organizationアカウントが作成され、
ベースとなった個人アカウントはorganizationアカウントのownerとなる。
organizationアカウントは基本的に個人アカウントと同様で、リポジトリやプロジェクトを持つことが可能である。
organizationアカウントが個人アカウントと異なるのは以下の点である。

1. メンバーを追加することができる
1. Teamという概念が存在する
1. 監査ログが存在する

以下これらの事柄について述べる。

## 1. メンバーについて
organizationアカウントと個人アカウントの大きな違いの一つに、
メンバーを登録できるということがある（メンバーの追加はowner権限のメンバーにしか許可されない）。

### 1.1 メンバーの登録方法
メンバーの登録はorganizationのpeopleのタブから可能。
追加されたメンバーにはリポジトリにアクセスする際の権限を付与する必要がある。
次にその権限についてまとめる。

### 1.2 organizationアカウントに関わる4つの立場
メンバーの権限には色々な種類があるが、最初により大きな枠組みについて述べる。
organizationアカウントに関わる立場についてである。
これには、

* Owners
* Members
* Billing managers
* outside collaborators

の4つがある。
ちなみに、この文章の中で「メンバー」と言った時は"Members"と"Owners"を指しているつもりである。
OwnersとMembers、outside collaboratorsは実際に開発に携わる者であり、
Billing managersは原文をそのまま引用すると、

>allow a person to manage billing settings. 

である。さしづめ、会計担当といったところか。
また、outside collaboratorsだが、組織のメンバーではないが組織のリポジトリへのアクセス権限を持つ者らしい。
権限そのものの取り扱いは、Membersに準ずると考えられる。
Owners,Members,Billing managersの権限の比較については、
[こちらの表](https://help.github.com/articles/permission-levels-for-an-organization/)にまとめられているので、そちらを参照されたい。

### 1.3 権限の種類
では、ここでメンバーの権限について具体的に述べる。
権限には４種類あり、それぞれ、

* Owner permission
* Admin permission
* Write permission
* Read permission

それぞれの権限について比較すると次のようになる。(この表は、[こちらの表](https://help.github.com/articles/repository-permission-levels-for-an-organization/)
のうち一部をを翻訳編集したものである。)

|操作|Read|Write|Admin|Owner|
|:---|---:|----:|----:|----:|
|全てのリポジトリに対する、pull/push/clone||||○|
|メンバーのteam managerへの変更||||○|
|メンバーのoutside collaboratorへの変更||||○|
|リポジトリの作成|○|○|○|○|
|リポジトリの削除|||○|○|
|リポジトリの設定変更|||○|○|
|リポジトリの公開設定変更|||○|○|
|リポジトリのorganizationアカウント下/外への移転|||○|○|
|teamへのリポジトリの割り当て|||○|○|
|リポジトリにoutside collaboratorを追加|||○|○|
|リポジトリからoutside collaboratorを除去|||○|○|
|teamリポジトリからpull|○|○|○|○|
|teamリポジトリへpush||○|○|○|
|teamリポジトリをfork|○|○|○|○|
|teamリポジトリのforkからpull requestを送信|○|○|○|○|
|pull requestのmerge/close||○|○|○|
|保護されたbranchでのpull requestのmerge[^1]|||○|○|
|pull requestに対するreviewのsubmit|○|○|○|○|
|pull requestのmergeabilityに影響するreviewのsubmit||○|○|○|
|issue の open|○|○|○|○|
|issue の close/reopen/assign||○|○|○|
|自らopenしたissueのclose|○|○|○|○|
|label/milestoneの適用||○|○|○|
|自分に対するissueの割り当て[^2]|○|○|○|○|
|releaseの作成と編集||○|○|○|
|下書き段階のreleaseの閲覧||○|○|○|
|発行されたreleaseの閲覧|○|○|○|○|
|自らのコメントの編集と削除|○|○|○|○|
|他の人のコメントの編集と削除||○|○|○|
|wikiの編集|○|○|○|○|
|statusの作成||○|○|○|

## 2 Teamについて
上の権限の部分でちらほら出てきたが、Teamという概念が存在する。
 
>組織アカウントの中では、個々のメンバーをチームとして関連付けることができます。 これは単に、個人ユーザーアカウントと組織内のリポジトリをとりまとめたものであり、 そのリポジトリに対するアクセス権の設定などを行います。

また、Teamに対して@コメントすることも可能であり、チームメンバー全体への一斉通知等が可能である。
アクセス制限に留まらず、以下のような使い方も可能である。

>一人のユーザーが複数のチームに属することもできるので、単なるアクセス制御以外の目的でチームを使うこともできます。 たとえば、ux や css あるいは refactoring などのようなチームを用意して、その手の質問に対応させることもできるでしょうし、 legal や colorblind など、まったく異なる種類のチームを作ることだってできます。

### 2.1 Teamへのメンバーの追加方法
organizationのダッシュボードからTeamsタブを選択し、create new teamをクリック。
さらにOwner権限のメンバーは任意の組織のメンバーをteam maintainerに登録し、teamに対する限定的なOwner権限を付与できる。

## 3. 監査ログについて

>組織アカウントのオーナーは、その組織の配下で起こっていることについてのあらゆる情報を取得できます。 Audit Log タブを開くと、組織レベルで発生した出来事やそれを行った人、そしてそれを行った場所などを確認できます。

Audit logへのアクセスはOwnerにのみ認められている。
また、Audit logには直近の90日間分の情報だけが保存されている


## 4. 参照資料
#### 公式リファレンス/ヘルプ

* https://git-scm.com/book/ja/v2/GitHub-%E7%B5%84%E7%B9%94%E3%81%AE%E7%AE%A1%E7%90%86<br> 
* https://help.github.com/articles/permission-levels-for-an-organization/<br> 
* https://help.github.com/articles/repository-permission-levels-for-an-organization/<br>

#### その他

* http://qiita.com/nyafunta/items/a8d764808dc29e28016c<br> 
* https://seleck.cc/647<br>

[^1]: pullリクエストが承認されていないものでもmerge可能
[^2]: これは本人の権限というより、issueを出す者が本人を指名できるかどうかについてだと思われる