Re: [思辯] 關於刪修推文
※ 引述《StaticVortex ()》之銘言:
: 其實我傾向支持原文著作者可有限度修改部分推文,
: 不過有些地方有疑惑.
: 有時候在瀏覽網站時,有些文章或項目會附著網友評量的選項,
: 從 單一選項"推薦"與否 或 二元選項 "支持" "反對"
: 到 像雅虎新聞的 "這篇新聞讓你覺得?"
: 雖然這些大抵上是讓其他網友評量該項目的價值,但細節有些不同.
: 譬如雅虎新聞是強制參與評量後才能看到其他人對該項目的評量,
: 在閱讀完畢該項目,閱讀該項目當下,或閱讀該項目前,
: 不會受到其他人對該項目評量的影響.
: 或譬如同樣雅虎新聞下的"有多少人推薦此新聞"其擺放位置在於文章末,
: 也就是在閱讀完畢後便立即受到此評量影響.
: YouTube 影音項目下的 文字評論 項目,
: 每則文字評論旁有其他網友對此文字評論項目的評量;
: Amazon 商品項目下的 顧客評論 項目,
: 每則評論項目上方有其他網友對此評論項目的評量.
: 即在閱讀該項目當下會受到此評量影響.
: 同樣上段兩例,
: 皆支援由 其他網友對此評論項目的評量 作為篩選條件.
: YouTube 可設定 只顯示 評分在某程度以上的文字評論;
: Amazon 以評分為基準排序.
: 在閱讀該項目前便受此影響.
: 但上述所有例子 項目的評量 都只有表達單純的預設選項
: (推薦與否;支持反對;新奇溫馨誇張難過實用高興無聊生氣)
: 然而此站上,推文較類似YouTube影音項目下的文字評論,同時附上簡單的評分(推噓箭頭),
: 因此任意刪修推文會有侵犯對方著作的疑慮,同時無法還原評分.
: 大部分的網路服務中,其附著評論與項目主體的評分是分開的,
: 而且似乎都沒有允許項目主體提供者刪修其附著評論,
: 而是藉由網友互評的方式作一定程度的把關.
: 不曉得系統上要達成類似的功能是否困難?會增加多少額外負荷?
: 此站上 推文系統 大概會在兩方面對文章主體造成影響.
: 推噓箭頭相當於直接對文章評分,
: 可影響到其他網友閱讀此文章的意願與可能性(系統支援以推文數為篩選),
: 甚至是在其閱讀此文章 前 便影響其對此文章的觀感.
: 而推文內容直接附著在文章主體下,
: 使其他網友在閱讀此文章完畢 後 立即受推文內容影響(排除直接看推文的).
: 但目前推文系統雖然同時在上述兩方面造成影響,但在刪改時,卻只能分開處理.
: 選擇推或噓只能改變文章評分,卻無法修改既存的推噓文內容;
: 刪修推文時文章評分卻又無法還原,
: 如果推文系統要達成這種還原評分的功能,不曉得難易度如何及會耗費多少資源?
推文的系統應該是比較偏向於短評的功能
設計上這種短評應該就是人們的直覺覺得如何就如何
系統不允許即使是作者本人的事後修改
好讓這種短評的功能不至於被扭曲取代回文的系統
如果你要講有內容的話 就回文
只是一句好或不好 就推文
推文所佔用的系統資源是比回文佔用的少很多的 當然能有的功能也少很多
而評分這種東西不就是加一減一嗎?
一個人就一票 噓錯了就推回來
難道為了這個要新增一個取消加一的功能 這樣不是多此一舉?
: 除卻推噓箭頭,推文內容(通常)是在閱讀文章完畢後才產生影響,
: 並且推文內容同時是推文者之創作也同時伴隨著推文者ID署名.
: 若要說推文內容減損原文價值,而允許原文著作者刪修推文,總覺得理由上不太恰當.
: 雖然系統上大概將原文與推文視為一體(按下"End"鍵 會跑到推文串末而非原文末),
: 但本質上原文與推文是分開的,有沒有推文並不會影響到原文的完整性,
: 而且我猜系統要將原文與推文分開應該不難做到,
: (譬如在原文末及推文串末各加註旗標記錄其所在行數,
: 按下"End"鍵改為跳到下個旗標所在行)
: 雖然推文內容附著在原文主體之後,但畢竟是在閱讀文章完畢後才產生影響,
: 相較之下,連推與連噓對文章的影響卻大多了.
: 而且推文是有署名的,因此推文內容減損的應該是推文者ID的價值而非原文或原文者價值.
: 我認為若要允許原文著作者修改推文,所持理由應該是推文內容對閱覽者造成的不便,
: 而且方法上應該是以前綴或後綴的方式,避免直接改動推文內容.
把原文跟推文分開?
我覺得這很不實際 現在很多人是用推文點名 或是用推文來對話
如果原文作者把文章砍了 結果推文還留著
然後還要請所有推文的人一個一個去砍自己推文 這不是很怪嗎?
而且推文本來就是設計來回應原文的
如果推文的人真的很介意自己的文字有沒有被改動 那他為何不回文呢?
回文的內容他自己完全可以掌控 而且所有人也都知道他是在回應原文
: 以 YouTube 文字評論為例,
: 其以其他使用者後綴評分,並同時在系統上支援篩選,
: 以此方法將管理權責交由網友互評,
: 同時使用者可以自行選擇是否閱覽低評價的文字評論內容.
: 若要在此站上達成類似的功能,不曉得需要額外耗費多少資源?
: 如果可以達成類似功能,那麼應該可以紓解對於推文不請自來附著在原文末的問題吧.
: 而在現況,也許可以允許原文著作者透過前綴色碼(灰)的方式(還有行末結尾碼),
: (推文時無法自行選擇顏色,因此應該不屬於推文內容吧?)
: 一方面保留網友自行判斷推文是否不適,
: (畢竟現在主流意見似乎不太喜歡由單一人(原文著作者)
: 或少數人(板主群)來替自己判斷什麼叫作合適 )
: 一方面也紓解問題推文對閱覽者的不適吧.
以我自己的感覺來說 Youtube的文字評論比較像回文 而不是像推文
我覺得一般禁止修推文是不可以扭曲假造或忽視別人意見
而不是說推文真的有什麼了不起 誰都不能碰
: 作為結尾的問題:
: 推文內容算是原文的從或附屬物嗎?
我認為推文在設計上就是原文的附屬
只是很多人自己發展出很多玩推文的方式 讓他越來越不像附屬物而已
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.20.128.100
→
06/25 10:30, , 1F
06/25 10:30, 1F
→
06/25 10:31, , 2F
06/25 10:31, 2F
→
06/25 10:31, , 3F
06/25 10:31, 3F
→
06/25 10:32, , 4F
06/25 10:32, 4F
推
06/25 11:05, , 5F
06/25 11:05, 5F
→
06/25 11:05, , 6F
06/25 11:05, 6F
→
06/25 11:06, , 7F
06/25 11:06, 7F
→
06/25 11:06, , 8F
06/25 11:06, 8F
推
06/25 12:31, , 9F
06/25 12:31, 9F
→
06/25 12:32, , 10F
06/25 12:32, 10F
→
06/25 12:32, , 11F
06/25 12:32, 11F
→
06/25 12:33, , 12F
06/25 12:33, 12F
→
06/25 12:34, , 13F
06/25 12:34, 13F
→
06/25 12:35, , 14F
06/25 12:35, 14F
→
06/25 12:36, , 15F
06/25 12:36, 15F
→
06/25 12:36, , 16F
06/25 12:36, 16F
→
06/25 12:37, , 17F
06/25 12:37, 17F
推
06/25 15:08, , 18F
06/25 15:08, 18F
→
06/25 15:09, , 19F
06/25 15:09, 19F
→
06/25 15:09, , 20F
06/25 15:09, 20F
推
06/25 16:37, , 21F
06/25 16:37, 21F
→
06/25 16:38, , 22F
06/25 16:38, 22F
→
06/25 19:57, , 23F
06/25 19:57, 23F
→
06/25 19:59, , 24F
06/25 19:59, 24F
→
06/25 20:00, , 25F
06/25 20:00, 25F
→
06/25 20:02, , 26F
06/25 20:02, 26F
→
06/25 20:03, , 27F
06/25 20:03, 27F
→
06/25 20:04, , 28F
06/25 20:04, 28F
推
06/25 20:08, , 29F
06/25 20:08, 29F
→
06/25 20:08, , 30F
06/25 20:08, 30F
→
06/25 20:09, , 31F
06/25 20:09, 31F
→
06/25 20:10, , 32F
06/25 20:10, 32F
→
06/25 20:10, , 33F
06/25 20:10, 33F
→
06/25 20:18, , 34F
06/25 20:18, 34F
→
06/25 20:19, , 35F
06/25 20:19, 35F
→
06/25 20:23, , 36F
06/25 20:23, 36F
→
06/25 20:24, , 37F
06/25 20:24, 37F
推
06/25 22:07, , 38F
06/25 22:07, 38F
→
06/25 22:07, , 39F
06/25 22:07, 39F
→
01/06 23:43,
7年前
, 40F
01/06 23:43, 40F
討論串 (同標題文章)
ask-why 近期熱門文章
PTT職涯區 即時熱門文章
54
114