Recently in wiki Category
台灣維基人夏季聚會應mingwangx之邀,簡短地分享我的Wiki經驗與建立小型偕作的可能。
CMW Watch的Wiki Myths, Wiki Reality (簡體中文翻譯:Wiki 的神話與現實_cnBeta 視點觀察)提到三點Wiki技術的迷失。
- Wiki技術將鼓勵員工貢獻內容 (A wiki will heighten motivation and spark contributions)
- 員工們都知道如何使用 Wiki (Employees will know how to contribute)
- Wiki 會讓你隨時找到你需要的訊息 (Wikis will always surface the information you need)
迷失2與迷失3在原作中均已經提到一些解決方案,此處就「迷失1: Wiki技術將鼓勵員工貢獻內容」進行回應。
作者在文中建議Wiki需要「(1)明確目標、(2)訊息自由發佈的企業文化 與 內容品質議題、(3)可以幫助員工們的工作」。iThome重新思考知識管理系列文章中的「回到營運角度思考知識管理」提到「如何讓知識管理系統發揮效用,提高員工使用率和貢獻度,決定了的成敗」,Wiki作為知識管理的環節的前提下,回到Wiki強調「自由發佈、多人合作、建立資訊脈絡與關聯」的功能(修改自Jedi對於Wiki的詮釋),什麼樣的內容主題可以觸發這樣的合作機會及內容分享,又能處理內容品質議題?
內容協作的可能:
(1)文件編寫:除了使用Word追蹤修訂,也可使用Wiki的版本管理功能,例如Google文件的共用、協同合作及發佈、
(2)會議記錄確認:會議記錄的修改確認與再確認,除了Email往返外,經由Wiki集中編寫與共同檢視,減少溝通時間、
(3)客戶服務支援:客戶服務的技術文件支援,經由Wiki讓不同部門或使用者社群方便共同編寫,例如國內社群書籤分享網站funP.com 使用手冊(使用DokuWiki)、國外Second Life Wiki(使用MediaWiki)等、甚至是奧客言論集與客服教戰手冊、
(4)群組專案:將群組專案原本散落各處的資源進行連結彙整。
(5)其他:例如日常所需的中午訂便當商家名冊與評論等等。
內容品質議題:
內容品質並非Wiki上才會發生的問題,不管使用哪一種資訊系統,均會面對該問題。在品質管理機制上,常見的是有專家或守門人審核文件後,才進行發佈,但相對地將會將低文件傳遞的速度,因此加註資料來源供其他使用者查證、或者將該議題結合企業的獎勵誘因方針,提升與鼓勵好的內容的分享。
回到「Wiki作為知識管理的環節」的前提,是否Wiki技術該視作企業知識管理的部分 或者 企業根本不該使用Wiki,則留待讀者來回答。
最近英文教師虛擬社群論壇EVOnline,熱烈討論著「Google Docs算不算是Wiki?」(Are Google Docs Wikis?)。就Wiki的定義來看,「使用者可以透過瀏覽器自由地存取、貢獻或編輯的多個網頁(collection of web pages)」,Google Docs是wiki。
跟其他wiki軟體相比較,Google Docs功能上令人讚賞的是,除了偕同編輯、MS Office風格的使用介面及文件格式的銜接外,並且可以有最多10人同時間在線上同步編輯。因此在另一個討論串中,被許多老師提到將Google Docs作為「小組合作進行寫作練習」的資訊工具。不過當文件數量多時,Google Docs不能看到小組其他同學如何組織分類文件,以及編輯時方便引用與連結其他文件,是Google Docs相較欠缺的地方。
將Google Docs與其他wiki軟體比較,可能的問題是,Google Docs是以文件為單位的線上文件編輯及管理系統,而其他wiki通常是多個文件組合而成的網站,兩者的層次有所差異。Google的另一套產品Google Sites比較接近其他wiki軟體的層次,但是它擴充了文件編輯的認知,整體網站的元件均可以偕同編輯組成。
參考資料
- evonline2002_webheads : Are Google Docs Wikis? 2008-06-30
- evonline2002_webheads : Google Docs 2007-12-19
- [ METAMUSE ]: Google Apps 全新功能: Google Sites 小組訊息共享網 - 羊男實驗の咖啡館 2008-02-28
附註:為何wiki是「偕同編輯」,而非「協作編輯」?因為「協」字代表一群人在一起,但是可能有人會扯後腿。而「偕」字則代表一群人心連心、手牽手地一起完成一件事。 (語出自Jedi, 2007-07-20 演講)
應OSSACC之邀(謝謝KJ轉介),講解MediaWiki建置與管理。
直接下載簡報檔(.PDF, 2008/6/23修復下載連結)或 點閱Wiki版的筆記。
簡報大綱
一、MediaWiki簡介與教學應用
二、Windows下安裝MediaWiki
三、MediaWiki本地化設置
四、MediaWiki介面修改
五、MediaWiki功能擴充
六、MediaWiki備份與管理
七、教學資源的交換與分享
註: 從簡報檔複製程式碼時,需留意將引號的全形改為半形。
相關資料
* Chieftain (2007). Reflection » Blog Archive » Wiki 的教學研究應用 (2007-09-14 更新連結)
* Vicki A. Davis (2007). Wikis in the Classroom » SlideShare
安裝Wikipedia Presentation後(需事先安裝Firefox瀏覽器及GreaseMonkey套件),重新整理維基百科(中文維基百科也適用)的網頁,將會在「條目」下面前會增加「Start presentation」的連結,點選後會進入簡報模式。
- 原條目的每一段落(section),將會是一張簡報。
- 數字列表或項目列表,則會有點擊滑鼠來逐項顯示的特效。
- 需點選網頁最上方的輔助連結,才能切換上一張簡報、下一張簡報、或離開簡報模式。

由於wikipedia的書寫,原本未預期要是以簡報方式呈現,所以簡報會出現內文超過單一螢幕大小。另外跟dokuwiki+S5簡報系統結合的顯示效果相比較,還有改善空間。
如果有架設MediaWiki(v. 1.6.9)的系統,可自行將UserScript原始碼中前3個span改成div。
參考資料:
WikiMatrix網站收集了各種Wiki方案的詳細資料,並且可以方便地進行線上比較。但是初次使用Wiki方案選擇精靈(Wiki Choice Wizard)的使用者,對於洋洋灑灑的Wiki功能用語可能會感到疑惑,反而不清楚應該選擇何種方案。對於選擇精靈中的條件,補充說明如后:
Step 1. 頁面的版本紀錄(Page History)
當你修改頁面在儲存時,將會儲存成為一個版本。頁面版本紀錄的功能對於協同編輯是不可或缺的,可以防制廣告留言與內容破壞的回復。個人經驗上,開放匿名編輯很容易看到整面數十個的內容破壞版本,因此頁面的版本紀錄需要結合基本的權限控制(ACL),編輯頁面需要經過身份驗證,才會有效避免廣告留言與內容破壞。不過如果Wiki僅供個人使用,版本紀錄是可有可無的。
Step 2. 所見即所得的線上編輯器(What you see is what you get, WYSIWYG)
多數Wiki使用簡單的語法(markup、或稱格式化規則)來格式化文字,但不少Wiki開始使用類似文字編輯軟體的所見即所得的線上編輯器。對於初次使用Wiki的使用者,所見即所得的線上編輯器會降低Wiki的使用門檻,但是原有簡單的語法,對於有經驗的使用者能提供快速與彈性的編輯。有些軟體雖然沒有所見即所得的線上編輯器,但提供了另一個快速產生簡單語法的編輯器,也可以加速內容編輯的速度。
不同Wiki的簡單語法卻不相同,導致內容轉換到不同Wiki時是一件苦差事(例如標題2在Oddmuse及MediaWiki是以==強調,而DokuWiki則是以=====表示)。儘管Wiki間無法與其他Wiki達成語法一致,但可以透過Ingy發展所見即所得(Wyswyg)的Wiki編輯介面Wikiwyg或語法轉換(Wiki Converter)來增加互通及編輯的彈性。
Step 3. 自行架設軟體或使用現有服務(Software or hosted?)
自行架設軟體,需要滿足軟體安裝的條件。相對於使用現有服務,自行架設軟體有更多的控制權。不管使用何種方案,都應該留意是否有方便的備份方式。在這邊我們選擇自行架設軟體。
Step 4. 頁面的儲存系統(Storage System)
儲存系統有(1)關連性資料庫(例如MySQL):適合大量頁面的處理與全文搜尋、(2)檔案系統:因為不需要資料庫,所以系統需求低也很容易備份、(3)修訂版控制系統 (Revision Control System, RCS例如Subversion) 。關連性資料庫以MediaWiki為例,全文搜尋並不是運作良好,不過如果安裝在公開的網路上,可以改用Google的站內搜尋。如果安裝在個人電腦或硬體環境不佳(記憶體不多)時,方便備份的檔案系統Wiki是不錯的Wiki方案。
Step 5. 自由軟體或商業軟體(Free and Open Source?)
採用自由軟體的方案,則能有強大的開發社群,協助Wiki軟體的功能調整與新增。但是Wiki程式碼的修改,不會獲得任何保固。如果你喜歡有更多的控制權,自由軟體是不錯的選擇,但程式碼在修改前,記得備份以免遭遇慘劇。
Step 6. 採用的程式語言(Programming language)
多數Wiki採用PHP、Python或Java,採用何種程式語言取決於你個人的偏好與公司政策。
希望上述說明,能有助於Wiki方案的選擇 。
相關討論:如果想自己建立wiki系統的話,大家有什麼建議? @HemiDemi
相關文章:比較Wiki服務網站的中文支援程度與功能項目 (2007-01-05新增)
Wikipedia 創辦人Jimmy Wales 在4月7日 Wikipedia and Free Culture 演講 (主辦單位宣傳網頁)中說明品質管理機制(quality control)之前,提到餐廳的例子:
餐廳用餐安全
然而...沒有一個餐廳會設計成這樣!但許多社交性軟體(social software)卻會有這樣的設計侷限。
相對於缺乏對於使用者的信任、未適度與彈性地下放權利等軟體的設計,在Wiki概念下有了突破。使用者除了單方向的閱讀,同時有了權利可以讀與寫。
即時的同儕評論(realtime peer review)
然而如何確保自由編輯的品質? Jimmy提到透過即時的同儕評論:
4月8日在OSDC的演講裡,與會者hlb詢問到「如何確保5年後或10年後, Wikipedia內容的正確性?」Jimmy以甘乃迪條目的風波為例,「當問題發生(expose)時,社群可以很快做修改。另外,由社群組成品質管理小組重新檢視內容正確性與進行評選,來提昇內容品質。」
Wikipedia未來技術發展方向(Roadmap)
Jimmy提及Wikipedia未來技術發展方向(Roadmap, 註),其中與內容品質相關的是「文章破壞行為防治機制」(Heuristics for vandalism):
前一天有位與談者提到透過Google找不到的資料,也許不是事實。我的想法是,除了社群與程式協助判斷之外,使用者編寫內容時,應詳細標註資料的參考出處(reference),例如Yahoo知識+ 使用者回答問題時,需要說明參考資料。另外,學術社群的論文撰寫,也常被要求須說明文獻出處(citations)。Wikipedia的內容撰寫者,若能說明清楚這一點,除了消極地提供其他社群成員,驗證資料的正確性與排除著作權疑慮,也可以積極提供其他使用者擴展內容的可能。
自由軟體(free software)與開放內容(open content)的差異
與會的聽眾提到「自由軟體發生問題時,使用者會透過bugzilla提交bug,然後開發者提交修改程式碼(patch),再經過社群驗證之後,才會正式釋出。而不像wikipedia,當使用者發現"錯誤"時,馬上可以進行內容的修改。」 Jimmy回應說:
後話
相對於既有百科全書發展的步調遲緩,Wikipedia展現社群的活力和世界不同文化的多樣風貌。隨著內容的增加,內容的品質議題也受到更多的關注,然而在一旁觀察的你我,除了享受wikipedia的服務之外,何妨不一同參與文件的編寫,進而形塑Wikipedia。
註: Wikipedia未來技術發展方向(Roadmap): (1)Wyswyg(Wikiwyg), (2) Client-API, (3) Ajax, (4)Multi-tier architecture(DB layer OK, UI and domain layer interwined), (5)Heuristics for vandalism, (6)WAP/wireless 。以上現場抄錄自Jimmy簡報。
Update 20060409 ::
* Wikipedia創始人訪台座談會後感及podcast釋出
Oddmuse Wiki若能事先擬定命名規則,對於日後搜尋會很方便。以我為例,以下是我的頁面命名原則:
1. yyyy-M-d - 該天工作除外的內容, 例如: 2005-11-25
2. yyyy-M-d_Tasks - 該天工作, ex: 2005-11-25_Tasks
3. yyyy-M-d_Query - 當我檢索不同資料庫時,會紀錄不同關鍵字的結果,建立檢索策略的檢索歷史檔案, ex: 2005-11-25_Query
4. 簡短的APA書目格式 - 作者姓名 (年份). 文章標題, ex: Tennis, J. T. (2003). Two axes of domains for domain analysis
A. 以特定字串為開始的頁面名稱或內文: %5CA(以...開始) + %s (查詢字串)
將下面這行插入到oddmuse的 InterMap
StartWith /cgi-bin/wiki.pl?search=%5CA%s
例如: [StartWith:2005-11 2005-11的月彙整頁面]
B. 以特定字串為結束的頁面名稱或內文: %s (查詢字串) + %24 (以...結束)
將下面這行插入到oddmuse的 InterMap
EndWith /cgi-bin/wiki.pl?search=%s%24
例如: [EndWith:Query 我所有的檢索歷史]
C. 尋找相同作者的文獻: 從APA style, 作者姓名總是先於年份,以此作為正則表示式判斷依據
將下面這行插入到oddmuse的 InterMap
Author /cgi-bin/wiki.pl?search=^%s(.*|\s|_|\()\d\d\d\d
例子: 點選 Author:You-Zheng, 你可以找到 You-Zheng_Li_1993_Philosophy_Semiotics 與 You-Zheng_Li_(1993)_Philosophy_Semiotics 這兩個頁面 (如果你想用比較鬆散的書目格式)
D. 尋找相同年份的文獻
將下面這行插入到oddmuse的 InterMap
Year /cgi-bin/wiki.pl?search=^*\(%s\)\.
更新: 尋找相同作者的文獻,下面是快速的替代選擇
Author /cgi-bin/wiki.pl?search=^%s
原本是寫在個人Wiki的小型計畫 - 成語中的政治、社會議題,今天將撰寫的其中一個題目釋出到Wikipedia ,所以連帶地授權方案也轉變成GNU 自由文件許可證 。
亂世用重典
== 定義 ==
透過嚴格的法律制度懲罰犯罪,來達到治理社會的目的。最常被舉到的例子是,「日治時代,台灣的治安很好,晚上睡覺的時候可以不用關窗戶」,就是因為有嚴格的法律制度和強而有力的警察制度。
== 為什麼支持? ==
任何有同理心的人,對於犯罪者造成受害者和受害者的親人的傷害有所體會。當傷害是如此深刻難以磨滅時,為什麼反而對犯罪者如此寬大,難道不該給這些犯罪者應得的懲罰?
== 為什麼反對? ==
亂世用重典,強調透過威嚇的法律制度來解決所有社會問題,但是那不是唯一的解決方式,而且過度地依賴法律制度,代表一廂情願地認為法律制度不會有缺失、不 會有疏誤的可能!當警察抓錯人、法官誤判、冤獄發生的時候,透過重典只不過是凸顯政府治理社會的失責,並且使得冤獄變成難以挽回的遺憾。
受害者與其家屬固然值得同情,但是重典不是協助他們的合適方式。如果我們期待一個開明專制的政府,可以效率地、有力地、明智地抓到真兇,但是給予政府過大權力,往往適得其反,並且反過來箝制人民思想自由。
== 相關文章 ==
* cinema-critique: 1010 世界反死刑日 2005-07-22
昨日下午,發現共筆(後端引擎為MediaWiki v1.4.8)遭到罐頭文章機器人(spam bot)攻擊,起初還耐著性子,逐篇文章設定24小時封鎖IP的限制,後來發現大量機器人湧入,於是決定使出殺手鐧。
緊急封鎖編輯權限
修改LocalSettings.php,插入以下這行,要求使用者必須登錄帳號後,才能進行編輯。
如果沒有登錄,想要編輯的話,會出現以下訊息:
由於使用者點選[[特殊:登錄]]之後,不會進入正確的登錄畫面。需透過資料庫管理程式,將Cur資料表中的Whitelistedittext or Whitelistedittext/zh_tw 中的[[特殊:登錄]],更改成[[特殊:Userlogin]] 或 [[特殊:Userlogin|登錄]] 。詳細的權限設定,詳見Setting user rights in MediaWiki
用處不大的IP封鎖
將.htaccess放在根目錄
Deny from 000.000.000.0
Deny from 000.000.000.0
allow from all
由於IP數量眾多,且日後維護該清單困難,不建議採用。
版本回復
透過Wiki的版本紀錄,回復正確的版本。
安裝黑名單(SpamBlacklist)擴充套件
下載SpamBlacklist extension,並上傳到extensions目錄下,並且在LocalSettings.php,插入以下幾行
require_once( "$IP/extensions/SpamBlacklist/SpamBlacklist.php" ); $wgSpamBlacklistFiles = array( // database title "DB: wikidb My_spam_blacklist", );
然後從Spam blacklist複製名單(點選該網頁上方的view source),貼到My spam blacklist的Wiki頁面。
參考資料:
* Setting user rights in MediaWiki - Meta
* Anti-spam Features - Meta
圖形來源:Wikipedia
常常會有朋友問什麼是Wiki、什麼是Blog,用短短幾分鐘時間介紹它們,其實是很不容易的事,特別是當這些「技術」還在發展的過程,有時候不是我們發現了Wiki或Blog,而是我們參與、界入其中,進而形塑她們的風貌。
Sometimes some friends asked me what is Wiki or Blog? It's not easy to describe them in couples minutes. Because these "technologies" is still in developmental, sometimes we are not discover them, but to construct their form/styles.
Recent Comments
xxc on 回應: Wiki Myths, Wiki Reality: 我覺得根本還是社會學
四野 on Google站內搜尋的瀏覽器按鈕 (for Firefox v3.0 & IE v7): 找了很多地方,都是乱
ivan on Firefox 作為網路資料引註的輔助工具(APA格式): QuoteURLText套件: A USEFUL T
armrol on Google站內搜尋的瀏覽器按鈕 (for Firefox v3.0 & IE v7): 請問一下 如果要把站
planetoid on 事件模擬 - 關於恐懼: Hi, around
aroundyou on 事件模擬 - 關於恐懼: 你引的那段話好像是我
planetoid on Google Docs算不算是共筆(Wiki)?: KJ: 我回頭查了一
planetoid on Firefox 與 個人知識管理: 謝謝 :) 如果有任
jk on Firefox 與 個人知識管理: 感謝您今天的分享,讓