#1 Explicit Document ownership. The primary author, as well as team distro list slapped at the top.
#2 Document aging. If a doc goes over X days without review by the author or team, it is listed at the top in yellow/red/etc as some level of "Stale" so others know. This also has the slight shame effect if you're the primary owner and all of your docs are bright red and stale.
#3. Directory structure template that you enforce on your entire org. So when a new team starts, you can have some sort of standardization stamped out around where things are like Design Docs, Runbooks, Meeting notes, etc, etc
I really like the idea of #2. Maybe combined with some way to indicate the 'lifespan' of a piece of documentation at the time of creation. We've got bits of docs lying around that were intended to be updated weekly, and regularly fall to the wayside for months at a time. A way to just tag them as 'weekly' and have them pop to the top of a list in yellow/red when they haven't been updated in 7/10 days, would be useful.
Even if it just ends up being a trigger for people to go 'hey, I cbf updating this anymore' and deleting it. It's better than just keeping it around in limbo forever. Our confluence is a graveyard of useless pages and it's only going to get worse over time. I imagine most are the same.
I'm glad to hear I wasn't the only one experiencing this. When using the Scribe feature I mentioned to mdeeks if anything becomes outdated that was under your purview you will see it at the top of your feed. Didn't want to go down the notification route because I was worried you would get 100 notifications and just learn to ignore them
These are really great suggestions! I have been thinking a bit about ownership and accountability. The author thing is a good idea. Currently I was thinking that when you hover over a given block (e.g. paragraph, table, ect) you would see icons on who created and edited it so you would know who to ask if something wasn't clear.
As for #2 I fully 100% agree, I was going to work that into the Scribe feature (ability to have if-this-then-that actions) so you could say If this document is older than x days mark it as outdated for example.
Automatic aging is a good suggestion, though some mechanism for manual review / rating (and, probably, aging of that) could also be quite useful.
It's easy to build toy systems. My working definition of "complex systems" is "you've got to think before doing something". There are interactions, there are implications, there are consequences.
You can cobble together a small wiki of a handful, or even a few dozen, pages, with ease. As that collection scales, both in page count and page size, the ease of working with the compilation becomes a challenge.
The Unix / Linux world offer a touchpoint. Of documentation, there is source code, in-application help, manpages, alternative documentation (hello, texinfo, please go rethink your meaning for existence), collections such as the Linux Documentation Project (once a gem, now rare to find a HOWTO younger than a decade and a half), various distro wikis and documentation archives.
There is documentation which remains current and useful. The Debian project updates (and creates) manpages (and considers their lack a bug, though not a release-critical one), as well as a trove of its own docs (some now staling a bit, though much still admirably current). My view is that all documentation is a palimsest, and for utility if not archival, old velum must periodically be scraped clean and re-inked with new works.
Memory and memorialisation are themselves a denial of progress and time. This can be useful, certainly, but also handicapping.
Active projects, work teams, and organisational documentation suffer from the challenges of constant flux (project, goals, priorities, personnel), under-resourcing, often a failure of any participants, certainly most, of having an accurate (or mutually consistent) big-picture view. That moment at the end of an RSA Animate lecture where the camera pulls back from the whiteboard and suddenly the entire scope of a talk is presented as a single whole has its analogue in technological work.
Structuring of documentation is a whole 'nother religious war. For books which can only occupy a specific location on a shelf, that's essential. For files or documents within a CSM, various other groupings become more appropriate, and can be flexible, though a nominal "principle map" or route through the major elements of a corpus can certainly be useful. The bound codex provides both random access and explicit ordering of content, principles which are difficult to improve upon.
Online systems which can create on-demand standalone formats (PDF, ePub, HTML) can be a useful hybrid and/or emulation of this.
#1 Explicit Document ownership. The primary author, as well as team distro list slapped at the top.
#2 Document aging. If a doc goes over X days without review by the author or team, it is listed at the top in yellow/red/etc as some level of "Stale" so others know. This also has the slight shame effect if you're the primary owner and all of your docs are bright red and stale.
#3. Directory structure template that you enforce on your entire org. So when a new team starts, you can have some sort of standardization stamped out around where things are like Design Docs, Runbooks, Meeting notes, etc, etc