部門運作 - SHELTER-ZONE/SHELTER-ZONE-Structure GitHub Wiki

職位

各職成員只負責自身職責內工作，請勿直接干預其他職位成員職務以免造成 Side Effect。

例：

其他職員不得直接更改任何部門內線上技術文件、文檔，因為維護線上文檔的工作是由 DM 負責。

回報、請示請遵循冒泡式回報，一層一層往上回報，切勿直接跨級回報。

例：

其他職員認為 CM 處理不當，應當向 CM 上級 Guide 部門嚮導 回報。如果仍無法解決或需進行請示，請再由 Guide 部門嚮導 向上級 Server Owner 群主 回報。
p.s. 第一時間請直接上報，盡量勿直接干預，以免造成 Side Effect。

雖然這感覺有點多此一舉，但在管理機制層面上還是比較實用。
目前是利用部門專用 Github Respository 的 Issues 功能來發包 Task/Issues。(由於目前尚未找到合適團隊、專案管理協作平台)
主要用於尺度 (Scale)比較大或正式的 Task/Issues。

p.s. Discord 內會有對應的 Webhook 頻道監聽 Issues 的發布消息，請部門成員時刻注意。

目前有幾項確定該使用此機制的情境：

例1：

TS 欲想對線上技術文件添加、修改內容，應當使用 Github Issues 來發包 Task 請求 DM 更新。

例2：

Guide 想委派 DM 創建某項新的文件，應當使用 Github Issues 來發包 Task 請求 DM 創建文件。

例3：

CM 發現部門內部存在某些問題，應當使用 Github Issues 來發佈 Issues，視問題隱私性決定在 Github 上或 Discord 進行內部討論。

Note.

這項機制可能存在較多模糊的地方，會不斷進行修正。

依照 單一職責 原則，照理來說 CM 應該不會有文件撰寫的相關職務，因為那是屬於 DM 的工作。
但部門職員的數量有限，或專業領域等問題，有時候會直接委派任務的方式進行。

因此職員的職務分為兩種：

職務
職位本身的職務。

委派職務
由上級或自行委派之任務。

例1：

DM 自行之提議、舉辦的專案，屬於自行委派任務。

例2：

群主或部門嚮導直接任命 CM 再Github上制定相關規範文件，屬於上級委派職務。

Note.

同理 單一職責/Bubble回報 ，其他職員不得直接干預其他職員負責的委派職務，如有問題請Bubble回報。

此為 Task/Issues 機制事件
職員可互相發起彈劾，但職員不能對部門嚮導發起彈劾部門嚮導直接由群主監督。
彈劾依照 彈劾標準 判定。 (尚未制定，所以現在無法發起彈劾)

成員部門可隨自己意願退出，但請盡可能完成交接工作後予以退出。