# active member や開発メンバーとして設定してある expectation

## まとめの進行計画
**目次**
0 ゼミの目的/活動内容
1 知識のインプット
1.1 タスクの決定 onboarding
はく
1.2 issueの作り方
はく
1.3 進め方
かわい
- [リンク] つまったときは

1.4 進捗報告
かわい
- [リンク]　メンターへの報告
- issue報告

2 開発フロー
独立　ディスカッション　
2.0 機能開発タスクの決定
2.1 issue立て
2.2 開発
git/GitHub について習熟していることを期待します
[Udemy リンク]
branch名ルール
[xclone-backend]
[twiclone]
共通フローはコマンド：Ryoma
サンプルプロジェクト
ブランチヒストリー
- backend
- [frontend](https://hackmd.io/@IeybMmLYQAi-J5YABOmq5A/SkxMOSYhC)

2.3 PR
PR template
オプショナル
CI解決を目指す
label, assignee, development, reviewer
[実際のPR]
2.4 merge
Approve, merge, delete branch

3 ゼミ参加者として期待される振る舞い
3.1 全体
メンバーとのコミュ
3.2 メンティー
メンターとのコミュ
3.3 メンター
メンティーとのコミュ

## ゼミの目的/活動内容

## 知識のインプット

## expectation

### タスクの決定

#### 前提として
[Onboarding](https://github.com/okuda-seminar/Resources/blob/main/Onboarding.md)を1年で終わらせる
各タスクの完了までの時間の上限は決まった時間+2weeksまで

#### 最初にやること
メンターと話し合って、自分の興味のある分野の[Onboarding](https://github.com/okuda-seminar/Resources/blob/main/Onboarding.md)を終わらせる

#### その後のタスク決定

####

### issueの作り方
#### 最初にやること
テンプレートを選んで作成する（基本はParent issue template、child issue templateは指定があった場合に使いましょう）

#### 中身に関して
* Background：なぜこれをやるのか（例：こういうエンジニアになりたいから、この理由でこういう知識が必要）
* Goal：このissueは何をしたらcloseするのか
* Approach：どう言うふうに取り込むか
* Overview：全体的な方針を書く（Goalをcloseするためにどうするのか）
* Todo：やることリストを書く
* Frequency(optional):どのぐらいで頻度でやるか
* Deadline:いつまで終わるかを書く。ここの日程を絶対守るように（守らない事情があれば報告しましょう）
* Parent issue(optional):親issueを貼る
* References(optional):関連するリンクがあれば貼る（udemyならudemyのリンク、本なら本の購入リンク）
* Notes(optional):ノートなどがあれば貼る

#### その他
* Labels：reportとparentにする
* Assignees：自分にする
* Projects: Todoにして、StatusもIn progressにする

[わからない場合はメンターに質問しましょう！](#expectation)

### タスクの進め方

研究活動などで時間が確保できない場合はissueのコメントに残すなど、あらかじめ伝えておきましょう

**理由**
報告がなければ事情によらず、ただ勉強をしていないだけだとみなされます
事前に報告して混乱を防ぎましょう
#### わからない内容があり進められないときのフロー
1. 15分間自分で調査する
2. 15分経過時に自分の直面している問題への手がかりが得られないならばメンターにオープンな場(issue, slackのtimes)で質問する
質問の際は自分が何で困っているかわかるように伝えよう

- よくある対処例
- タイポ: サンプルコードがある場合は自分のコードとの差分を見る
- エラーメッセージを読む: 読んでもわからなければchatGPTに聞いてみよう

例:

何を実現しようとしたのか: ユーザーログイン機能を追加しようとした
どんなエラーが出た: エラーメッセージを貼る
ソースコードの提示: 自分の書いたソースコードを全て提示

### 進捗報告
[メンターとの報告](#メンターとの報告)でも触れていますが、直前になって問題/質問などの報告をすることはできるだけ避けましょう。唐突に質問された際に答えられるかどうかはメンターの能力次第になってしまいます。答えられれば良いですが、答えられないと１週間を無駄にしてしまいます。

#### issueへの報告
宣言した頻度、最低週１回で最低限以下の2点を報告しましょう
- どこまで進んだか
- どれだけ時間がかかったか

タスク進捗の責任はメンターにあります。進みが悪いなどのタスクが期限内に終わらなくなるような情報は共有しましょう。
別のタスクに取り組む際にどれだけ時間がかかるのかの参考になります。

#### メンターとの報告
メンティーは議題、質問事項を提示する責任があることを頭に入れておきましょう。自分からメンターとのコミュニケーションをとりにいきましょう。
確認すべき内容は以下の２つに分けられます
- タスク内容理解度確認
- 質問事項

メンターの指導の理想はメンティーをある理解度まで引き上げることです。この理想を実現するにはメンティーの理解度と理想の差分の説明が重要です。メンティーの現時点での認識によって指導方法が変わります。どこまで理解できているかを説明するように話しましょう

タスクを効率よく進めるための主導権を握るのはメンティーの責務です。突然質問することはやめましょう。面談の時間をメンターの思考に費やすだけで済めばまだいいですが、良い解決策が出てこなければ１週間を無駄にすることにつながりかねません。タスクを効率よく進めるための主導権を握るのはメンティーの責務です。

## 機能開発タスクの決定
オフラインアクティビティを活用し土曜日のみ繰り返し質問ができる。
翌週までのタスクはオフラインアクティビティ終了時までに決定する必要がある。

実装するタスクは主に３種類ある
- プロジェクトに必要
- スキルセットのアピール
- 将来的に触れておいた方がいい
## プロジェクトIssueの立て方
- titleにサービス区分の名前をつける
例：swiftの場合、[iOs] title
titleは実装内容が一目で分かるように具体的な内容にする。
- Assignee,Labels,を設定する。（Labelsは基本enhancementをつける。）
- Referencesが取得できるようなissueの場合、実装予定のReferencesを貼り付ける。（Documentのリンク、UIなど）
## PRのやり方
### お作法
* PR作成時には、PRテンプレートを使用し、内容を明確に記述する。必要最低限の情報に絞れるなら絞る。ただ単に項目を埋めるのではなくシンプルなことを意識する。
* 開発ルールに準拠する
### Reviewerに見せる前に確認すること
* Label、Assignee、Developmentを適切に設定する。
* テストが含まれていること
* 動作することを確認してから必ずPRを投げること
* CIのエラーが発生した場合は、解決してからReviewを頼むこととする

FYI:[Ref](https://)

## Mergeの仕方
- Reviewer全員の Approveが行われてから行う
- Rebase and Mergeを選択して行う

FYI:[mergeの種類
](https://qiita.com/ko-he-8/items/94e872f2154829c868df)

# 保留
## Active Members
担当: はく/はるき

## Development
担当: りょうま/あつし

## active membersについて
- 守るべきタスクとその理由 E/R
- GitHub上での振る舞い E/R
- 土曜日の有効活用 E
- issueの立て方 R 活動報告のところのexpectationに関係
- 活動報告 E/R
- 推奨worktime E
- メンティーとしての心構え E/R
- メンターに求められるもの E
- ミーティングまでに準備すること: メンティー・メンターの心構えにまとめる
- 活動に時間を割けない場合 R
- ゼミへの貢献 E: 具体化が必要
- 文言と姿勢 E
- 周りとのコミュニケーション E
- 情報の共有 E

## 開発プロジェクトについて
- 参加用件 R
- 開発フロー R: Add TODO, Ensure that,
- PR/commitのお作法 R
- 技術の提案時の作法 R
- 立てるissueの内容 E
- メンターへの配慮 R
- reviewを出す際に気をつけること
- [front](https://hackmd.io/@IeybMmLYQAi-J5YABOmq5A/SkxMOSYhC)
- [backend](https://hackmd.io/qQL9yOTKTgOFS18IKNrt0Q)

## Command

1. Clone a repository (local)
1. git clone {REPOSITORY_NAME}
1. Create an issue (remote)
1. Create a branch (local)
- git checkout -b {FEATURE_BRANCH_NAME}
- git switch -c {FEATURE_BRANCH_NAME}

1. Edit files (local)
1. Add files (local)
1. git add {FILE_NAME}
1. Commit files (local)
1. git commit(1st)
2. git commit --amend(2nd~)
1. Push files (local)
1. git push origin {FEATURE_BRANCH_NAME}
1. Create Pull Request (remote)
1. Submit the review (remote)
1. Repeat step4 ~ step8 until the reviewer approves

1. Apply commits in to the main branch to the feature branch (local)
1. git checkout main
1. git pull origin main
1. git checkout {FEATURE_BRANCH_NAME}
1. git rebase main
1. git push -f origin {FEATURE_BRANCH_NAME}
1. Merge the feature branch (remote)
1. Repeat step2 ~ step12

## ゼミ参加者として期待される振る舞い
### 全体
積極的に取り込むを常に意識すること
報連相を忘れないこと
嘘を言わないこと
周りを助ること
参加率+コミュニケーションを意識すること
### メンティー

### メンター