If there’s a problem with a wiki, then you can fix it; that’s why it’s a wiki

Date:October 17, 2012 / year-entry #244
Tags:other
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20121017-00/?p=6313
Comments:    24
Summary:On an internal mailing list, somebody asked a question about how to do X with Y, and I replied with a link to an internal wiki that described how to do X with Y (answer: use the Z tool). Somebody else replied, "Time to update that article because the link to the Z tool is...

On an internal mailing list, somebody asked a question about how to do X with Y, and I replied with a link to an internal wiki that described how to do X with Y (answer: use the Z tool).

Somebody else replied, "Time to update that article because the link to the Z tool is broken."

Apparently, this person forgot that one of the defining characteristics of a wiki is that it's easy to edit. (Another characteristic is that it is collaboratively-edited; there is no central authority.)

In other words, if you see something wrong, fix it yourself. Don't just stand around saying somebody should do something. Be someone. Because on a wiki, there is no default value for somebody.


Comments (24)
  1. GWO says:

    "All my life, I've always wanted to be somebody, but I see now I should have been more specific" – Lily Tomlin

  2. If I had a pound for every time I've fixed something on a wiki just to have it reverted to the previous incorrect state with a "YOU'RE A MORON!!1one LEAVE THIS ALONE!!!111oneoneeleven"  reason line…

  3. SMW says:

    Of course in some cases the person noting that the link is broken doesn't know the correct link.

  4. I just put a link to this article on our company wiki's home page. Thanks!

  5. Gabe says:

    That's a perfectly legitimate comment if the commenter doesn't know anything about the Z tool. Or maybe they know about it but don't want to be the last person to edit, making them "responsible" in the future (the same way being the last person to check in a file might cause every bug in that file to be assigned to you).

  6. Brian_EE says:

    @David Walker: I think you're missing the point. This was an internal tool discussed on an internal mailing list. So it would be safe to assume the those people are familiar with "Z Tool".

    The commenter took the "lazy way" and hoped someone else would fix it. What he/she should have done is taken the initiative to find out what the correct link was and update the wiki (even if that meant asking someone else). The appropriate comment would be "The link to Z tool is broken. Can someone tell me what the correct link is so that I can update the wiki?"

    And I just saved Ray from having to say "I can't believe I had to type that."

  7. Roger says:

    I can't fix the wiki because it's ACL'd all weird and I don't have access.  CAN SOMEONE FIX THE ACL!

  8. John Fringe says:

    I like your ubuntu philosophy, Raymond (sorry for the bad geek joke XD ).

  9. David Walker says:

    I have run across the same thing, where I see something in an internal Wiki that is clearly wrong but *I don't know what the correct information should be*.  

    Raymond, it's easy to find out that a link is broken; it's not always true that a Wiki reader knows what the correct link should be.  So the reader often CAN'T fix it, as SMW mentioned.

    [Then at least edit the wiki to say "[broken link]". -Raymond]
  10. jon says:

    Nice to know that the links on the Microsoft intraweb are as broken and unreliable as the ones on their public web sites :)

  11. @Brian – it is rarely ever safe to assume anything.

  12. configurator says:

    I've seen more than one wiki where it's ridiculously hard to edit. The defining characteristic of wikis isn't that they're easy to edit, it's that they're meant to be easy to edit. Big difference.

  13. Matthew Wills says:

    > I've seen more than one wiki where it's ridiculously hard to edit. The defining characteristic of wikis isn't that they're easy to edit, it's that they're meant to be easy to edit. Big difference.

    So the better alternative is to email a list of other people and let them take the hit instead?

  14. kbiel says:

    When you give Everybody responsibility for something, you might get Somebody to do something, but usually Nobody ends up doing the work.

  15. Neil says:

    @kbiel: The worst bit is that Anyone could have done it!

  16. Larry Hosken says:

    On the plus side, at least this person didn't say "The wiki page is wrong, but I'm scared to edit it… so I'll copy the page and make the corrections in my new version." Those folks lead to plenty of trouble.

  17. Gechurch says:

    I enjoy picking out the patterns in responses to Raymond's articles. One such pattern is that whenever Raymond says "this user should have done X", without exception people respond with all sorts of excuses why that person shouldn't have to (and why it is much fairer for the support person to go to far more effort, often armed with far less information that the original person). This attitude bugs the hell out of me, but interests me from a pyschological point of view.

  18. David Walker says:

    @Brian EE: Why do you assume that "everyone on an internal mailing list was familiar with Z tool"?  Maybe the person reading the wiki was trying to LEARN about the Z tool.  People do that sometimes.  "Use the Z tool" was even Raymond's ANSWER to the question "how to do X with Y", so obviously the person looking for the info was NOT familiar with the Z tool.  

    And there's not a lot of difference between saying "Time to update that article because the link to the Z tool is broken", which Raymond rails against, and saying "The link to Z tool is broken. Can someone tell me what the correct link is so that I can update the wiki?".  Whoever knows the correct link first should update the Wiki!

    I would have said "What's the correct link to the Z tool?  I'll try to get the Wiki updated."  Unfortunately, some internal Wikis have cumbersome sign-on requirements, and there are some Wikis where MY password gets reset by some unknown outside force, so I can't easily update those Wikis.  That doesn't mean I shouldn't update it, of course.

    [In this case, it was an open wiki, and finding the new home of the Z tool was not particularly difficult. (Just type it into the company's internal search engine and hey look!) -Raymond]
  19. Douglas says:

    Obviously you don't work where I do. We have six-hundred different internal wikis (that's an exaggeration, I don't even know the actual number, but it's more than a dozen). Each of those wikis have their own access systems, and on some of them access is partitioned. When you encounter a random wiki page, odds are high that you don't have access to edit. Now you have to submit an IT request and wait 2-3 weeks. During that wait period there will be several exchanges of emails to get your boss to email his boss to email IT that you're allowed access.

    It's a lot easier to tell the person you know has access to edit that it needs editing.

  20. Nick says:

    Moral of the story, when Raymond knows people can help themselves, he gets frustrated when they don't. I do, too. Don't be helpless. http://www.bing.com/search

  21. nt says:

    One problem with a wiki for team docs is that "everybody is responsible for keeping this up to date" is surprisingly similar in effect to "nobody is responsible for keeping this up to date"

  22. Brian_EE says:

    @Douglas: Apparently (to me, anyway) your company doesn't understand the wiki model. It should be editable by everyone in the organization who has access to see it in the first place.

    "But someone might change the information in it when they shouldn't!" – Yeah? So revert the edits. If someone has a habit of defacing the wiki, they should be reprimanded by their boss.

    If the wiki is closed and not editable by people, you might as well have a static webpage in it's place.

  23. Douglas says:

    @Brian EE I'm with you all the way. Unfortunately, there's nothing I can do to change it.

  24. spork says:

    your company doesn't understand the wiki model.

    Wiki is not just a technology, its also a religion.

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index