开发者文档:Sharepoint文档管理与ScrewTurn Wiki[关闭]

我希望这将是一些使用-额外的分数或没有:)

如果您正在使用office文档,SharePoint Server(SPS)或Windows SharePoint Services(WSS)非常好-您可以进行版本设置、签入/签出、共享、搜索等。我认为市场上没有任何功能可以实现这一功能(它还可以很好地完成自定义列表和其他功能)。

但正如您所指出的,WIKI功能是,嗯,低于标准的。

对于开发人员文档,wiki要好得多,因为您可以轻松地链接文档,即使仅仅是因为开发人员喜欢wiki标记!让人觉得他们在写代码,而不是文档。好吧,我喜欢。Word文档?没完没了的沮丧,尤其是对于代码剪贴画和类似API的东西。Wiki通常能很好地处理代码和结构化格式。

如果您可以托管ASP.NET,并且如果您有SP,那么您已经可以然后只需安装两个。创建一个新的IIS虚拟主机,将STW放入其中(“因为SP将位于其自己的虚拟主机中)*。稍微按摩一下DNS(这样你就可以点击 http://wiki 或者别的什么),然后去做。

• 把螺丝拧到部门内部的东西上。
• 其他东西的Trac(其他人在我们的源回购上用SVN设置了它,所以它使用了一点-它很好,我很喜欢,但它是一个设置的基础)
• SPS/WSS用于文档管理。

效果很好。

至于弹药:如果SPS适合你想做的(或者你可以适合它做的),它就可以很好地工作。如果不是,你要么完蛋了,要么需要做很多开发工作,这其实是一样的:)

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

它让dev写文档,这很少是一件坏事。好吧,如果真的人类必须阅读它,这是一件坏事,但是其他开发人员的文档呢?一切都好。

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

我两者都做过。在这些经历之后,我的建议如下:

• 如果你需要所见即所得而不在乎 关于Sharepoint的膨胀和缺少 功能(wiki过于简单,但是 具有您在应用程序中需要的主要功能 wiki),随它去吧。它作为一个 wiki和帮助商务人士 需要访问维基——要少得多 时间教他们如何使用它等等。
• 如果你能用裸骨和 只需要一个简单的快速维基 灵活多变,你无法战胜

嘿,我在这里有经验。我们开始在工作中使用ScrewTurn,但由于公司已经购买了SharePoint,我们被要求更换。文档质量下降了,因为Word文档与Wiki不匹配,正如其他人指出的,SharePoint的不符合标准。

在我看来,在文档方面,没有什么能比得上wiki。我认为主要是能够创建指向尚不存在的页面的链接。这样我就可以把文档删掉,剩下的就可以根据需要填写了。它使文档更加简洁易读。

一般来说,word对于技术文档来说是非常糟糕的。因为它对大型结构化文档的效果很差,它会鼓励大量的小文档,而文档之间没有交叉引用。将其放大到任何重要的大小,您将很难找到与您试图调查的问题相关的文档。随着时间的推移,你会发现人们浪费越来越多的时间,在一大堆word文档、电子表格、visio图表甚至powerpoint演示文稿中寻找可能记录或不记录的信息。

将它们放入sharepoint只会迫使您通过浏览器进行搜索。

任何技术文档工具都必须支持文档之间的交叉引用,以避免丢失这些引用。wiki实现这一点的效果比word好得多。此外,将生成的内容(如数据字典或API文档)合并到wiki中要容易得多,并且可以使外部参照目标稳定。

以下是一个适用于SharePoint的开源扩展wiki:

http://www.codeplex.com/CKS/Wiki/View.aspx?title=Enhanced%20Wiki%20Edition&referringTitle=Home

首先,退房 this StackOverflow thread . 有人问了一个关于Sharepoint Wiki的类似问题,其中的赞成和反对答案都非常有用,并概述了问题中“Sharepoint中不可能”的部分。

我正试图在SharePoint中实现一个团队wiki,现在几乎和他完全一样,在使用SharePoint为团队文档几年之后。我的意见:

Sharepoint文档库

我的经验是,Sharepoint for documents相当不错。它可能是脆弱的,有时您会丢失编辑或出现性能问题,尽管优秀的Sharepoint支持团队可以帮助您解决其中的一些问题。我确实发现Sharepoint文档库比在网络上存储东西要好。它使文档和库易于链接。明智地使用元数据属性可以使Sharepoint列表视图在查看文档内容、用途和状态方面非常有用,因此我们的分析师、PM、开发人员等都可以一眼就知道谁有权,什么时候有什么事情在等着他们。这是几年前开始的一个项目;今天,Sharepoint 2007的工作流可能会提供通知。

还有文档的版本控制。但正如其他一些人所指出的,在文档中做事情会在编写、下载和共享过程中产生开销和缺陷。签出文档会有所帮助,但松散的cannon开发人员可以下载文档、编辑文档,然后将其存储到其他地方,从而破坏版本控制。这发生在我们身上,尽管这是一个纪律问题,不是Sharepoint的错。

Sharepoint Wiki

根据克里斯·海恩斯(Chris Hynes)的回答,摩擦是描述问题的一个好词。为了快速参考团队内部基础设施的详细信息,wiki似乎更适合我们。wiki使数据几乎瞬间可见,而无需先单击链接并等待Word加载。编辑也更快更容易…尽管我还在尝试,Sharepoint wiki有版本控制,允许“签出”wiki文章。

正如您和另一位SO线程所指出的,与其他wiki引擎相比,Sharepoint是轻量级的。它更擅长什么?嗯,我之所以使用它,是因为它就在那里,不需要任何特殊设置,总比什么都没有好,而且坦率地说,它可以很好地用于内部的东西,而不必是健壮的或面向客户的。向老板推销很容易,因为它不会比我们已经花费的更多。维基也不能轻易地被我前面提到的松散的加农炮类型所破坏,如果必要的话,我们可以查看审计跟踪或回滚。

要考虑的其他事情。您是否希望您的开发人员积极参与编辑wiki?如果是这样,您可能需要另一个wiki引擎的讨论功能。我的开发者和大多数人一样;他们最讨厌的两件事是测试和文档。因此,我是撰写文章解释构建过程、数据库环境使用、应用程序实例、服务器映射、SOX文档清单等的人。其他开发人员将主要参考它并发布一些小的更新。我们的版本控制和并发支持并没有受到很大的压力。

问题就变成了哪个维基

Screwturn非常优秀,在v3中有ACL和WYSIWYG,并且非常容易扩展

e、 使用XSLT插件非常适合嵌入服务器进程、CI构建、测试、源代码管理统计等的输出

e、 g.我们有一个OLEDB插件,可以从各种公司数据库中读取关键值,并将它们嵌入到描述数据是什么以及应该具有什么值的页面中。我们有一个母版页,其中列出了所有数据超出规定范围的页面。有点像FIT和系统监控工具的混合体

你可能想退房 Confluence ,因为它可能是市场上领先的企业wiki。有一个 SharePoint Connector 对于那个维基也是如此。作为SharePoint Connector的贡献者之一,我有点偏颇,但如果您不查看其中的一些选项,可能会对自己造成伤害。wiki可能强大且具有传染性,但如果wiki低于标准,这种情况就不会发生。

通过将SharePoint wiki与任何其他wiki系统进行比较,没有人会对它感到满意。

是的,图片支持很糟糕。您必须先创建图片,然后粘贴图片的URL。因此,花两分钟时间创建一个图片库来发布wiki图片。

正如其他人所说,telerik提供了一个富文本编辑器的替代品,有一个CodePlex Project(缓慢地)在改进,还有,伙计们,它是SharePoint——如果你不喜欢它,你可以自定义它。它是ASP.NET、Web服务和Windows工作流基础。

我不建议任何人仅仅为了实现wiki(或者博客),就去购买MOSS许可证。但是,如果您已经拥有SharePoint基础设施(可能作为VisualStudioTeam Stoundation Team Foundation Server的一部分),那么就去吧。我见过几个SharePoint wiki库过去常常

我经常使用Sharepoint,我觉得它有点慢,而且很烦人。如果所有内容都已经是一个Office文档,并且您所在的公司愿意让每个人的计算机与Office版本保持同步,那么Sharepoint可以正常工作。如果你有各种各样的Office版本(就像我们一样),那么它就不那么好了。我的机器有一些旧版本的office组件,集成并不总是正常工作。我已经学会了根本不尝试使用集成。

这两种解决方案中最重要的是确保您的员工知道如何使用它。我们在早期遇到了一些问题(不同名称的文件版本,而不是使用sharepoint内置的版本控制),这些问题实际上只是人们培训中的空白。

目前,我们将两者结合使用,sharepoint用于规范和正式文档,Wiki用于“隐性知识”。我们的每个解决方案在wiki中都有一个页面,由于易于添加内容,因此效果非常好。