我正在为我公司的开发人员设置一种方法来共享有关我们各种内部系统的文档和信息。这包括有助于提高新员工速度的信息，以及用户对系统及其解决方案的常见问题的描述。
对我来说，这似乎是一个理想的维基工作，而且由于我们公司只能托管ASP.NET应用程序，所以我开始研究可用的ASP.NET wiki。 ScrewTurn Wiki似乎是最合适的，它功能非常齐全，有几个可用的插件对我的情况很有用，包括语法高亮和AD集成。然而，在开始将ScrewTurn部署到我们的Intranet的过程中，突然想起，嘿，Sharepoint 2007有一个wiki，而且由于我们已经设置了Sharepoint，我们不能只使用它吗？我对Sharepoint“wiki”进行了一些评估（在引号中因为它几乎没有资格），并且能够证明它由于它的许多缺陷而不合适，我将不在此列出。
现在在这一点上，有人建议我可能根本不需要维基，我们不能只在Word文档中执行所有操作并使用Sharepoint的文档管理功能吗？
所以我正在寻找的是一些额外的弹药，最好是有经验的人。在内部开发人员文档的上下文中，Sharepoint难以或不可能的事例是什么？什么是wiki更好？嘿，我心胸开阔，Sharepoint更好的是什么？
部署维基而不是简单地使用我们现有的维基会有什么价值？
答案 0 :(得分：18)
我希望这会有所帮助 - 加分或不加分：）
如果您正在使用Office文档，则SharePoint Server（SPS）或Windows SharePoint Services（WSS）非常好 - 您可以进行版本，签入/签出，共享，搜索等。我不认为市场上有什么东西接近该功能（它也可以自定义列表和东西）。
但正如你所指出的那样，WIKI功能是不合标准的。
对于开发人员文档，维基更好，因为您可以轻松地链接文档，即使出于开发人员倾向于喜欢wiki标记的唯一原因！使它感觉他们正在编写代码而不是文档。好吧，好吧，我喜欢它。 Word文档？无尽的挫败感，特别是对于代码snippits和像API这样的东西。 Wiki通常会非常非常好地处理代码和结构化格式。
但这是我发帖的主要内容：
如果您可以托管ASP.NET - 如果您有SPS，那么您已经可以了！ - 然后只安装他们两个。创建一个新的IIS虚拟主机，将STW放入该虚拟主机（'cos SPS将在其自己的虚拟主机中）*。按下DNS一点（这样你就可以点击http://wiki或其他东西），然后去吧。
由于它是贵公司内部的，STW具有Windows安全性和版本，因此安全性不是一个大问题。每个页面都可以从任何地方链接 - 毕竟它是一个HTML页面 - 所以如果你真的想要，你可以从SPS wiki链接到它。我想，有一些锁，但不是很多。
在BBC Worldwide，我们使用了许多技术：
运作良好。
至于弹药：SPS如果适合你想做的事情（或者你可以适合它的功能），效果很好。如果没有，你要么被搞砸了，要么需要做很多开发，这实际上是同样的事情：）
但是除了管理层对它的所有有趣之外，我都看不到安装两者的问题。 STW毕竟是免费的。你有服务器。
它得到了开发人员的写作文档，这很少是一件坏事。好吧，如果真正的人类必须阅读它，这是一件坏事，但对于其他开发人员而言，这是一个很好的事情吗？一切都好。
*注意：虚拟主机。不是虚拟的DIRECTORY。
答案 1 :(得分：9)
我做到了。在那些经历之后，这是我的建议：
至于使用wiki的原因，无论是旋转还是分享 - 它在Sharepoint中击败了word文档。要使用Sharepoint，首先您必须下载文档，编辑，上传或使用最好是chancy的Office集成。 Wiki消除了所有的摩擦，使其更新变得简单。消除摩擦是关键，因为当你必须使用word文档时，你最终不会像你应该那样经常更新它们。使用wiki，它是一个2秒弹出/编辑/保存事务。使用单词doc，加载单词，打开文档，编辑，担心格式化，保存等需要几分钟。
答案 2 :(得分：6)
在我看来，没有什么比文档更好的维基。我认为主要是能够创建到目前尚不存在的页面的链接。这样我就可以删除文档，其余的则根据需要填写。它使文档更简洁，更易读。
使用Word文档时，不太可能使用超链接，但它对文档的可读性非常有帮助。我可以继续......
答案 3 :(得分：4)
作为概括，对于技术文档来说，这个词非常糟糕。因为它对于大型结构化文档而言效果很差，所以它鼓励小文档的扩散，而不会在文档之间进行交叉引用。将其扩展到任何显着大小，您将无法找到与您要调查的问题相关的文档。随着时间的推移，你会发现人们浪费越来越多的时间来搜索各种文字文件，电子表格，visio图表甚至是powerpoint图表来查找可能记录或未记录的信息。
将它们放入sharepoint只会强制您通过浏览器进行搜索。
任何技术文档工具都必须支持文档之间的交叉引用，以避免丢失这些引用。维基比任何人都能做得更好。此外，将生成的内容（如数据字典或API文档）纳入维基更容易，并且可以使XRef目标保持稳定。
答案 4 :(得分：3)
以下是适用于SharePoint的开源扩展wiki，可能更合适：
http://www.codeplex.com/CKS/Wiki/View.aspx?title=Enhanced%20Wiki%20Edition&referringTitle=Home
答案 5 :(得分：2)
首先，查看this StackOverflow thread。关于Sharepoint wiki的问题也有类似的问题，而pro和con的答案非常有用，并概述了你的问题中“不可能在Sharepoint中”的部分。
我正在尝试在Sharepoint中实现团队wiki，因为几乎与他完全一样，在将Sharepoint用于团队文档几年之后。我的观察：
我的经验是Sharepoint for documents是体面的。虽然一个好的Sharepoint支持团队可以帮助解决其中的一些问题，但它可能会出现片状，有时会丢失编辑或出现性能问题。我确实发现Sharepoint文档库比在网络上存储东西更好。它使文档和库易于链接。明智地使用元数据属性可以使Sharepoint列表视图对于查看文档是什么，它是什么以及它处于什么状态非常有用，因此我们的分析师，PM，开发人员等一目了然谁都知道球和什么东西等着他们。那是几年前开始的一个项目;今天，Sharepoint 2007的工作流程可能会提供通知。
还有文档的版本控制。但正如其他一些人所指出的那样，在文档中做事需要在编写，下载和共享方面涉及开销和缺陷。检查文档会有所帮助，但松散的加农炮开发人员可以下载文档，编辑文档，然后将它们存储在其他地方，从而破坏版本控制。这发生在我们身上，虽然这是一个纪律问题，而不是Sharepoint的错。
根据Chris Hynes的回答，摩擦是描述问题的好词。为了快速参考团队的内部基础架构详细信息，wiki似乎对我们更有效。维基使数据几乎立即可见，无需先单击链接并等待Word加载。编辑也更快更容易......虽然我仍在尝试使用它，但Sharepoint wiki具有版本控制功能并允许“检查”维基文章。
正如您和其他SO线程所指出的，与其他wiki引擎相比，Sharepoint是轻量级的。它有什么好处？好吧，我正在使用它，因为它在那里，不需要任何特殊的设置，总比没有好，坦率地说，它适用于内部的东西，不一定是健壮的或面向客户的。它很容易卖给老板，因为它不会花费我们已经花费的任何东西。 wiki也不容易被我前面提到的松散的加农炮类型所破坏，并且我们能够在必要时查看审计跟踪或回滚。
添加和交叉链接条目很容易，但如果要嵌入图形，则必须先将它们上传到Sharepoint库。您也可以在wiki中编辑HTML，虽然我不确定它有什么限制，并且控制我认为没有安全访问和Sharepoint Designer时无法使用的CSS。所以除了文本之外的任何东西（比如表格）都不是很强大。
到目前为止，我喜欢将所有内容存储为文档。查看和编辑数据的即时性使维基真正具有优势。这肯定比下拉文档并重新检入更容易。对于普通的文档厌恶开发人员来说，它有助于消除保持信息更新的障碍。
要考虑的其他事项。您是否希望您的开发人员热心并积极参与编辑维基？如果是这样，您可能需要不同wiki引擎的讨论功能。我的开发人员最喜欢;他们最讨厌的两件事是测试和文档。所以我是创建文章解释构建过程，数据库环境用法，应用程序实例，服务器映射，SOX文档核对表等的人。其他开发人员将主要参考它并发布次要更新。我们的版本控制和并发支持没有受到很大压力。
答案 6 :(得分：2)
维基比单词文档更有可能被使用，因为找到编辑或创建新页面的条目比单词文档更快更容易！
然后问题变成哪个维基
几乎所有维基都比SharePoint维基更好，一个超出了笑话
Screwturn非常出色，在v3中有ACL和WYSIWYG，并且很容易扩展
e.g。使用XSLT插件非常适合嵌入服务器进程，CI构建，测试，源代码控制统计等输出
e.g。我们有一个OLEDB插件，可以从各种公司数据库中读取关键值，并将它们嵌入到描述数据内容和应该具有的值的页面中。我们有一个母版页，其中列出了具有超出规定范围的数据的所有页面。 FIT和系统监控工具的混合分类
如果您有一个管理可能“一切”必须在SharePoint中，那么有一些Screwturn插件可以将Screwturn页面呈现为PDF，HTML，xml等（然后您可以转换为docx）并拥有一个脚本dump将每天晚上的拧紧页面更改为SharePoint以进行搜索和“管理”目的
答案 7 :(得分：2)
您可能想查看Confluence，因为它可能是市场上的领先企业wiki。该wiki也有一个SharePoint Connector。作为SharePoint Connector的贡献者之一，我有点偏颇，但如果你不查看那里的一些选项，你可能会对自己造成伤害。 Wiki可以是强大且具有感染力的，但如果维基低于标准，则不会发生这种情况。
答案 8 :(得分：1)
通过将SharePoint wiki与任何其他wiki系统进行比较，没有人会对它感到满意。
所以，不要比较它。它具有维基有用的基本功能：您可以输入（有些）格式丰富的文本，以及指向其他页面的链接，无论它们是否存在。单击指向不存在页面的链接将转到新页面的编辑页面，允许您保存页面。
是的，图片支持很糟糕。您必须先创建图片，然后粘贴图片的URL。所以，花两分钟时间创建一个图片库来发布维基图片。
记住维基的主要目标 - 不要与其他维基工具竞争，而是要快速写下想法，不要停下来构建它们。如果有的话，可以在以后添加结构。
正如其他人所说，telerik提供了Rich Text编辑器的替代品，有一个CodePlex工程（缓慢地）改进，而人们，它是SharePoint - 如果你不喜欢它，你可以自定义它。它是ASP.NET，Web服务和Windows Workflow Foundation。
我不建议任何人出去购买MOSS许可证只是为了实现维基（或博客，就此而言）。但是，如果您已经拥有SharePoint基础结构（可能作为Visual Studio Team System Team Foundation Server的一部分），那么请继续使用它。我见过几个SharePoint维基库曾经非常提高了大型软件开发组织中几个团队可用的开发人员文档的数量和质量。一旦我们关闭了关于其他维基的精彩程度的讨论，就会发生很多文档，就像它应该做的那样。
答案 9 :(得分：0)
我经常使用Sharepoint，我发现它有点慢，各种烦人。如果所有内容都已经是Office文档，并且如果您的公司愿意让每个人的计算机都能快速使用Office版本，那么Sharepoint可以正常工作。如果你有各种各样的Office版本（就像我们一样）那么它就不那么好了。我的机器有一些旧版本的办公组件，并且集成并不总是正常工作。我已经学会了根本不尝试使用集成。
任何一种解决方案最重要的是确保您的员工知道如何使用它。我们早期遇到了一些问题（具有不同名称的文件版本，而不是使用内置于sharepoint中的版本控制），这实际上只是人们培训中的差距。
答案 10 :(得分：0)
我们目前正在使用两者的组合，针对规范和正式文档的sharepoint以及用于“隐性知识”的Wiki。我们的每个解决方案都在wiki中有一个页面，由于易于添加内容，因此非常有效。