你如何logging你的工作，stream程和环境？

评论工具。

我们已经尝试了在线维基百科，但是发现了一些限制，这可能是个人的喜好，但包括文档结构，并且最关键的是必须连接到文档服务器。

如果你是离线的或者现场的话，被连接是一个严重的问题（显然你可以通过一个安全的SSL连接来缓解现场等）

我们目前的文件处理是：

• 静态html生成器
• 降价语法
• 分布式版本控制系统

我们有一个“正式”的文档布局，并提供了菜单结构（以及相关的可视化样式的CSS等）

静态HTML生成器

我们使用一个基于cubictemp和一些其他工具的内部静态html生成器： pygments ， docutils 。

生成的页面（不是？）显然很难看，因为我们大多数人/我们的系统pipe理员/程序员知道什么是美观的，但完全缺乏协调。

但是，它提供了/让我们包括configuration文件，示例脚本，PDF等，而不必担心HTML格式的搞砸或担心在哪里可以find它在“服务器”下载。

如果不是HTML，只需将其放在文件夹中，然后添加一个url链接即可。

HTML为布局提供了“潜在的”结构，并且批判性地提供了知识/内容项目之间的“连接”（以及基础结构机制，例如能够创build菜单，表格的内容等）。使用HTML，每个用户现在可以在他们的机器上运行一个小型的Web服务器，无论是lighttpd还是小型的，或者只是用Apache或者IIS来完成。

我们所有的机器都有基本的html服务的咕噜声，并且对我们来说工作得很好。

MARKDOWN语法。

我们使用MARKDOWN，Textish和orStructuredTEXT的混杂版本让我们的创意果汁写文档，而不必担心HTML。

这也意味着每个人都可以使用他们最喜欢的编辑器（我在Windows和* Nix上使用Scintilla），而其他人使用vi / vim。

分布式版本控制系统。

我们使用Git来“分发”用户之间的文档。 哦，我们也使用它的版本容量。

我们的主要优势是我们可以全部更新文档，而无需连接到服务器，也无需发布“完成”作品。 我们都可以在文档的相同部分或不同部分上工作，或者只是使用这些信息。

就个人而言，我讨厌被绑定到服务器更新博客，更不用说维基百科。 Git适合我们。

评论工作stream程

Wiki似乎是知识传播/编纂的“时尚”，但正如其他地方所评论的，所有stream程都难以维持，find最能满足您团队需求和可持续发展的工具组合是需要时间的。

更好的解决scheme最终被发现，而不是强制性的。

我们已经开始在我工作的地方使用DokuWiki了 。

从Dokuwiki的网站：

DokuWiki是一个符合标准，简单易用的Wiki，主要目的是创build任何types的文档。 它针对开发团队，工作组和小公司。 它有一个简单但function强大的语法，可以确保数据文件在Wiki外保持可读性，并简化了结构化文本的创build。 所有数据都存储在纯文本文件中 – 不需要数据库。

我发现Dokuwiki最容易实现，因为它不需要数据库，而且很容易设置。 还有一些插件模块使我能够使用我现有的Active Directory帐户login，而不必为每个人创build帐户，这是我发现的其他许多wiki系统的一大优点。 它还具有典型的版本控制function，您可以在其中查看谁发布了哪些内容，并且可以根据需要轻松回滚到以前的版本。 他们还包括一个可定制的主页，您可以轻松地更改任何types的内容适合您的环境。

Doku Wiki或Sharepoint适合放入图表的其他内容。

你用得很快，在wiki上发布，语法不是很复杂。 组织信息非常容易，以后可以很容易地find其他人。

我使用visio来制作更清晰的解释图（导出为JPEG）。

我们正在使用一个维基。 实际上，我们正在使用MediaWiki。 在MediaWiki之上，我们安装了Semantic Mediawiki扩展 ，它实际上将我们的MediaWiki变成松散types的数据库，我们可以用Category，Title，Contents等查询。

例如，我想说我想查看所有通过群集F路由的networkingcname。我所需要做的就是使用Special：Ask页面来查询[[Category：cname]] [[destination :: cluster_f]] .. 。它会返回所有被归类为cname的页面，其目的地为cluster_f。

我们支持几百个非常不同的客户，因此将这些文档放在一个中心位置（并将它们交叉连接起来，以便将特殊情况保存在文档中，并将其整合在一起）是一件非常方便的事情。 显然，我们的文档需要维护，但是您可以采取更多的“园丁”方法进行维护，因为用于保持大型数据集的mediawiki工具包已经相当成熟。

通过正确的插件， Trac可以成为组合票和维基系统。 这使您的票据可以轻松链接到wiki文章，反之亦然。

我喜欢的几个插件：

• 私人门票插件 。 Trac被build立为一个bugbase，所有的门票和他们的回复都是公开的。 这不适合IT票务系统，但是这个插件修复了这个问题。
• Trac所见即所得插件 。 让我们面对现实，大多数人不会学习wikisyntax让你快乐。 这给了他们一个“你看到的是你得到的”编辑器的门票和维基页面。

Trac还有更多的自定义function。 根据自己的喜好设置和定制Trac系统并不困难！

在我以前的工作中，我使用Twiki。 它工作得很好。

接下来，我倾向于自动化大部分任务，并logging脚本（并不总是有很多enthousiasm，但仍然…）。 logging脚本很容易在devise过程中完成，所以没有真正的开销

两者的结合（以及为脚本使用版本控制）相当不错。

JIRA，Confluence和Word文档的组合。

制度化知识

我们从文件开始。 然后我们将其中的一些存储在Sharepoint库中。 最近我们转到了Sharepoint wiki。 我喜欢维基的低摩擦方式来快速更新内容，尽pipeSharepoint的维基在graphics支持和格式化支持方面留下了一些东西，比如表格。 对文本来说很好，内置的编辑器允许一些基本的HTML格式和有序/无序的列表。 还有其他低成本的Sharepoint替代品。

在我们的帮助台软件Numara的Track-It中，我们也有一些非正式的知识库供我们的支持票使用。 这不是完美的，但它的工作。

让员工使用制度化的知识

我同意你的评估，即把知识制度化只是战斗的一部分。 如果你的组织和人员不习惯“先研究，再问第二”，那么你会发现旧的方式盛行：每个人都会依靠正式和非正式的大师来寻求答案，对于一些人来说，问问总是容易一些你旁边的人比自己search。

处理这将涉及一些变更pipe理; 像大多数成功的变革举措，不仅影响到一个小团队，还将有助于获得pipe理层的认可和支持。 你真的必须在两个方向上build立新的行为。 有人需要捕捉知识，人们需要使用它。 更难的是，人们也需要保持这个数据最新。

只是一些想法：可能需要以正式政策的forms予以鼓励，说明解决的门票和问题需要在知识库或维基中logging下来，然后才能被视为封闭。 另外，通常被问到问题的知识领导者不应该总是按要求提供答案; 他们需要把人们指向维基，并让他们习惯先在那里检查。 另一件事是将数据提供给用户自助，这样可以在问题成为技术人员必须要处理的另一个项目之前解决问题。

我们的服务台系统最好有一个类似于StackOverflow和ServerFault的系统：当input一个问题时，search引擎find相似的项目并提供它们，所以用户甚至可以在提交问题之前查看它们。

在我最近的两个工作场所中，我使用了Sharepoint的Wiki，另外还有一个文档库，其中包含一些文档（如DRP和一次升级计划），这些文档不能轻易创build为Wiki文档。 这些文件有Wiki内的链接。 维基在这方面有很多优点，因为很多人可以编辑，版本是内置的，易于search和访问等。为了快速写下笔记或想法，我使用OneNote或白板。

我之前以论坛的格式（在Lotus Notes和MS Sharepoint中）创build了一些知识库，但是我必须说，很less有人通过它们来查看某个问题是否已经解决。 这样的解决scheme必须来自一个强大而有效的search引擎。

如果你想创build可以在假期使用的文档，请写下来，就好像你试图指导你的父母一样。 这不是100％的傻瓜，但有时帮助。 取决于谁在阅读。

Sharepoint很好。

它的searchfunction有能力索引几乎任何types的文件，使search文件很容易。

它也可以做一些模板，这可以使事情更容易，例如，如果你有一个标准的信息表，为每个你build立的服务器。

它也可以为您的文档版本，所以你有一个文档更改的审计历史。

另外，包含在文件库中的文件可以通过networking，outlook或通过unc共享。

我们已经使用了MediaWiki （与fckeditor）好几年了，但是我必须说如果图片（即截图）处理更容易，那将会很好。 虽然有能力search是必不可less的 – 我发现MediaWiki的search经常错过页面。 也许这只是一个学习更好地search的问题（哪一种方法可以打破让别人做你的工作的简单方法的目的）

目前我们正在谈论如何把所有的东西都转移到MS Sharepoint ，尽pipe并不是他们的wiki。 我认为Sharepoint能够以一种否定wiki的某些优点的方式进行全面的文档search ，所以我们将看到这一点。

（不期待着移植我们目前的所有文档的过程:)）

我们正在使用一个维基。 当然，这个语法需要一些习惯，但我们使用的（twiki）将其数据完全存储为文本文件。 这使得我们可以在发生灾难时轻松读取它们，因为我们可以将它们恢复到任何地方，并通过grep从命令行search它们，并在任何我们喜欢的文本编辑器中阅读它们。

每个服务器都有一个页面，其中包含用于更改pipe理信息，启动/closures和configuration注释的标准子页面集合，以及dns，防火墙和资产信息。

我们正准备转移到某个版本的Sharepoint服务，试图让我们把三个服务器上分散的文档文件混合在一起，谁知道有多less个文件夹。 目前，我们有一个庞大的Excel电子表格，其中包含超文本链接。

不是最好的办法，但是当公司开始的时候，他们从来没有计划过如何处理内部文件，而是留给每个小组来决定如何对他们自己的文件进行分类和存储。 现在，我们正试图融入一个统一的系统，这将围绕Sharepoint产品之一。

在我工作的非政府组织中，我们只是使用放置在关键程序的文件夹中的文本文件。 就个人而言，作为一名系统pipe理员/ Web开发人员，我一直使用分散在树目录中的文本文件的知识库，这是我的Memex ，我写下了几乎所有的东西（个人，工作等）。 这个scheme很容易pipe理使用Jedit真正的瑞士军刀进行文本处理，我发现它的轮廓插件，代码折叠和hypersearchfunction不可缺less的。 所有这一切都通过rsync安全地备份到ssh可访问的远程服务器。

再加上Makelink Firefox Extension ，你就拥有了完美的书签pipe理器。

我们使用flexwiki ，这是一个dotnet和开源。

呃… Fogbugz呢？ 🙂

我们使用ScrewTurn的内容和SharePoint来存储文件/图像。

在这里有一些有趣的事情 – 我喜欢在安全的密码。

我们使用文本文件的组合来快速searchgrep。 和SharePoint更深入的文档（Visio图表等）有组织的集合。

作为Google Apps（企业）客户，我们使用Google站点 – 他们的维基“味道”。 易于使用，我们已经从pipe理员和开发人员的很大采用。

在回答另外一个问题之前，我没有看到这个问题 ，但是现在我们走了。

我们使用一些工具和方法。

• 基础设施组件和软件的function规格 。
• 两个合streamWiki 。 一个用于内部公司文件（政策，程序，内部基础设施和IT等），另一个用于我们的开源软件产品。
• RSpec和黄瓜testing。 我们的软件大部分是用Ruby编写的，而且我们正在练习BDD / TDD ，因此规范testing会驱动实际的代码和文档。
• 内联代码文档。 我们在代码注释中使用RDoc标记。
• 声明式configurationpipe理（ Chef ）。 我们所有的服务器都由厨师进行pipe理，厨师通过食谱和食谱中的有用资源“自我logging”。

我们喜欢Confluence，因为它非常灵活，function强大，function齐全，再加上我们喜欢的票务pipe理软件Jira 。

在以前的公司里，我使用过各种各样的工具和方法，许多人都试图用一个全部的资源（比如Wiki）来保持一切。 问题在于用单一工具来logging各种主题，而不是唯一适合覆盖该主题的工具意味着很多事情根本就不会被logging，因为很难迁移信息。 作为Unix / Linux的极客，我相信每个任务都需要一个特定的工具，而且这个工具应该非常适合这个任务。

这个问题非常好，是我的答案。

我为我的公司做了大部分的文档工作，我在这里开始工作的时候创build的格式是MS Word，用于编辑原始文档，导出为只读的通用版本。 对于只有一个人更新文档的项目来说，这种方法非常有效，而且由于这个人通常是我，pipe理层并没有看到需要改变。

我们已经开始使用Traclogging我们的错误和即将到来的任务，同时使用代码评审的“同行评审”扩展。 这已经得到了我们团队的高度认可，因为协作很简单，而且很容易导航。 其他一些团队成员表示希望开始更多的与规格说明，testing程序和手册进行协作，所以我们正在研究DocBook / XML导出为PDF格式的公共文档，如手册，以及Trac WIKI页面的内部文档，如规格和testing程序。

在我看来，select文档格式时遇到的最大问题是：

1. 创build容易吗？
2. 容易维护吗？
3. 如果别人写了，容易维护吗？
4. 可以导出/转换成其他格式没有太多的麻烦？

1-3让我的生活更加轻松，对于快速生成文档而不用疯狂是很重要的。 我认为第四个是客户端最重要的，因为格式不断变化。 Microsoft Word 2003格式不会永远存在，我们目前的PDF也不是。 我需要确保我们的所有客户都可以阅读我们的文档，而不pipe他们的操作系统或文档阅读器是什么。

我们使用MediaWiki和各种插件，包括SemanticMediaWiki。 SMW很好，因为它将我们的MediaWiki安装变成一个可以随意查询的大型自由格式关系数据库。 需要知道一个网站上的服务器？ 访问它的页面。 需要知道什么网站托pipe在服务器上？ 运行一个查询，它会根据每个网站页面上的正确标签select页面名称。

我不会用我用过的文档系统来回答，而是用我见过的东西，而且我觉得很好： http : //stackexchange.com/

stackexchange是在serverfault下运行的Q＆A平台（从技术上讲它不完全相同，但是对于我们这里我们可以假定它是一样的）。

Fogbugz 使用它 。

有一个来自Fogbugz员工的有趣的博客文章 ，我发现这些引用：

对于产品规格之外的所有目的，我认为公司维基和讨论forms已经受到了致命的打击。

…

由于我们已经开始使用FogBugz.StackExchange.com作为我们的支持平台，所以我从来没有两次回答同样的问题。 我们甚至有一个内部的SE服务器，用于非公众的Q＆A，同样的原则适用于那里。

他们使用stackexchange作为面向客户的知识库和内部知识库。

我有兴趣看看这样的知识交stream问答平台是否会取代公司的wiki。

在我以前的雇主中，我使用Word，Excel和Visio文件收集在一个文件夹中。 所有东西的硬拷贝都放在我办公桌的活页夹里。 我是唯一的IT人员，所以几乎没有其他人需要访问这些信息。

在我目前的雇主中，我们使用Exact Software公司的Macola ES，但是我仍然喜欢用Word编写我的文档，并将它作为附件上传到Macola，而不是使用内置的文档编辑器。

在我的工作场所，我把ScrewTurn Wiki放在我们的一个Windows开发服务器上，并把它连接到我们的SQL Server上。 它运行得非常好，运行速度很快，主要是保持文档的方式。 在部署之后的两周内，我们已经添加了大约60页的信息，只有我们的团队（约10人）。

到目前为止，我们保留了关于当前和过去项目的信息，并且已经开始添加有关应用程序的信息，比如从头开始构build它们，URL和其他重要信息。

我最喜欢的wiki页面之一是工具和库页面。 在那里，我们已经开始添加关于我们最常用的生产力工具和库的信息，其中一个例子就是grepWin，用于Windows中的文本search。

我会强烈推荐检查wiki的完整版本，并find适合您的使用目的，function和部署环境的版本。 我select了ScrewTurn，因为它易于使用，而且我们在本地的WinServer上有很多空闲的空间，但是YMMV。

在某些情况下，我们使用Confluence作为wiki和文档共享点。 我相信当你需要非常广泛地分享这些信息的时候，在线wiki格式是一个首选，当文件被编辑和更新的时候，更重要的是什么。 所以我认为知识库文章最好放在wiki中。

我们正在将我们的信息从networking上的各种文件转移到两个位置：

1. 在我们的Intranet上可用的维基
2. 与该服务器/根目录中的特定服务器相关的信息的副本。

对于networking图， networking记事本 。

另外，在logging什么的时候，记住要logging为什么要configuration它。 这有助于防止看起来像是一个好主意的想法变成错误。

我们发现MediaWiki一直是一个缓慢的起步点，但是一旦IT之外的人感受到添加注释，修改，编辑等是多么的容易，那就变得不可或缺了。 开发人员将其用于内部文档，设施部门。 用于发布通知等等。它不仅仅是一个IT文档工具。