IT文档平台[关闭]

我们是一个不断发展的IT运营部门，它将继续为各种客户提供其他产品和支持。随着我们继续保持这种增长，我们发现我们需要轻松访问有关我们IT团队中各种系统和软件的信息和文档。我们的IT部门具有三个主要职能领域，包括：

1. 服务台人员（第1层），
2. 开发人员和程序员，以及
3. 系统管理员/网络管理员/安全分析师（方法2）。

目前，我们已经有了基于MediaWiki的Wiki上存储的方法1的信息，事实证明对于服务台团队而言，这是非常成功的。开发人员和程序员已移至Redmine来跟踪其项目，问题和项目文档。管理员（第2层）没有集中的知识库，而是依赖散布在网络驱动器，个人计算机上的MS Word文件，这些知识仅对特定个体有用，因为他们没有在任何地方进行文档记录，等等。

我们现在面临的挑战是，我们需要一个集中的位置来记录有关第2层的信息和文档。但是，我们已经有了另外两个系统。理想情况下，我们希望有一个文档平台，该文档平台至少要为第1层和第2层工作，并且还可以添加程序员。该平台将需要具有将某些内容分开的能力。例如，在层2级别有一些敏感信息（我们如何构建服务器，可能的用户名等），而层1不需要知道这些信息。此外，第2层应该能够访问第1层及以上的信息。我们考虑过为此扩展MediaWiki安装，但是ACL' 和Wiki用户信息保护似乎没有得到很好的支持，这违背了Wiki核心的开放和轻松访问信息的精神。我正在寻找符合上述列出的标准以及以下其他目标的想法和建议：

1. 最好是免费或开放源代码的软件（和网络工具），因为我们实际上对此没有预算
2. 一个不包含票证元素的平台，因为我们有一个单独的系统来处理第1层和第2层的票务
3. 不需要第1层和第2层项目管理功能的平台
4. 灵活，易于添加文档的产品，包括表，简单标记，语法突出显示，图像，网络图等。
5. 全文搜索功能可能具有自然语言功能
6. 支持文件上传和下载的能力
7. 可能具有RSS或Atom提要和更新的电子邮件警报
8. 允许LDAP身份验证能够集成到现有SSO环境中
9. 不需要大量开发时间或大量自定义代码创建的平台
10. 基于用户，角色，组成员资格，每个单个文档/页面或一组文档/页面的访问控制，因此，如果您无权访问站点/文档/页面/成员资格的该部分，则看不到链接或内容
11. 最好有一个内置的编辑器，以帮助简化数据输入和文档发布
12. 内置版本控制和审核将是更可取的
13. 能够将页面或集合或页面导出为PDF文件
14. 如果我们继续发展壮大，就具有良好的扩展能力
15. 也许支持跟踪使用情况或执行分析的功能
16. 仅用于内部使用，不会面向客户或无法访问
17. 支持管理信息片段的能力，例如操作方法，过程，解决方案，项目，服务器版本，网络文档等。
18. 它不需要社交整合功能
19. 可能支持拥有或添加系统（服务器和客户端计算机）清单的功能
20. 如果必须切换平台，则允许导入MediaWiki信息

此外，在线上有很多地方谈论专家系统，这些专家系统允许创建故障诊断工作流程，类似于流程图或分步向导。这是我们应该考虑在文档平台中选择的东西吗？这将有多大用处？这将有助于第1层更好地执行其工作吗？在线上也有一些信息讨论内容管理和知识管理之间的区别。作为文档平台要求的一部分，我们应该考虑这一点吗？

我知道这是一篇较长的文章，也感谢您可以提供的帮助和反馈。我试图确保我提出正确的问题并涵盖基础，以帮助做出更明智的决定，并实施长期可行的解决方案，以便我们不再继续重做我们刚刚实施。再次感谢您，我期待阅读您分享的内容。

我知道这不是免费的，但是我认为Altassian产品可以满足您的需求。特别是Confluence Wiki可以为您的文档提供帮助，而JIRA模块可以进行问题/错误跟踪。

不必过度简化，但可以想到Sharepoint。

就个人而言，我会选择Wiki（我喜欢Trac）或Plone。

在以前的雇主那里，我们将Plone用于内部知识库应用程序，其中支持具有一定的读写权限，管理具有其他权限，而开发又具有另一权限。

正如SLY所述，Jira和Confluence为此非常有趣。在免费方面，您会想到Trac及其相关的插件。

再一次，您正在寻找免费的厨房水槽，到目前为止，所有推荐的水槽都不能提供所有所需的功能。

如果确实有一些额外的周期，您可以腾出时间来使用，Trac可通过插件进行扩展，因此您可以添加一些所需的功能。

我还认为Wiki最适合您的需求。Wikipedia在功能，目标受众和许可/成本等方面对Wiki软件进行了很好的比较，因此，除了其他答案中的建议外，您还可以在那里查看。

我咬

我和MoinMoin一起运气很好。它是一个Wiki引擎，可支持您所需的大多数内容，并且已被Ubuntu，Apache Foundation等大型组织使用。但是它包括ACL，LDAP集成，页面到PDF的导出以及所见即所得的编辑器。除了所见即所得的编辑器之外，如果您希望使用它来编辑页面，它还支持Wiki标记语言。WYSIWYG界面还支持从Word复制和粘贴，从而可以帮助迁移现有的Word文档。

过去，我使用它的一些内置宏和模板将其用作清单和系统历史记录平台，以允许您使用表单将新设备和事件添加到Wiki。

我看到它可能与您的要求有关的唯一问题是从mediawiki导入数据。确实存在一些脚本，但是它们的边缘有点粗糙并且受到限制。

当然，听起来像是Wiki是正确的方法。产品没有尽头-但是，正如您所说，有时关键功能在其实现中有些特殊（例如，搜索不知道权限子系统会导致受限制的信息泄漏）。

我使用dokuwiki-与大多数wiki一样，它打勾了您所询问的大多数框，但是它相互融合的很好，而且还使我可以非常轻松地将PHP嵌入页面中（尽管对于数量众多的系统而言）对于某些用户，您可以考虑将自定义标签添加到Wiki外部的引用脚本，而不是提供对解释器的直接访问）。它当然可以扩展以支持大量用户，但是基于平面文件，它可以存储的数据量受到限制。

http://www.wikimatrix.org/wiki/comparison提供了一种快速检查功能的方法。

Nuxeo拥有根据LGPL许可的开源文档管理解决方案。

营销宣传：

Nuxeo DM是使用灵活而强大的Nuxeo企业平台技术构建的文档管理解决方案。通过管理和跟踪整个业务周期中的内容流，Nuxeo DM解决了文档复制的常见陷阱，缺乏版本跟踪，耗时的搜索和检索以及安全和访问问题。为什么？仅仅因为文档管理超出了将文档存储在文件服务器上的范围；这是关于管理企业与内容交互的方式。继续阅读以了解为什么我们的客户告诉我们Nuxeo DM是针对其内容和文档管理计划的最佳解决方案。

Alfresco也有一个文档管理解决方案，但这是其企业产品的一部分，而不是开源社区版。

您正在寻找的许多所需功能都可以在Kablink Vibe中找到。

http://sourceforge.net/projects/kablink/

http://www.kablink.org/