9 ms·

This is a terrible idea. You're destroying institutional knowledge because "it's cluttered." What do you do with clutter? You clean it. You don't burn your hou

This is a terrible idea. You're destroying institutional knowledge because "it's cluttered." What do you do with clutter? You clean it. You don't burn your house down every year because it's cluttered. Wikis aren't free. Organizations need to take it upon themselves to continuously groom the contents and organization of their wiki. They can be very useful if you do. But it's an ongoing process, just like organization in any other area in life. You don't write code in a single file and then delete it when it gets too big. You create folders. You move and prune. Sometimes you delete. Make it intuitive.

deleted 6y ago
[deleted]
cheez 6y ago
> You don't burn your house down every year because it's cluttered. If you can afford it.... It isn't the worst idea to just start from scratch.
- makapuf 6y ago
  Why not if you give away everything, otherwise its such a waste of resources ...
  - cheez 6y ago
    One of the most memorable experiences of my life was when I was moving out of a place and I had a beautiful loft bed with a slide for my son. I more or less gave it away (or... sold a $1500 bed for $50) and the mother who bought it cried because she said this is the nicest thing she has ever bought for her son. So... If you can afford to do it, do it.
programmarchy 6y ago
This method acts as a forcing function to do exactly that because he tells his team to "recreate the pages they thought were important". If an organization's Wiki really is 75% irrelevant, unused, or incorrect, then a major correction is needed, and "declaring bankruptcy" seems like a good motivational tool to initiate a repair.
- JumpCrisscross 6y ago
  > a good motivational tool to initiate a repair The 75% of articles nobody reads aren’t a problem. The problem is the 20% of articles everyone reads of which 80% is outdated or inconsistent. This solution doesn’t solve that problem. The natural response to this policy is to copy and paste across resets. Not only does that do nothing useful, it risks adding more cruft.
qzw 6y ago
To be fair, what the article proposes is more akin to a parent telling the kids, “pick up all the toys you care about, and anything that’s still on the floor by tomorrow is going to be donated.” My question is why can’t the process be automated? Just make the whole thing behave like a cache with LRU eviction.
- guessbest 6y ago
  But what about the deleting clutter? In the analogy about the kids and the toys should the children be told to throw away toys they don't want to play with?
- aSplash0fDerp 6y ago
  Fresh timestamps on the wrong answer defeats the purpose of a wiki. I`ve personally seen a Fortune 500`s informal wiki/support infrastructure and knowledge consolidation is not as black and white as FIFO or GIGO (it was nonexistent aamaf). Its rare to find an F500 company that has big data analysts working front-line roles to even get a grasp on a consolidation strategy, but shareholders can dream.
- msla 6y ago
  > To be fair, what the article proposes is more akin to a parent telling the kids, “pick up all the toys you care about, and anything that’s still on the floor by tomorrow is going to be donated.” This works because the kids having one specific toy probably doesn't matter. However, having one specific wiki page might matter quite a bit. For example, how often do you perform emergency procedures? Is it often enough that you're going to edit the various emergency procedure pages in your wiki often enough to keep them from the chopping block? How about pages about things which aren't emergencies, but which are involved and delicate and require non-obvious knowledge? Again, how often will you edit those pages? Will you remember all of these vital pages every time the man comes around? Forget one and... You're on the hook for suddenly remembering everything which got deleted a few cycles ago.
JulianMorrison 6y ago
Contrasting pattern: Ise shrine They literally do burn it down periodically, and build another. Because they do this, and plan to do it, the knowledge of how to make it doesn't fade into history.
- cheez 6y ago
  This is actually my coding philosophy. Burn it down and rebuild nearly weekly. The rewrites get smaller, less buggy and more flexible.
- detaro 6y ago
  At non-negligible cost, and without needing to support customers that are still on Shrine 173.5 for Workgroups two rebuilds later ;)
Hayvok 6y ago
This is probably the biggest unsolved problem in the "corporate wiki" space. It's easy to create content, but it's hard to organize it properly, it's even harder to re-organize a large mess, and it's harder still to have a person or team who's job is solely to manage document organization. IMO, the tools themselves are really failing us here. I'm creating a new document? Give me some kind of super-powered organizer algorithm. Auto-suggest the appropriate tags & folder/space location based on the content. I'm an admin and trying to clean up the clutter? Run that same algorithm across the entire space and auto-suggest a better layout & document naming. Make it easy to bulk move/delete documents, folders, etc. Surface old, unvisited documents with no edits & recommend for archiving. Search indexes could also take into account age of the document, # of edits, # of days _since_ an edit, etc. I could go on.
- corty 6y ago
  A corporate wiki is the easiest and simplest form of corporate documentation you can have. If you really want proper, up-to-date, well-written documentation, a wiki isn't for you. A wiki is the first step towards proper documentation just above the "no documentation" stage. If you want to improve on the wild-and-easy stage of everyone just using the wiki however they feel like, just have some rules. For devops work, have a page for all your objects. Track lifetime events (the non-automatic kind) there. Swapped yet another disk in machine b47f8? You'll see the record in the wiki and can maybe also swap the controller or cables. Looking for the local installation procedure of some software? look at the wiki page. Doing another installation on a different host group? put a link in the wiki from hostgroup to software and vice versa. Have page templates for all objects and tasks. The trick is "no change without wiki change". "No identical second support answer without wiki FAQ entry". The trick is documentation discipline. (I know that some tasks may be better served with e.g. proper inventory software, however, there is something to be said for everything documentation-like in one place). Oh, and ffs, never delete history, it will definitely bite you someday.
- zarq 6y ago
  Agree. What you need for most content is not structure; what you need is really great search and discovery tools.
- 6y ago
bartread 6y ago
> This is a terrible idea. You're destroying institutional knowledge because "it's cluttered." It's also a terrible idea because, depending on the type of company and its lifestage, it might also be a colossal waste of time and energy even assuming wiki-rot is a problem you actually have (and that it's causing any damage which, honestly, is a moot point for many companies). Are you really telling me, and especially now, with revenue down in the middle of a global pandemic and economic crisis, that the best use of everybody's time is to trash our internal wiki and start it again rather than, oh, I don't know, work on projects that we can actually charge people money for? What I need most, right now, is for everyone to focus on making it raaaaaaaaaaaaiiiiin. That's not likely to change anytime soon, especially if the economy takes a protracted period to bounce back, as seems likely. More generally I tend to be sceptical of people whose main output is corporate busywork[0]. If there's one thing any kind of recession makes clear it's this: the people you want are the people who either make a valuable product or offer a valuable service that can be sold, and the people who can effectively market and sell those products or services. Everything else is ancillary and, whilst you might need it, you want to run it as lean as possible. This isn't about being ruthlessly mercenary: it's about building a sustainable business with a decent buffer of cash that allows you to ride out the rough times so you can afford and keep paying people rather than be forced to make a load of them redundant. As you've implied, keeping a wiki up to date is a cultural issue, and is something that needs to be done continuously. I think the key here is that sense of active maintenance, and encouraging everybody to be involved. If you change something and that something is referenced in the wiki, you need to change the wiki too otherwise the job isn't done. [0] I imagine the places where wiki rot is most prevalent are those where creating the wiki in the first place was busywork - some sort of checkbox exercise, or a one off project with no thought given to ongoing maintenance.
- PragmaticPulp 6y ago
  > Are you really telling me, and especially now, with revenue down in the middle of a global pandemic and economic crisis, that the best use of everybody's time is to trash our internal wiki and start it again rather than, oh, I don't know, work on projects that we can actually charge people money for? I bet if you forced the managers to set everyone's OKRs or priorities for the quarter, none of them would include "Rewrite Wiki" in the written goals. That's the real problem with these exercises: The intent may be good, but it's a massive amount of work that no one is willing to prioritize over other projects. So instead, the efforts stall out. Furthermore, no one wants to contribute to a new Wiki if they think it will simply be discarded in a few years when the next up-and-coming manager wants to declare Wiki bankruptcy. I worked at a company that was upset that too many people were relying on Slack backlog search to find answers to old questions. They decided to shut down the Slack workspace and start over new to encourage everyone to become less reliant on Slack. This solved nothing, but made everyone's jobs more difficult when they couldn't remember conversations from a few years ago. Worse yet, many teams set up their own separate Slack workspaces, off the record, so they could have control over the destiny of their backlogs. Nothing was solved, but many things became significantly worse.
DiffProg 6y ago
Indeed, this is the same terrible idea I see whenever my next job wants me to switch to the new latest and greatest javascript framework, or the new latest and greatest ML framework. If you never have time to build up the simple knowledge you keep wasting time.

deleted 6y ago

[deleted]

cheez 6y ago

> You don't burn your house down every year because it's cluttered. If you can afford it.... It isn't the worst idea to just start from scratch.

makapuf 6y ago
Why not if you give away everything, otherwise its such a waste of resources ...
- cheez 6y ago
  One of the most memorable experiences of my life was when I was moving out of a place and I had a beautiful loft bed with a slide for my son. I more or less gave it away (or... sold a $1500 bed for $50) and the mother who bought it cried because she said this is the nicest thing she has ever bought for her son. So... If you can afford to do it, do it.

programmarchy 6y ago

This method acts as a forcing function to do exactly that because he tells his team to "recreate the pages they thought were important". If an organization's Wiki really is 75% irrelevant, unused, or incorrect, then a major correction is needed, and "declaring bankruptcy" seems like a good motivational tool to initiate a repair.

JumpCrisscross 6y ago
> a good motivational tool to initiate a repair The 75% of articles nobody reads aren’t a problem. The problem is the 20% of articles everyone reads of which 80% is outdated or inconsistent. This solution doesn’t solve that problem. The natural response to this policy is to copy and paste across resets. Not only does that do nothing useful, it risks adding more cruft.

qzw 6y ago

To be fair, what the article proposes is more akin to a parent telling the kids, “pick up all the toys you care about, and anything that’s still on the floor by tomorrow is going to be donated.” My question is why can’t the process be automated? Just make the whole thing behave like a cache with LRU eviction.

guessbest 6y ago
But what about the deleting clutter? In the analogy about the kids and the toys should the children be told to throw away toys they don't want to play with?
aSplash0fDerp 6y ago
Fresh timestamps on the wrong answer defeats the purpose of a wiki. I`ve personally seen a Fortune 500`s informal wiki/support infrastructure and knowledge consolidation is not as black and white as FIFO or GIGO (it was nonexistent aamaf). Its rare to find an F500 company that has big data analysts working front-line roles to even get a grasp on a consolidation strategy, but shareholders can dream.
msla 6y ago
> To be fair, what the article proposes is more akin to a parent telling the kids, “pick up all the toys you care about, and anything that’s still on the floor by tomorrow is going to be donated.” This works because the kids having one specific toy probably doesn't matter. However, having one specific wiki page might matter quite a bit. For example, how often do you perform emergency procedures? Is it often enough that you're going to edit the various emergency procedure pages in your wiki often enough to keep them from the chopping block? How about pages about things which aren't emergencies, but which are involved and delicate and require non-obvious knowledge? Again, how often will you edit those pages? Will you remember all of these vital pages every time the man comes around? Forget one and... You're on the hook for suddenly remembering everything which got deleted a few cycles ago.

JulianMorrison 6y ago

Contrasting pattern: Ise shrine They literally do burn it down periodically, and build another. Because they do this, and plan to do it, the knowledge of how to make it doesn't fade into history.

cheez 6y ago
This is actually my coding philosophy. Burn it down and rebuild nearly weekly. The rewrites get smaller, less buggy and more flexible.
detaro 6y ago
At non-negligible cost, and without needing to support customers that are still on Shrine 173.5 for Workgroups two rebuilds later ;)

Hayvok 6y ago

This is probably the biggest unsolved problem in the "corporate wiki" space. It's easy to create content, but it's hard to organize it properly, it's even harder to re-organize a large mess, and it's harder still to have a person or team who's job is solely to manage document organization. IMO, the tools themselves are really failing us here. I'm creating a new document? Give me some kind of super-powered organizer algorithm. Auto-suggest the appropriate tags & folder/space location based on the content. I'm an admin and trying to clean up the clutter? Run that same algorithm across the entire space and auto-suggest a better layout & document naming. Make it easy to bulk move/delete documents, folders, etc. Surface old, unvisited documents with no edits & recommend for archiving. Search indexes could also take into account age of the document, # of edits, # of days _since_ an edit, etc. I could go on.

corty 6y ago
A corporate wiki is the easiest and simplest form of corporate documentation you can have. If you really want proper, up-to-date, well-written documentation, a wiki isn't for you. A wiki is the first step towards proper documentation just above the "no documentation" stage. If you want to improve on the wild-and-easy stage of everyone just using the wiki however they feel like, just have some rules. For devops work, have a page for all your objects. Track lifetime events (the non-automatic kind) there. Swapped yet another disk in machine b47f8? You'll see the record in the wiki and can maybe also swap the controller or cables. Looking for the local installation procedure of some software? look at the wiki page. Doing another installation on a different host group? put a link in the wiki from hostgroup to software and vice versa. Have page templates for all objects and tasks. The trick is "no change without wiki change". "No identical second support answer without wiki FAQ entry". The trick is documentation discipline. (I know that some tasks may be better served with e.g. proper inventory software, however, there is something to be said for everything documentation-like in one place). Oh, and ffs, never delete history, it will definitely bite you someday.
zarq 6y ago
Agree. What you need for most content is not structure; what you need is really great search and discovery tools.
6y ago

bartread 6y ago

> This is a terrible idea. You're destroying institutional knowledge because "it's cluttered." It's also a terrible idea because, depending on the type of company and its lifestage, it might also be a colossal waste of time and energy even assuming wiki-rot is a problem you actually have (and that it's causing any damage which, honestly, is a moot point for many companies). Are you really telling me, and especially now, with revenue down in the middle of a global pandemic and economic crisis, that the best use of everybody's time is to trash our internal wiki and start it again rather than, oh, I don't know, work on projects that we can actually charge people money for? What I need most, right now, is for everyone to focus on making it raaaaaaaaaaaaiiiiin. That's not likely to change anytime soon, especially if the economy takes a protracted period to bounce back, as seems likely. More generally I tend to be sceptical of people whose main output is corporate busywork[0]. If there's one thing any kind of recession makes clear it's this: the people you want are the people who either make a valuable product or offer a valuable service that can be sold, and the people who can effectively market and sell those products or services. Everything else is ancillary and, whilst you might need it, you want to run it as lean as possible. This isn't about being ruthlessly mercenary: it's about building a sustainable business with a decent buffer of cash that allows you to ride out the rough times so you can afford and keep paying people rather than be forced to make a load of them redundant. As you've implied, keeping a wiki up to date is a cultural issue, and is something that needs to be done continuously. I think the key here is that sense of active maintenance, and encouraging everybody to be involved. If you change something and that something is referenced in the wiki, you need to change the wiki too otherwise the job isn't done. [0] I imagine the places where wiki rot is most prevalent are those where creating the wiki in the first place was busywork - some sort of checkbox exercise, or a one off project with no thought given to ongoing maintenance.

PragmaticPulp 6y ago
> Are you really telling me, and especially now, with revenue down in the middle of a global pandemic and economic crisis, that the best use of everybody's time is to trash our internal wiki and start it again rather than, oh, I don't know, work on projects that we can actually charge people money for? I bet if you forced the managers to set everyone's OKRs or priorities for the quarter, none of them would include "Rewrite Wiki" in the written goals. That's the real problem with these exercises: The intent may be good, but it's a massive amount of work that no one is willing to prioritize over other projects. So instead, the efforts stall out. Furthermore, no one wants to contribute to a new Wiki if they think it will simply be discarded in a few years when the next up-and-coming manager wants to declare Wiki bankruptcy. I worked at a company that was upset that too many people were relying on Slack backlog search to find answers to old questions. They decided to shut down the Slack workspace and start over new to encourage everyone to become less reliant on Slack. This solved nothing, but made everyone's jobs more difficult when they couldn't remember conversations from a few years ago. Worse yet, many teams set up their own separate Slack workspaces, off the record, so they could have control over the destiny of their backlogs. Nothing was solved, but many things became significantly worse.

DiffProg 6y ago

Indeed, this is the same terrible idea I see whenever my next job wants me to switch to the new latest and greatest javascript framework, or the new latest and greatest ML framework. If you never have time to build up the simple knowledge you keep wasting time.