How to politely prevent coworkers from altering one's contributions to a knowledge base?

Question

In the company I work for we extensively use a knowledge base for technical matters. Everybody can ask questions and everybody can answer.

Of course, there are always contributions that one thinks could be improved. For example, sometimes people misspell words or use lexical constructs that other members of the team do not like.

So a problem has arisen: instead of sending comments to the original author of the contribution, people just edit the contribution to fit their personal preferences.

That has caused a heavy atmosphere in the workplace, because people feel - I don't know the exact word - disrespected when they make a contribution and then some other member of the team puts words in their mouths by editing their post. Edit history is not displayed.

I know edits are made with the best of intentions but I think the right way to proceed is to suggest a change, instead of editing a contribution directly, and leave the final decision to the original author.

How can I ask politely and professionally for editors to stop editing, so as to avoid hurting the authors' feelings?

---

As requested by jcmeloni in the comments below here are the rules of the knowledge-base:

1. Anyone can have an account. The account has a name (not necessarily their real name) and a picture.
2. Anyone can open a "thread" that can be responded to by other members of the community
3. Anyone can respond to "threads" or even to responses.
4. Thread and replies have "contributions" which show who is the original author.

Example:

Thread: How do I connect to a MySQL database? - kogoro1122 (picture of kogoro1122)
Reply: do x, and y and z, then pray. - Satoshi44  (picture of Satishi44) 

The problem arises when some other user thinks that satoshi's joke about praying is not tasteful, unprofessional or otherwise does not fit his standard and then proceeds to edit satoshi's response, removing "then pray".

Satoshi then comes to me and asks, "Why man"?

Answer 1

The point of maintaining a knowledge base is to spread knowledge, not to "avoid hurting other people's feelings". Asking how to prevent edits in the name of peace and harmony is asking the wrong question entirely.

Do you think wikipedia would last long if nobody was allowed to make edits just because "it might hurt someone's feelings"? How about if you were part of a plumbing company -- if you botched a job that was leaking all over the place and flooding a room, should your coworkers politely inform you that you needed to fix the leak, or should they just fix the leak when they see it (and prevent further costs in water damage)?

Believe it or not, your coworkers are displaying the right behavior -- rather than let typos and incorrect information persist just because their coworkers are lazy / don't understand the reason for the change, they're fixing it on the spot.

You don't need people to stop editing -- you need to create an atmosphere that encourages collective ownership and discourages "personal ownership" of a given topic or post. Make it clear the posts are a company resource and anyone can (and should!) edit the posts to make them the best they can be.

If the entire company takes ownership for the content in the knowledgebase, then individual workers will stop taking edits to the content personally. This is the only way to ensure the content -- i.e. the purpose of the knowledgebase in the first place -- is the highest quality it can be.

Answer 2

This sounds like a problem with the knowledge base software. Any knowledge base with the ability to edit other user's content should preserve the edit history (like, for example, Stack Exchange and Wikipedia do, or like version control software does). This preserves accountability, and could even become important in legal workplace issues (for example, what if one user edits another's comment to contain harrassment?)

If you're truly sure your software doesn't maintain any kind of edit history (similar to how Stack Exchange has an "edited X mins ago" link under each post), it's time to choose new software. (There's even a whole list of Stack Exchange clones, one of which might be appropriate).

Answer 3

You don't. You shouldn't feel insulted any more than you should feel insulted if someone changes your code. You don't own the knowledgebase, the group does. There is no disrespect involved and if you feel there is, then you need to look to your own attitude.

If someone revises your contribution and you feel they have changed the meaning, then revise it again. However, do not use the same words as clearly they were unclear to begin with or the other person would not have misinterpreted them.

The point is the contributions ARE NOT yours any more than the code you write is yours.

Answer 4

So, how do can I ask politely and professionally ask editors to stop editing without hurting their feelings?

Other answers discuss why allowing collective editing is a good idea.

Some practical ways to avoid hurt feelings:

1. Add some sort of "revision" history so you can always see who changes what (basically how Stack Exchange works)
2. Add a "change reason" description so whenever someone modifies existing text they must give a reason.
3. Clearly communicate the reasons for why collective editing exists to the entire team.
4. Clearly communicate the standards for what is appropriate. Are jokes appropriate? Are non-technical terms appropriate? etc.

Most tools which allow collective editing should have functionality to do #1 and #2.

If yours doesn't, find software which does.

Answer 5

The real problem is not that other people are editing your content. The real problem is that the user interface of the knowledge base makes it look like it's your content, when in fact it belongs to the company.

If I write an article to my own liking, somebody else makes a change to it that I don't like or that I disagree with, and it still shows me as the sole author, then sure, I'll be annoyed.

But if the top of the article shows, for example, the names of the original author and of everyone else who has edited it, or just doesn't show anyone's name, or shows the full edit history in an alternate view (something like Stack Exchange's edit history or Wikipedia's "View history" page), then I'll be much less concerned about it.

The idea is to make it clear that the knowledge base is a collaborative effort, and that no one person "owns" any of it.

On the other hand, if you really want individuals to "own" content, and take full blame and/or credit for it, you can configure your knowledge base so that only the original author can edit content. But as Wikipedia and Stack Exchange both show, the collaborative editing model can be extremely effective.

Having said that, there are times when it might be more appropriate to suggest an edit to the original author rather than just making it yourself. For example, if you see a problem but you're not sure just how it should be corrected, it's probably a good idea to talk it over; here on Stack Exchange, we do that by posting comments. And if you find yourself in an "edit war", with two editors alternately reverting each other's changes, then you should definitely get together with the other person, or if necessary escalate the issue to management (on Stack Exchange, moderators play that role).

Collaborative editing is a powerful tool. Direct editing of content is a good way to achieve that, but it's not the only way.

Answer 6

A knowledge base exists for the benefit of an organisation beyond any one individual. A continuous process of refining (and editing) allows for that knowledge to be improved over time by other members of the organisation.

Sensitivity towards edits would suggest colleagues feeling ownership of the knowledge which is simply not true, and is counter-productive in terms of the overall purpose of the base in the first place.

I also think that this question addresses some of the root concerns quite well.

Answer 7

It's not YOUR page on the knowledge base. It is the company's. Just like a wiki - many people edit the same page and nobody owns it. You used the word "owner" in your question. What makes you the owner? The fact that you wrote the answer first?

You don't want to get in an "edit war" with someone. If you feel the meaning has changed, talk to the person so you can come to an understanding on what the content should be.

Answer 8

In general, I believe that allowing people to edit and the knowledge to evolve easily outweighs the potential "hurt feelings" which such edits cause.

It seems to me that a knowledge base is a very similar resource to a company as the codebase (assuming a software company for the sake of analogy). For code, having code reviews helps to increase the quality. This could be applied to your case as follows: anybody can make a change, but before it goes live, it has to be reviewed and accepted by one (or more, tune this at will) coworkers. This has a few nice effects:

• The original contributor sees that multiple people agree with the change.
• If someone tries to make a change which is only helpful to his personal taste, another coworker might catch this in a "change review".

Answer 9

The simple answer here is moderation. The level of moderation depends on your company. Sometimes, simple peer moderation works fine. Other times, you might need a weekly meeting of contributors to review knowledge base additions/removals/edits.

I would approach your manager, explain the issue, and then suggest the above solution. This does a couple of things. First, it demonstrates that you are being proactive in suggesting continual improvement of your business processes. Secondly, it demonstrates that you are thinking more "big picture" instead of just asking for a quick fix to your individual problem. This kind of thing can only benefit you.

The last thing that it does is allows your manager -- who has authority -- to present the new process to the team. He/she can do this without accusing anybody of wrongdoing or hurting their feelings. It can be put into the light of continual improvement -- which is absolutely accurate.

The thing I recommend to people is to always try to think big picture when issues happen. If something counter-productive happens, don't just try to think about how to solve the problem for yourself. Instead, try to also think about what can be done to prevent this issue from happening to others in the future.

Answer 10

If your intention is that the knowledge base should be owned and maintained by the group, then the ability to edit and update existing content is paramount. There are two obvious problems you are facing. 1) The edited text remains incorrectly attributed to the original author, and 2) Some people may not appreciate that someone's edit of their writing is an improvement.

Many of these issues were faced early in the days of wikis, and the discussion around them is preserved (or rather, still active) at the very first wiki. A good starting point to visit might be RefactorWhleRespectingSignatures.

There's a lot of useful material there and in the nearby pages that might help you to facilitate a suitable discussion with your team on how to work together better.

Regarding the second point: that someone may not like the edit of their writing; they always have the possibility of reverting the change or making their own clarification or improvement. Collaborative ownership of this kind is something that takes getting used to. It helps if everyone is open about the guiding principles that they expect each other to follow.

Answer 11

Moderation, as others here have mentioned, is one option, and can help with individual disputes over entries. However, if you don't already have one, consider drawing up a style guide - a set of mutually agreed principles and guidelines for contributions.

These are an important part of many wikis and help contributors achieve a degree of standardisation. It doesn't have to be as long or as detailed as Wikipedia's Manual of Style - even a few basic guidelines can go a long way. If you already have one, consider expanding it, or if your knowledge base is very large perhaps even create separate ones for different types of contributions.

This will help people avoid making edits that are likely to be overridden.

Answer 12

Why is there a confusion in the accepted style of answer in the first place?

Perhaps there should be a list of guidelines posted somewhere about what is acceptable and what isn't. I don't know what the culture of your company is, but as an example, my company's culture is very relaxed and casual, so jokes are acceptable in our wiki's (I work the tech startup group of a large tech company, so I disagree with other answerers forcing their company culture on others, as that is definitely not the overall attitude here and at most places). But since there seems to be a confusion in your company, perhaps it should be outlined.

And yes, it is rude to edit other people's work. I thought that goes without saying. So, I disagree with HLGEM that someone changing your code is just dandy. That is a huge taboo here. You don't change someone else's code without a review with the original author given with an explanation.

Of course, depending on your company culture, the action is probably different. But I think the course of action should be, outline what is accepted, and take away edit rights to edit other people's posts. If someone wants to edit something, they would propose the edit to the original author, and it would be up to the original author to accept or reject it, and given a fair reason, i.e. having been offended by the joke, I'm sure more often than not, the original author would not press to keep a joke that offends someone. If the editor has an issue with the original author's decision, then it will be escalated to the rest of the working group, otherwise, just drop it. I believe this is the most fair way of going about it.

And of course, if this were a client facing FAQ rather than an internal wiki, ground rules about acceptable answers should have been set in the first place.

Answer 13

The root of the problem is using a forum software but treating it like a wiki. Both approaches are great, but not misrepresenting one as another. Remove edit privileges or remove authors names. As about exact answer to your question: Remind users that your KB is "forum" not a "wiki" and should be treated as such. But ofc changing the software or just tweaking it is a better solution.

As others pointed out, the authors and readers are lead to believe that posts are actual statements made by authors, while they're not. It's absolutely normal people are upset - your knowledge base is based on a lie.

Imagine that someone would edit Satoshi44's "and pray" into "and bang CEO's husband/wife". Or plain childish "I'm (insert sexual orientation here)". Your employees have already displayed a great deal of responsibility and politeness to refrain from such pranks. Edit history would only make persecution easier, but the problem is putting words into someone's mouth.

If I'd work at your company, I'd just edit all posts to something very, very offensive and then send a mail to all "I've found a bug in our KB and took the effort to demonstrate it. You're welcomed.".

Edit: I feel I'm being misunderstood. I am not proposing OP to take any drastic actions, I'm merely presenting worse scenarios than those happening now. As arguments to present superiors when discussing the need changing current software.

There is still worse scenario than the board turning into 4chan: One edit would eventually hurt Satoshi44's feelings so much, he'll file a lawsuit for damages for defamation because company publishes posts representing someone other's opinions and falsely claim them to be his.