Scriptapedia/建立並貢獻指令碼到“Scriptapedia”

本節介紹如何建立和編輯/貢獻指令碼到Scriptapedia。可以出於多種原因建立指令碼，包括記錄尚未出現在Scriptapedia中的實踐、需要以與原始作者的指令碼有足夠差異的方式調整指令碼，以及發明新的指令碼以滿足群體模型構建實踐中的一些需求。

指令碼的元素

Scriptapedia的初始開發之一是定義一組欄位，這些欄位可以用於組織指令碼的元素。以下列表簡要介紹了這些元素。當前列表用於Scriptapedia和使用指令碼的修訂。

• 指令碼的背景和目的：指令碼的背景和目的指的是何時使用指令碼以及出於什麼原因使用指令碼。這通常是一段不超過幾句話的簡短陳述。目的是為指令碼的潛在使用者提供一個關於何時以及為什麼他們可能考慮使用指令碼的簡明陳述。
• 狀態：指令碼的狀態為已確立的實踐、有希望的實踐或開發中。已確立的實踐是指已被多個團隊反覆使用以實現可預測結果的指令碼。有希望的實踐是指已被一個團隊公認使用但尚未被另一個團隊或具有相似結果的群體獨立複製的指令碼。開發中是指目前正在建立且可能不完整或具有實驗性質的指令碼。
• 群體任務的主要性質：任何時候的群體任務的主要性質都可以區分為收斂性、發散性、評估性或演示性。收斂性活動有一個整合想法的一般軌跡，而發散性活動則產生想法。評估性練習迫使參與者優先考慮並做出選擇，在某些方面與收斂性任務類似。演示性練習包括向參與者介紹特定技能或見解的教學演示。
• 時間：應考慮並將其劃分為三個階段：會議前的準備時間、會議期間的實際時間以及可用於後續的剩餘時間。
• 材料：這列出了成功完成指令碼所需的材料和裝置（例如，記號筆、紙張、資料投影儀）。請注意，在一種環境中普遍可用的材料在其他環境中可能難以獲得。

• 輸入：其他指令碼的輸出，作為此指令碼的輸入（例如，來自“時間上的圖形”指令碼的變數列表）。

• 輸出：此指令碼的輸出，其他指令碼可以使用。

• 角色：所需的各種角色列表以及成功完成技能所需的最低技能水平。

• 步驟：描述如何準備、促進和完成指令碼的步驟列舉列表。
• 評估標準：一系列可觀察的結果，表明指令碼是有成效的，並以與經驗豐富的指令碼使用者一致的方式生成結果。如果輸出是視覺化的（例如，CLD），那麼提供一組說明結果的圖片會有所幫助。理想情況下，有不同小組的不同促進者提供的多個示例。
• 作者：發明指令碼的人或社群。如果指令碼基於一個起源不明的傳統，請明確說明這一點以及觀察到起源的位置。這將幫助其他人找到並更新指令碼的作者身份。請注意，僅僅記錄指令碼並不等同於作者身份（即，指令碼的發明）。
• 歷史：描述指令碼的歷史和動機。當現有的指令碼因某些特定原因或限制而被修改時，這變得尤為重要，但它也可以用來描述導致新指令碼的適應的動機和性質。
• 修訂：這指的是對現有指令碼的更改。通常，無需包含次要的編輯或格式更改。主要重點是捕獲代表指令碼的增量更改以改進指令碼的修訂。
• 參考文獻：除Scriptapedia中交叉引用的其他頁面外，應在此處列出所有引用的參考文獻。
• 註釋：這是一個關於各種主題的註釋列舉列表，包括促進指令碼的變化和適應。這可能包括文化適應或引入特定練習的變化。

選擇指令碼的狀態

指令碼通常分為三種開發狀態類別：已確立的指令碼、有希望的指令碼和開發中的指令碼。已確立的指令碼是指已被多個團隊獨立地在一段時間內複製的指令碼，因此不僅證明了對它們是什麼以及如何促進它們的某種共識，而且還產生了在各種條件下可靠且可推廣的結果。一般規則是，已被兩個或多個團隊在一段時間內獨立複製的指令碼符合此標準。

有希望的指令碼是指僅由一個團隊可靠地實施的指令碼。這可能是因為它是相對較新的指令碼，還沒有機會被另一個團隊複製/測試，或者更簡單地說，因為它不是一個有趣的或有效的指令碼，正如其他從業人員所判斷的那樣。

開發中的指令碼為人們提供了一個地方，讓他們在指令碼可能不完整或正在進行中、仍然很大程度上不感興趣或需要線上協作來開發指令碼時共享指令碼。

指令碼的審查

指令碼由編輯團隊審查。在某些情況下，更改直接進行並記錄。

新指令碼模板

要為指令碼建立一個新頁面，請在頁面的開頭新增{{subst:gmbscripts}}，然後儲存。然後，指令碼模板的最新版本將自動新增並可供編輯。