I worked with a team of 6 remote contractors for a year at my last company. They suffered greatly from a lack of documentation for our project. As it turned out, most people were using saved emails in Outlook as their own personal documentation store. Emails from years ago might describe how to set up a dev environment or deploy code. This left me with an easy solution: I started pasting emails into OneNote and touting them as official documentation.
There was low buy-in from other developers to contribute because many of them already had emails saved. After posting all of my own emails in OneNote, other developers did the same. Some even updated the documents with later threads that less of the organization was included on. If something was incorrect, it was better to have it written down and correct it in text than figure it out and spread the knowledge via word of mouth. It was also better to have poor email documentation than no documentation at all. Quality quickly improved on the poorer pages and the habits of some developers who were referring to old emails for documentation changed when they learned that new emails described better ways of doing things.
> Emails from years ago might describe how to set up a dev environment or deploy code
In some kind of bizarro world that might be encapsulated in a script in version control of some kind instead of a word document in a document management system. Imagine that!
I use zim desktop wiki myself - with the git plugin. Cross platform. Just works. Eventually people want to clone my git repo and read the raw notes I have. It can eventually be imported into a wiki or whatever.
There was low buy-in from other developers to contribute because many of them already had emails saved. After posting all of my own emails in OneNote, other developers did the same. Some even updated the documents with later threads that less of the organization was included on. If something was incorrect, it was better to have it written down and correct it in text than figure it out and spread the knowledge via word of mouth. It was also better to have poor email documentation than no documentation at all. Quality quickly improved on the poorer pages and the habits of some developers who were referring to old emails for documentation changed when they learned that new emails described better ways of doing things.