維護知識庫的目的是傳播知識，不是“避免傷害他人的感受”。問如何以和平與和諧的名義防止編輯完全是在問一個錯誤的問題。

您是否認為，如果沒有人僅僅因為“它可能會傷害某人的感情”而允許進行編輯，那麼維基百科會持續很長時間嗎？如果您是一家水暖公司的一部分，該怎麼辦？如果您破壞了一個正在四處洩漏並淹沒整個房間的工作，您的同事應該禮貌地告訴您您需要修復洩漏，還是應該只是修復洩漏？

信不信由你，你的同事會表現出正確的行為-而不是因為他們的同事懶惰/而讓錯別字和錯誤的信息繼續存在/不了解更改的原因，他們正在現場修復它。

您不需要人們停止編輯-您需要營造一種鼓勵集體所有權的氛圍，並阻止給定主題或帖子的“個人所有權”。明確說明這些帖子是公司的資源，任何人都可以（並且應該！）編輯這些帖子，以使其盡可能地發揮最佳效果。

如果整個公司都擁有知識庫中的內容的所有權，則個別工作人員將停止對內容進行個人編輯。這是確保內容的唯一方法，即首先是知識庫的目的 –是其最高質量。

這聽起來像是知識庫軟件的問題。任何具有編輯其他用戶內容能力的知識庫都應保留編輯歷史記錄（例如，例如Stack Exchange和Wikipedia或版本控制軟件）。這樣可以保持問責制，甚至在合法的工作場所問題中可能變得很重要（例如，如果一個用戶編輯另一個人的評論以包含騷擾該怎麼辦？）

如果您確實確定您的軟件不維護任何形式，編輯歷史記錄（類似於Stack Exchange在每個帖子下都有“ X分鐘前編輯”鏈接）的方式，該選擇新軟件了。 （甚至還有 Stack Exchange克隆的完整列表，其中一個可能是合適的）。

你不知道。如果有人更改您的代碼，您不應感到被侮辱。您不擁有知識庫，而是擁有該知識庫。沒有不尊重的參與，如果您感到存在，那麼您需要考慮自己的態度。

如果有人修改了您的貢獻，而您認為他們已經改變了含義，請再次修改。但是，請不要使用不清楚的單詞來表示相同的單詞，否則其他人不會誤解它們。

重點在於，您所做的貢獻與您所編寫的代碼完全相同

因此，我該如何礼貌而專業地要求編輯者停止編輯而又不損害他們的感受？

其他答案討論了為什麼允許集體編輯是一個好主意。 / p>

一些避免受到傷害的實用方法：

1. 添加某種“修訂”歷史記錄，以便您始終可以看到誰更改了哪些內容（基本上是Stack Exchange的工作方式）
2. 添加“更改原因”說明，以便每當有人修改現有文本時，他們都必須給出原因。
3. 向整個團隊清楚地說明為什麼存在集體編輯的原因。
4. 清楚地傳達適用標準。開玩笑合適嗎？非技術術語是否合適？等等。
ol>

大多數允許進行集體編輯的工具應具有執行＃1和＃2的功能。

如果沒有，請查找可以的軟件。

真正的問題不是其他人正在編輯您的內容。真正的問題是，知識庫的用戶界面使它看起來像您的內容一樣，而實際上卻屬於公司。

如果我按自己的喜好寫文章，其他人會做出我不喜歡或不同意的更改，並且仍然顯示我是唯一的作者，那麼可以肯定，我

但是，例如，如果文章的頂部顯示了原始作者以及編輯過該文本的所有人的姓名，或者只是沒有顯示任何人的名稱，或在備用視圖中顯示完整的編輯歷史記錄（例如Stack Exchange的編輯歷史記錄或Wikipedia的“查看歷史記錄”頁面），那麼我就不用擔心了。

其目的是明確表明知識庫是一種協作，並且沒有人“擁有”任何一個。

另一方面，如果您真的希望個人“擁有”內容，並對此承擔全部責任和/或信譽，您可以配置自己的知識庫，以便只有原始作者才能編輯內容。但是，正如Wikipedia和Stack Exchange所顯示的那樣，協作編輯模型可能非常有效。

話雖如此，但有時向原始作者建議編輯而不是僅僅進行編輯可能更合適。它自己。例如，如果您發現問題，但是不確定如何糾正，那麼討論一下可能是個好主意。在Stack Exchange上，我們通過發布評論來做到這一點。而且，如果您發現自己陷入“編輯大戰”，兩名編輯交替輪流恢復彼此的更改，那麼您一定應該與另一人聚在一起，或者在必要時將此問題上報給管理層（在Stack Exchange上，主持人扮演該角色）

協作編輯是一個功能強大的工具。直接編輯內容是實現此目的的一種好方法，但這不是唯一的方法。

存在一個知識庫，它可以為組織帶來超越任何個人的利益。不斷完善（和編輯）的過程可以使組織的其他成員隨時間改進這些知識。

對編輯的敏感性會建議同事感覺到對知識的所有權，這是不正確的，並且首先，對於基地的總體目的而言適得其反。

我還認為，這個問題很好地解決了一些根本問題。

這不是您的知識庫頁面。是公司的。就像維基一樣，許多人都在編輯同一頁面，而沒有人擁有它。您在問題中使用了“所有者”一詞。是什麼讓您成為所有者？您首先寫下答案的事實？

您不想與某人進行“編輯大戰”。如果您覺得含義已經改變，請與該人交談，以便您可以理解其內容。

總的來說，我相信允許人們進行編輯和輕鬆地發展知識遠勝過這種編輯可能引起的潛在“傷害感”。

在我看來，知識庫與之非常相似資源作為代碼庫提供給一家公司（為類推而假設一家軟件公司）。對於代碼，進行代碼審查有助於提高質量。可以將這種情況應用於您的情況，如下所示：任何人都可以進行更改，但是在更改生效之前，必須由一個（或多個，可以隨意調整）同事進行審查和接受。這會產生一些不錯的效果：

• 原始貢獻者認為有很多人都同意更改。
• 如果有人嘗試進行更改，而這僅對他的個人有所幫助品味，另一個同事可能會在“變更評論”中發現這一點。

這裡的簡單答案是適度。適度的程度取決於您的公司。有時，簡單的對等審核工作正常。在其他時間，您可能需要每週一次的貢獻者會議來審查知識庫的添加/刪除/編輯。

我會與您的經理聯繫，解釋該問題，然後提出上述解決方案。這做了兩件事。首先，它表明您在建議業務流程的持續改進方面很主動。其次，它表明您在思考更多的“全局”，而不僅僅是要求快速解決您的個人問題。這種事情只會使您受益。

它做的最後一件事是允許您的經理（誰擁有權限）向團隊介紹新流程。他/她可以做到這一點，而無需指責任何人做錯或傷害他們的感覺。可以將它放在持續改進的基礎上-這是絕對準確的。

我向人們推薦的事情是，在出現問題時始終嘗試著大局。如果發生適得其反的事情，請不要僅僅考慮如何自己解決問題。取而代之的是，嘗試考慮可以採取哪些措施來防止將來再發生此問題。

如果您的意圖是知識庫應歸小組所有和維護，那麼編輯和更新現有內容的能力至關重要。您面臨兩個明顯的問題。 1）編輯後的文本仍然被錯誤地歸因於原始作者，並且2）有些人可能不欣賞某人對其寫作的修改是一種進步。

許多問題早在Wiki時代就已面臨，圍繞它們的討論在第一個Wiki中得以保留（或者說仍然活躍）。一個不錯的起點可能是 RefactorWhleRespectingSignatures。

那里和附近的頁面中有很多有用的材料，它們可能有助於您與團隊就如何更好地合作進行適當的討論。

關於第二點：某人可能不喜歡他們的作品的編輯；他們總是有可能撤消更改或做出自己的澄清或改進。這種協作所有權需要習慣。如果每個人都對彼此期望遵循的指導原則持開放態度，這會有所幫助。

適度性是一種選擇，就像這裡其他人提到的那樣，它可以幫助解決有關條目的個人爭議。但是，如果您還沒有，請考慮草擬樣式指南-一套相互同意的貢獻原則和準則。

這些是許多Wiki的重要組成部分，可幫助貢獻者獲得一定程度的學位。標準化。它不必像Wikipedia的樣式手冊一樣長或詳盡-甚至一些基本準則也可以走很長一段路。如果您已經擁有一個，則可以考慮對其進行擴展，或者如果您的知識庫很大，甚至可以針對不同類型的文稿創建單獨的知識庫。

這將幫助人們避免進行可能被覆蓋的編輯。

為什麼首先在接受的答案風格上會造成混淆？

也許應該在某個地方列出一些關於可接受和不可接受的準則。我不知道您的公司的文化是什麼，但是例如，我的公司的文化非常輕鬆隨意，因此我們的Wiki中的笑話是可以接受的（我在一家大型技術公司的技術創業小組工作，所以我不同意與其他應答者將他們的公司文化強加於他人，因為這絕對不是這里和大多數地方的總體態度）。但是由於您的公司似乎有些混亂，所以也許應該概述一下。

是的，編輯其他人的工作是不禮貌的。我以為不用說。因此，我不同意HLGEM，有人在更改您的代碼只是花花公子。這是一個很大的禁忌。未經原始作者的審閱並給出解釋，您就不會更改別人的代碼。但是我認為應該採取行動，概述接受的內容，並取消編輯權限以編輯其他人的帖子。如果有人要編輯某些內容，他們會向原作者提出修改建議，然後由原作者決定接受還是拒絕，並給出合理的理由，即被玩笑所冒犯，我相信通常情況下，原始作者不會勉強開玩笑冒犯某人。如果編輯對原作者的決定有疑問，那麼它將被上報到工作組的其他成員，否則，將其刪除。我相信這是解決問題的最公平的方法。

當然，如果這是面對FAQ而不是內部Wiki的客戶，那麼應該首先設置有關可接受答案的基本規則

問題的根源是使用論壇軟件，但將其視為Wiki。兩種方法都很棒，但又不能曲解彼此。刪除編輯權限或刪除作者姓名。關於您問題的確切答案：提醒用戶您的知識庫是“論壇”而不是“維基”，應該這樣對待。但是，最好更改軟件或對其進行調整是一個更好的解決方案。

正如其他人指出的那樣，作者和讀者被認為是帖子是作者的真實陳述，而並非如此。絕對正常的人很難過-您的知識庫基於一個謊言。

想像一下，有人會把Satoshi44的“祈禱”編輯成“並爆炸CEO的丈夫/妻子”。還是簡單的幼稚的“我（在這裡插入性取向）”。您的員工已經表現出很大的責任感和禮貌，避免這種惡作劇。編輯歷史記錄只會使逼迫變得容易，但問題是要在別人的嘴裡說些話。致所有人的郵件“我在知識庫中發現了一個錯誤，並竭力進行了演示。歡迎您。”。我不建議OP採取任何嚴厲措施，我只是提出比現在發生的情況更糟糕的情況。作為討論上級主管在討論是否需要更改當前軟件時的論點。誹謗，因為公司發布代表他人觀點的帖子，並錯誤地聲稱自己是他的觀點。