42 ms·

This is a great approach. How do you deal with outdated info that's still useful to keep around? I have a few internal wiki-pages which are 80% 'stuff I tried

This is a great approach. How do you deal with outdated info that's still useful to keep around? I have a few internal wiki-pages which are 80% 'stuff I tried that doesn't work but I'd like to keep around because the tries are valuable in case I re-visit these angles', 20% 'stuff that worked in the end'. I find the 80% confuse newcomers, and I still have to explain which parts are important.

jabroni_salad 5y ago
I have a separate content category called The Stacks. If you're looking around in there, you are having a bad day, but it's come in handy a few times.
kaycebasques 5y ago
Put it in an "archive" category and auto-insert a header at the top of every page under /archive explaining that it's old and probably outdated but kept around for historical research purposes.
polote 5y ago
The more general concept behind that is called document life cycle. Ideally you would want to have different possible status, like draft, published, verified, outdated, archived. Most wiki tools don't handle that well. And make outdated = archived which is an issue as in your case, will not work, and outdated documents will keep polluting your knowledge base
aerojoe23 5y ago
I like having a section in a project document titled approaches tried and why we're not doing that. It sounds like this maybe whole projects/products that have died. Maybe large titles that say canceled, discontinued, or whatever. On the other hand if you have good version control over the wiki, and a way to search the version history as well, kill the zombies. Just like killing zombies in your code, killing zombies in documentation sounds good. https://www.bitnative.com/2012/10/22/kill-the-zombies-in-your-code/ https://www.bitnative.com/2012/10/22/kill-the-zombies-in-you...
Mezzie 5y ago
I'm in the process of creating an internal documentation wiki + system for my organization. You separate out them out into 2 related parts of documentation. My guess is that you want them in the same wiki page because that's how you wrote it and that's how the information lives in your head since it's all for the same project, but from an information management point of view, they're two different pieces of information with mutually exclusive metadata properties. More broadly, ideally you talk to other people and find out where THEIR 80% 'stuff I tried that doesn't work but I'd like to keep around because the tries are valuable in case I re-visit these angles' information lives and collect it all together and presented in a way where people know going in that they're looking at historical information for the sake of current decision making.

jabroni_salad 5y ago

I have a separate content category called The Stacks. If you're looking around in there, you are having a bad day, but it's come in handy a few times.

kaycebasques 5y ago

Put it in an "archive" category and auto-insert a header at the top of every page under /archive explaining that it's old and probably outdated but kept around for historical research purposes.

polote 5y ago

The more general concept behind that is called document life cycle. Ideally you would want to have different possible status, like draft, published, verified, outdated, archived. Most wiki tools don't handle that well. And make outdated = archived which is an issue as in your case, will not work, and outdated documents will keep polluting your knowledge base

aerojoe23 5y ago

I like having a section in a project document titled approaches tried and why we're not doing that. It sounds like this maybe whole projects/products that have died. Maybe large titles that say canceled, discontinued, or whatever. On the other hand if you have good version control over the wiki, and a way to search the version history as well, kill the zombies. Just like killing zombies in your code, killing zombies in documentation sounds good. https://www.bitnative.com/2012/10/22/kill-the-zombies-in-your-code/ https://www.bitnative.com/2012/10/22/kill-the-zombies-in-you...

Mezzie 5y ago

I'm in the process of creating an internal documentation wiki + system for my organization. You separate out them out into 2 related parts of documentation. My guess is that you want them in the same wiki page because that's how you wrote it and that's how the information lives in your head since it's all for the same project, but from an information management point of view, they're two different pieces of information with mutually exclusive metadata properties. More broadly, ideally you talk to other people and find out where THEIR 80% 'stuff I tried that doesn't work but I'd like to keep around because the tries are valuable in case I re-visit these angles' information lives and collect it all together and presented in a way where people know going in that they're looking at historical information for the sake of current decision making.