I've been trying to figure out the best way to manage information at work. I do this for myself, but also for everyone on the team to be able to contribute, and share info. Various people, some technical, and some non-technical, use various methods for sharing right now:
When I work with other tech divisions we use source control to keep track of documents, files, and code.
The non-tech people on my team like to use a network share to share files. There's a hodgepodge of folders, documents, images, zip files, and things. Some of the files and folders are probably not needed, but no one knows if someone else on the team still needs it or put it there for a reason. Someone like me coming into their system has no idea what anything there is because their convention is not documented. Unless you're using the same excel files as that group of people every day, the rare times when you need the information there you aren't really sure where to go to get it.
Wiki. I got a hosted service that has trac/SVN. I've been using the trac wiki to put in documentation. I get ask the same 10 questions probably 100 times in a year, some a lot more than others. This is always information i've broadcast with well thought out emails to the entire team whenever there is new software, process, or functionality introduced to them, but they end up asking me. It's really frustrating that I go out of my way to create documentation that is usable by the non-tech people for the stuff they use, and also for the techies for the tech stuff, but notice a few weeks later that there are alway people who are doing things that they wouldn't be if they had absorbed that information. So my reasoning behind the wiki is that there is that one place that will have the master version (and revision history) of all the queries, documents, spreadsheets, and documentation they will need. Having the information in a web browser helps it a cohesive experience, with search functionality. The wiki ties the spaghetti mess of files together with the associated documentation.
The one downside to this trac/svn solution isn't really great for non-tech savvy people, savvy? It doesn't have a wysiwyg editor, so they can't paste formated text from any source like a web page or a word doc.
I'm wondering if there are other ways you have to accomplish this that may be better, or if you might have tips. The two wiki systems I've seen used in workplaces were underused. Do you know of a way to get people involved in that? My strategy right now to create an initial store of some common info/scripts/files there. Whenever I find myself sending out info now, I put it into the wiki, and send out the info in an email and include a link to the wiki. My hope is that when they want this info in the future they will go get it from the wiki instead of emailing me. If necessary i create shell wiki pages, some pages with just one paragraph about a specific thing with the idea that the page will get fleshed out with other info later on, and some pages are complete the first time I enter them.
When I work with other tech divisions we use source control to keep track of documents, files, and code.
The non-tech people on my team like to use a network share to share files. There's a hodgepodge of folders, documents, images, zip files, and things. Some of the files and folders are probably not needed, but no one knows if someone else on the team still needs it or put it there for a reason. Someone like me coming into their system has no idea what anything there is because their convention is not documented. Unless you're using the same excel files as that group of people every day, the rare times when you need the information there you aren't really sure where to go to get it.
Wiki. I got a hosted service that has trac/SVN. I've been using the trac wiki to put in documentation. I get ask the same 10 questions probably 100 times in a year, some a lot more than others. This is always information i've broadcast with well thought out emails to the entire team whenever there is new software, process, or functionality introduced to them, but they end up asking me. It's really frustrating that I go out of my way to create documentation that is usable by the non-tech people for the stuff they use, and also for the techies for the tech stuff, but notice a few weeks later that there are alway people who are doing things that they wouldn't be if they had absorbed that information. So my reasoning behind the wiki is that there is that one place that will have the master version (and revision history) of all the queries, documents, spreadsheets, and documentation they will need. Having the information in a web browser helps it a cohesive experience, with search functionality. The wiki ties the spaghetti mess of files together with the associated documentation.
The one downside to this trac/svn solution isn't really great for non-tech savvy people, savvy? It doesn't have a wysiwyg editor, so they can't paste formated text from any source like a web page or a word doc.
I'm wondering if there are other ways you have to accomplish this that may be better, or if you might have tips. The two wiki systems I've seen used in workplaces were underused. Do you know of a way to get people involved in that? My strategy right now to create an initial store of some common info/scripts/files there. Whenever I find myself sending out info now, I put it into the wiki, and send out the info in an email and include a link to the wiki. My hope is that when they want this info in the future they will go get it from the wiki instead of emailing me. If necessary i create shell wiki pages, some pages with just one paragraph about a specific thing with the idea that the page will get fleshed out with other info later on, and some pages are complete the first time I enter them.
Facebook
Twitter