sharepoint - 开发者文档 : Sharepoint Document Management vs. ScrewTurn Wiki

Question

就目前情况而言，这个问题不太适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、民意调查或扩展讨论。如果您觉得这个问题可以改进并可能重新开放， visit the help center以获得指导。

已关闭 11 年前。

背景信息

我正在努力为公司的开发人员建立一种方法来共享有关我们各种内部系统的文档和信息。范围包括有助于新员工快速上手的信息，以及用户在使用系统时遇到的常见问题及其解决方案的描述。

对我来说，这似乎是 wiki 的理想工作，而且由于我们公司只能托管 ASP.NET 应用程序，所以我开始研究可用的 ASP.NET wiki。 ScrewTurn Wiki似乎是最合适的一个，它功能非常齐全，并且有几个可用的插件对我的情况很有用，包括语法突出显示和 AD 集成。

但是，在开始将 ScrewTurn 部署到我们的 Intranet 的过程中，我们突然想起，嘿，Sharepoint 2007 有一个 wiki，而且既然我们已经设置了 Sharepoint，难道我们不能直接使用它吗？我对 Sharepoint“wiki”做了一些评估(用引号引起来，因为它几乎不合格)，并且能够证明它不适合，因为它有许多缺陷，我不会在这里列出。

现在，有人建议我也许根本不需要 wiki，难道我们不能在 Word 文档中完成所有操作并使用 Sharepoint 的文档管理功能吗？

实际问题

所以我正在寻找一些额外的弹药，最好是来自有经验的人。在内部开发人员文档中，使用 Sharepoint 会遇到哪些困难或不可能的事情的示例有哪些？ wiki 更擅长什么？嘿，我思想开放，Sharepoint 更擅长什么？

什么会让部署 wiki 而不是简单地使用我们已有的内容变得值得？

Answer 1

我希望这会有一些用处——无论是否有加分:)

如果您正在处理 Office 文档，SharePoint Server (SPS) 或 Windows SharePoint Services (WSS) 非常好 - 您可以进行版本控制、 checkin / checkout 、共享、搜索等。我认为市场上没有任何产品可以满足您的需要。非常接近该功能(它还可以很好地完成自定义列表和其他内容)。

但正如您所指出的，WIKI 功能是不合标准的。

对于开发人员文档，wiki 更好，因为您可以轻松地互连文档，即使开发人员倾向于喜欢 wiki 标记也是如此!让人感觉他们在编写代码，而不是文档。嗯，好吧，我喜欢。 Word文档？无尽的挫败感，尤其是对于代码片段和 API 之类的东西。 Wiki 通常非常非常好地处理代码和结构化格式。

但这是我发帖的要点:

如果您可以托管 ASP.NET - 并且如果您有 SPS，那么您就可以了! - 然后只需安装它们。创建一个新的 IIS 虚拟主机，将 STW 放入其中(因为 SPS 将位于它自己的虚拟主机中)*。稍微调整一下 DNS(这样你就可以点击 http://wiki 之类的东西)，然后就可以了。

由于这都是您公司内部的，并且 STW 有 Windows 安全性和版本，因此安全性不是一个大问题。每个页面都可以从任何地方链接到 - 毕竟它是一个 HTML 页面 - 因此如果您确实想要的话，您可以从 SPS wiki 链接到它。我猜有一些锁定，但不是很多。

在 BBC Worldwide，我们使用多种技术:

• 某些项目的 Atlassian Confluence (WIKI)。我喜欢这个 wiki，但它是一个大型企业系统。
• 拧紧一些部门内的东西。
• Trac 用于其他一些东西(其他人在我们的源代码库上使用 SVN 设置了它，所以它被使用了一点 - 很好，我很喜欢它，但设置起来很麻烦)
• 用于文档管理的 SPS/WSS。

STW、Trac 和 SPS 之间存在链接 - 例如，我们尽量不要将文档作为附件存储在 trac 中，而是在 SPS 中链接到它们，等等。

效果很好。

至于弹药:如果 SPS 适合你想做的事情(或者你可以适合它所做的事情)，那么它就会很好用。如果没有，你要么被搞砸了，要么需要做大量的开发，这实际上是同一件事:)

但是除了管理层对此感到很有趣之外，我看不出安装两者有什么问题。 STW毕竟是免费的。您有服务器。

并且它可以获取开发人员编写的文档，这很少是一件坏事。好吧，如果真人必须阅读它，那是一件坏事，但是其他开发人员的文档呢？一切都好。

*注:虚拟主机。不是虚拟目录。