# 引き継ぎ内容
お願い部分
- スキルアップ研修改修
- 赤メンター資料
- 青メンター資料

やれたら
- GAS
- 提出フォーム x2
- 質問フォーム
- 進捗管理シート
- 進捗度合い計算
- 週報

範囲
- 設計学習
- チーム開発課題
- レビュー練習
- 修了試験
- 問題指摘
- レビュー作成
- 応用課題デバッグ
- Github研修
- 日程調整管理

# 今後の方針
- 分析(特にやってほしい)
- 分析して、課題の内容を修正するとか。
- ちなみに、「レビュー練習・作成」はなくてもいいかもしれない。
- 改修
- 進捗管理シート整理
- formひとつにまとめる

- S0研修改修もやれたら
- S2研修改修もやれたら

# 相談等
- 角谷さんに投げてください。

# 直近でやってほしいこと
## Github研修日程調整の管理

## 進捗管理シートの細分化

## 課題リポジトリのプライベート化 (関口依頼)
- せいはくんに、形式の調査と草案をしてもらって、
- オオウチがチェック。

- これまでのリポジトリをプライベートor削除してもらう。
- などの周知。

### 1. レビュー用Githubアカウントを作って、なんとかする
- 切り替えが面倒。

### 2. Github以外のリモートリポジトリを作成する
- GitLabが、共同編集者無制限っぽい？
- 無限ではあるが色々ややこしい。調査結果は後述。

### 3. その他
- とりあえず3/24(火)時点では他案は浮かばず。

# 調査結果・仮案
## 調べたメモ
- GitHub
- 共同編集者が3人までなら無料。
- 仮案無理なら、こっちの有料プランも検討。
- GitLab
- 共同編集者の人数制限はないっぽい。
- [参考](https://flanny7.hateblo.jp/entry/2019/07/11/202101)
- [GitLabのヘルプページ](http://eslead-ave.mother.co.jp/help/public_access/public_access.md)
- ~~触った感じ、十中八九無理。(3/25 0時時点)~~
- ...と書いたが、GitLabでフォークリポジトリを作成してもらい、それに共用アカウントの権限付与してもらうフローならあるいは？と思い以下。
- 正直あんまり見返すことないし、GitHubの切り替えするくらいならこっちでいいかも。

## GitLab所感
- 協力: 梶谷

### 招待者(研修生)の権限
- Guest
- そもそもチーム内のリポジトリ見れない、NG。
- Reporter
- 直接変更はできず、今までの修了試験レビュー返却通り、編集した人のForkリポジトリが生成、そこにpatch-○みたいなブランチができて、プルリク作れる感じ。
- **が、そのForkリポジトリが完全にプライベート化してしまい、内容が確認できない。**
- レビュー返却する分にはギリセーフだが、不便。
- Developer
- 該当リポジトリにブランチを生成してしまう。
- 内容の確認はしやすいが、他の研修生も見れる。
- ※研修担当側がレビュー返却するのにはOK。
- Maintainer、Ownerはこれ以上の権限なのでもっとダメ。
- Reporter以降共通
- Forkボタンを押しても、個人管理下のリポジトリが生成され、**チームに属さないため、権限付与が必要になる。**
- だるい。
- 土壌さえ整えれば楽か？

### 他操作性など
- 日本語化
- setting > preference(GPGの下) > languageから。
- プルリク作りにくい。
- 「比較」ってところからだったが、Fork元に作るのがよくわからなかった。
- googleアカウントでログイン可なので、アカウント作成自体は手間ではない。
- SSHキー登録は、githubと同じもの使いまわしでも接続できた。
- 直接弄るし登録しなくても可だが、もし実装課題も...となると必要と思う。
- (それでもHTTPSで行けますが)
- ただし`push -f`が弾かれた事案あり。よく解らない。

<br>

## (仮案)GitLab運用
### 元となるチームを作成
- 実験段階で作ってはいるが仮なので、本採用になったら作り直す。
- 入れるリポジトリ
- [description_task](https://github.com/Infratop/description_task)
- [bookers2_phase2_debug](https://github.com/Infratop/Booker2_phase2_debug)
- [design_documents_review](https://github.com/Infratop/design_documents_review)
- 実装課題は...そこまで気にするならzipで良くない？とは思います(小声)
- これS0→S1、受講生(課題&学習中コミット)にも同じこと言えますよね...？
- 他は今のところ良いはず。

### 共用アカウントを作成
- "s2-reviewer"みたいな。
- どのメアド、PWで作るかは相談。
- 角谷さんに聞く。
- ログイン方法は研修担当に周知。

### 研修生フロー
1. googleアカウントでアカウント作成。(infratopでgitlab作っていることはないと思うが、万が一あれば連絡してもらう)
2. チームに招待してもらい、内容確認、各リポジトリをフォークする。
3. フォークしたリポジトリ全部に、共用アカウントを**Developer**で招待。
4. 提出は今までと同じ。

### 研修担当フロー
#### 招待方法
- 共通
- 共用アカウントから、研修生をチームに招待。
- 研修生の権限は**Reporter**で。
- 既に研修に取り組んでいるメンター
- 上記周知時、スレッド等で報告してもらう。
- できれば研修リーダーが良いが...研修担当に事前告知要る
- 新規メンター
- S1→S2スキルアップの説明時に、説明担当が上のフローを説明し、1~3まで一緒に行う。
#### レビュー方法
- これまでのレビュー返却と同じはず。
- 共有アカウントでログインし、該当リポジトリを確認。
- もし権限なかったら説明。
- developerなら、提出者のリポジトリにブランチが出来るので、大本(チーム内)が壊れることはない。
- ~~大本の変更が必要な場合、共用アカではなく特定の人が弄れた方が良いと思う。~~
- ~~-f効かない事案があったので、念のため...~~
- ~~なので、必要に応じてOwner権限を数人に付与。~~
- よく考えたら、Owner権限ないと招待できない...
- **勝手にいじるような人はS2にいない**と信じ、共用アカウントをOwnerにします。
- (コミット履歴はあるし、-f効かなくても戻すすべはあるか。)

#### Docbase更新
- 研修生・研修担当とも、いくつかイメージ画像を交えつつ説明は書いておいた方が良い。
- Docbase編集リンク
- [:notebook:研修生](https://infratop.docbase.io/posts/981614)
- [:notebook:研修担当](https://infratop.docbase.io/posts/961773)

#### 現研修生・修了者への周知
- これまでのリポジトリをプライベートor削除してもらう。
- これだけでいいか？検討

### 懸念点
#### 招待フローの手間
- 共用アカウントをOwnerにしなくてもいけるにはいけるが、Owner権限がある人がいない場合が面倒。
- 後述の修正作業用に、S2の一部、およびLS社員(の一部?)に渡すにしても、社員に手間取らせるのは避けたい。
- なので、共用アカウントをOwner権限にするのが一番いいかな、と思っています。
- ちなみに招待したらメール行くので、共用アカウントのメアドにバンバンメール行くと思います。良いのかな。

#### この運用変更後の、修了者の扱い
- ※現S2はGitLabに個人アカウントない(はず)なので問題ない
- 個人アカウントを持っているため、切り替えが必要。
- 研修担当の方に
> 個人アカウントからレビューしないように
- と注意書きを加えれば大丈夫か?

#### 課題の大本に修正が必要な場合のフロー見直し
- 問題報告・相談
- どのチャンネル？
- 課題進捗チャンネル: 研修生も見れるのでNG
- 課題提出チャンネル: 現状一番適切ではあるが埋もれる...
- DM: たぶん報告被る。
- GitLabで報告用チーム作る?: 通知来ないし確認面倒そう。パス。
- 今後S2スキルアップも作るなら、新規で「スキルアップ研修運用」チャンネルを作っても良いのでは？
- S0→S1 / S1→S2 / S2→S3の報告が入り乱れるかもしれないが、課題提出のところよりはマシ。
- そうなると参加者を絞らないといけないような...(→進捗チャンネルと同じ問題)
- それぞれ別個で作成しても良いかもしれないが、要相談。
- 修正作業
- 共用アカウントがOwner権限を持っているが、あくまで修正は責任者が行うことにしておきたい。
- 修正完了報告
- 一応逐一進捗チャンネルに報告しておいた方が良いと思う。
- 問題報告・相談をするチャンネルにも、done報告はする。
- 今の14_wcみたいな感じ

---
**2020/03/25追記WIP**

Gitlabで共用アカウントを作成する流れは同意。

レビュー方法変えることで、権限周りを楽にできたりしないかな。
これまでは、
課題リポジトリをforkして、forkしたリポジトリに対してPRを送るような形式にしていたけど、
課題リポジトリ自体にPRを送るような形式にするのもありかな？

**2020/03/26追記**
以下の内容はReporter権限でclone, PRの作成ができたらの話。

### 研修生の取り組み方。
説明課題, 修了試験の問題抽出とレビュー作成
- GitLab上でPullRequestを生成
- Web IDEでファイルを編集する
- 編集内容をcommitする
- 合格するまで、PRの内容を編集する。

未確認
Reporter権限でWeb IDEを開けるかどうか。

デバッグ課題
- git cloneでローカルに自分の作業リポジトリ作成。
- 自分の作業ブランチを作成して、そこで作業
- 自分の作業ブランチをpushしてPRを作成

確認したいこと、これはReporter権限でできる？

### 研修担当
説明課題, 修了試験の問題抽出とレビュー作成
- GitLab上でPRを編集してレビュー
- Web IDEでいけるだろうと思う。

デバッグ課題
- git checkout PR-URLでPRの内容にcheckoutしてコードと動作を確認。
- cf. [他人のPRにチェックアウトする方法](https://hiroki.jp/hub-checkout)