※ 引述《AmosYang (Zzz...)》之銘言： : : 二來是無法透過系統面改變，這已然成為一個目前最好的方法。 : 是的，慣例(convention)是很重要的，我也認同你提出的「鍵盤」的 : 例子；相對的，另一個反例是「汽車 vs. 跑得更快更遠更久的馬」 : 也就是「使用者想要的(want)並不一定是他們所需要(need)的」 對，所以就是要思考， 有沒有在不大幅改變既有習慣的前提下，找到更好的作法， 以目前的情況下，我認為是只有修改 bbs ui 才有機會。 這個權力跟計畫，目前被掌握在系統部手上， （ptt 系統部基本上非常獨裁而且不太會給予任何回應。XD） 事實上以 BBS 而言，推文其實是後來才出現的產物， 早期的 BBS (如巴哈、不良牛等）其實是沒有推文功能的。 這有幾個時空背景， 一、轉信盛行（推文對轉信討論會造成障礙）， 二、技術問題（推文系統沒寫好容易造成文章的編修， ptt 的推文系統以前也有這種問題。） 那推文的誕生，也是因為當時有另一種困擾， 文章過多與很多文章過短，導致難以追蹤整個文章串。 當時就已經有水球的存在而且關水球風氣沒有現在盛行， 所以不完全是溝通/聊天的需求，而是 "公開討論/補充" 的需求。 : : 另外一般而言，推文在裁決鑑定上並不視為本文內容， : : 也就是你擁有的文章的部份並不包括推文。 : 我同意「公開文章」這個出發點，也理解在設定任何限制時都要小心 : 考量 regulation vs. censorship 中間這條線 : 我偏向於「發文者對其文章內容(含推噓文)有一定的(但非絕對的)仲裁權」 : 也就是 My body, my rule. My post, my way. 這部份我覺得可以討論。 : : Better way, or current way. :P : : 沒有更好的方式時，現在可行的方式就是好方式， : 我同意 : 然而，那是一個理由(reason)還是一個藉口(excuse)? :D 微妙的分界線 有辦法改變現況，有新的提案那就是個 excuse， 沒有就是一個 reason 。XD 在討論這種議題的時候我會比較偏向於拉出各種可能的方案， 像是 1.限制推文：魔羯版的最多連續五行連推 2.限制推文：痞子版的將推文間隔拉長(60秒到240秒) 3.限制推文：推文間隔5秒 (這主要應該是針對推文娃娃問題) 4.不限制，鼓勵討論後回文整理 5.不限制，鼓勵回文（取消一行文規範） 6.不限制 7.給發文者編輯權限讓它把推文改成比較適合閱讀的排版 8.禁止推文 -------------------------- 1 的限制我認為解決問題沒有很明確有效 2 副作用太大，已講過不再重複 3 基本上還好, 是可以考慮的方向 (目前公民版是採用這個) 4,5,6 基本上都是不限制的方案，目前應該是最多看板採用的方案。 只是分出了一些分支。 7 因為作者不一定願意加上內容修改常常會造成糾紛，實行有困難。XD 8 副作用跟 2 差不多。 因為其實案例已經很多，但沒有看到什麼很有效的結果， 這點基本上我是沒有想到還有什麼更新的方案。 : : 真要正面迎戰的話，我認為是到 pttsuggest 寫建議比較快。 : : 另外其實透過 / 來標示特定討論者 ID ， : : 在閱讀長推文時還算是個可以明確看出討論的一種作法。 : 在這個討論串更之前，我有去 PttSuggest 看過，感覺上，或許是受 : 限於人力物力，是比較偏向於「許願池」模式，似乎沒看到很明確的 : 開發流程的說明，例如 : 1. 如何建構開發環境; 更詳細的技術文件、資料 : 2. 更嚴謹的, 對於 feature request 的評量辦法與決策過程的說 : 明；例如，若有 pull request, 要去哪裡呈交; 其評量結果最後 : 的仲裁權與方法在誰手上? : 或許要多去站務區各版看看，能不能挖到這些資料... 1.ptt.cc 有 open repo https://webptt.com/m.aspx?n=/index.source.html 2.就我所知是系統部獨斷決行，沒聽說有收 pull request 的管道。 這點我多年前曾經私下問過板務站長 okcool ， 據說就連板務站長也無法掌握要改什麼跟什麼時候上。 : : 多年前這裡就是這樣的，我就是那個在胡蘿蔔跟鞭子環境下走過來的新手。 : 就「學習」來說，我的心得是 : http://webptt.com/m.aspx?n=bbs/GameDesign/M.1321118655.A.B56.html : 問問題的目的不在於得到答案，而是檢視自己思路的瑕玼 : 「問題」可以分為幾類，其中一類是「記憶問題」，例如某個字該怎 : 麼拼怎麼寫；這種問題本身問出來是浪費時間，因為真正的問題是「 : 如何取得該類知識領域的公認專業索引(index)?」，例如字典或 technical : spec. : 另一類是「理解問題」，例如為什麼 "2+2=5", 這類問題問出來也是 : 浪費時間 XD 因為真正的問題是「如果我不懂，那為什麼我不懂?」 : 是故, : 一旦具備了透視問題本質的能力 (也就是修正自己思路的瑕玼)答案 : 自然會浮現; 以「問答案」的方式問問題無異於飲鴆止渴 我是認為在回答過程自然就會從解構問題開始， 回答的目的不是解決那個問題， 而是引導發問者能夠跟隨回答者解題的腳步自我解構題目。 為什麼 2+2 = 5 這個例子可以先這麼問， 2 + 2 是什麼環境下的 2+2 ？ （釐清環境） 2 + 2 的期望結果是多少？（釐清現況與確認現況是否正確） 為什麼 2 + 2 結果是 5 （有無其他環境ex. 計算機可以佐證） 若有，還可以進一步的討論為什麼兩者有不一樣的結果， 其中環境的差異、系統的差異的哪一個環節造成結果。 把這種對於問題的解構，再回答解答時置入是教學很重要的過程。 的確新手缺乏對這種問題的理解， 所以我才主張去檢視新手的問題是否符合品質，根本就是不重要的。 因為一個蠢問題很有可能只是他還缺乏尋找索引的能力。 就算那個問題 google 就能搜到，要從 google 到的結果， 轉化成自己能夠"確信" 的結果，也還有段距離。 而且我認為啦，願意問問題的人本身一定有一定程度的動機或壓力， 這種時候對症下藥相對是容易的。 當然一定有人覺得幹麼浪費時間在這種人身上， 但回到原本的那句話，沒人逼你回。 自然有我或其他夥伴有願意花時間在這種人身上的人， 因為我們看到的是這些人的可能性，不是他現在的差。 當然我們畢竟不是神，如果他就是不願意學我們也不能拿它怎樣， 但有件事情很棒的就是這是個 bbs 有其他觀眾， 即使當事人不願意學，我們留下來的文章還是都會是很好的解說。 如同這版上我早期的一些文章一樣。 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.166.163.218 ※ 文章網址: http://webptt.com/m.aspx?n=bbs/java/M.1401805399.A.1F6.html ※ 編輯: TonyQ (118.166.163.218), 06/04/2014 00:09:52