gitlab communication

https://about.gitlab.com/handbook/communication/

一間 all-remote 的公司、採用 asynchronous communication 優先的策略

一件事情值得花時間處理，，那也值得記下來給別人參考、學習。
issue 預設為 non-confidential(除了一些有資安、個資等特別issue)
持續討論，優先專注定義問題。
issue 相互有關連 or 討論時，Double link issues。
討論過後要將結論 or 共識 update 到 issue 的 description
提交小的 issue，留言建議改善的方案，拆散到其他 issue，放上連結（也就是說，盡可能拆小 task
issue 不應該 open 太久，assign 給別人太久沒解的話，就 assign 給別人。
花心思將你的 task 排出優先順序，可能要考慮：
- 有沒有人在被你這個 task blocking？
- 如果 delay 會有什麼問題？
- 有多少人影響
從現在的 mileston 挑選 issue
大家應該要自己去 milestone 裡面挑選 issue。避免 assign 給別人，除非你是他主管。
一旦開始進行，就儘早把 issue assign 給自己，如果接續需要別人處理，就 assign 給對方。
re-assign 的時候，要 update 最新的 description
需要別人 review issue 時，@-mention 他，不要用 assign 的方式
close issue 時，寫下為什麼 close

所有寫作的溝通都用English，即使是一對一溝通，因為有時候會轉寄。
可能的話採用 asynchronous communication (issues/email/Slack)
(溝通方面優先）Issues > email > Slack
用 email 代替 chat，內部信只有簡短的訊息是ＯＫ的。Chat 的時候，為節省時間，別問候了 (別加入 Hi Emma,)，就把 email 的內容直接 past 上去也ＯＫ。另外，不第一時間回 email, chat 也可以
有時候 synchronous communication 比較好，有助於更清楚溝通，但不作為預設手段
你有問題，題問問題是很ＯＫ的。提出來，大家可以回答。利用 issue or public chat頻道。
溝通過程中，提到某些東西時，要附上連結 (MR, issue, commit, webpage, comment, etc.)
需要別人關注的話，就 CC 給他。issue 需要他關注的話，就 @ 他要讀一下這 issue
內部溝通避免去別的私人群組
- 很干擾，又要更多的 channel 需要接收訊息
- 沒法 search
- 沒法 share (不好加人進來)
- 歷史紀錄會消失（人走了 group 就散了）
- 沒有目標，大家都必須自己記得這些私人 channel 是做什麼用的
溝通當中，用 low-context(低情境) 詳盡描述。盡可能提供 context 減少 confusion。相對的，用 ubiquitous language(普遍存在的語言) 來溝通，提升效率。

每一個主題發一封 eamil，因為一封 email 包含多個主題，會 delay (需要花時間回覆所有東西 or 太亂了，單純忘掉)
回覆 email 時，永遠 replying to all，讓所有人知道你收到這個了。要結束這個 thread 的時候，就回說 OK, thankes, or done 之類的就好（想回去看看新聞記者跟 Bill Gates 的信）
如果你轉寄給別人，但沒有任何 comments 的話，請標註 FYI FYA (for your action) FYJ (for your judgment)。如果是 FYJ，那個人可能不會照你期望的去做決定。
Email 是 asynchronous 的溝通行為，如果你的 manager 週末 email 給你，那你上班時再回也ＯＫ
如果這封 email 變成緊急了，別擔心直接在 chat 上找那個人並把 email 主題丟上去。