开发人员文档:Sharepoint 文档管理与ScrewTurn Wiki [英] Developer Documentation: Sharepoint Document Management vs. ScrewTurn Wiki

问题描述

我正在努力为我公司的开发人员设置一种方法，以共享有关我们各种内部系统的文档和信息.这包括有助于让新员工跟上进度的信息，以及用户对系统的常见问题及其解决方案的描述.

I am working on setting up a method for my company's developers to share documentation and information about our various internal systems. This would range from information that would be useful for bringing a new employee up to speed, to descriptions of common problems users have with the systems and their resolutions.

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

This seemed like an ideal job for a wiki to me, and since our company only has the ability to host ASP.NET applications, I set about researching the available ASP.NET wikis. ScrewTurn Wiki seemed to be the most appropriate one, it's very full-featured and there are several plugins available that would be useful for my situation, including syntax highlighting and AD integration.

然而，在开始将ScrewTurn 部署到我们的Intranet 的过程时，突然想起，嘿，Sharepoint 2007 有一个wiki，既然我们已经设置了Sharepoint，我们就不能使用它吗?我对 Sharepoint wiki"做了一些评估.(用引号引起来，因为它勉强合格)，并且能够证明它不适合，因为它有许多缺陷，我不会在这里列出.

However, upon starting the process to have ScrewTurn deployed to our intranet, it was suddenly remembered that, hey, Sharepoint 2007 has a wiki, and since we already have Sharepoint set up, couldn't we just use that? I did a bit of evaluation of the Sharepoint "wiki" (in quotes because it barely qualifies), and was able to demonstrate that it wouldn't be suitable due to its many deficiencies, which I won't list here.

现在，有人建议我可能根本不需要维基，难道我们不能在 Word 文档中完成所有工作并改用 Sharepoint 的文档管理功能吗?

Now at this point, it's been suggested that perhaps I don't need a wiki at all, couldn't we just do everything in Word documents and use Sharepoint's document management functionality instead?

所以我正在寻找一些额外的弹药，最好是有经验的人.在内部开发人员文档的上下文中，有哪些使用 Sharepoint 难以或不可能实现的示例?维基更擅长什么?嘿，我思想开放，Sharepoint 更擅长什么?

So what I'm looking for is some additional ammunition, preferably from people with experience. What are examples of things that will be difficult or impossible with Sharepoint in the context of internal developer documentation? What is a wiki better at? Hey, I'm open-minded, what is Sharepoint better at?

部署 wiki 而不是简单地使用我们已有的东西有什么意义?

推荐答案

我希望这会有用 - 加分与否 :)

I'm hoping this is going to be some use - extra points or not :)

SharePoint Server (SPS) 或 Windows SharePoint Services (WSS) 非常适合处理办公文档 - 您可以版本、签入/签出、共享、搜索等.我认为市场上没有任何东西可以该功能非常接近(它还可以很好地处理自定义列表和其他东西).

SharePoint Server (SPS) or Windows SharePoint Services (WSS) is VERY good if you are working with office documents - you can version, check in/out, share, search etc. I dont think there is anything on the market which comes close for that function (it also does custom lists and stuff really well).

但正如您指出的那样，WIKI 功能不符合标准.

But as you point out, the WIKI function is, well, sub-standard.

对于开发人员文档，维基要好得多，因为您可以轻松地链接文档，即使仅仅是因为开发人员倾向于喜欢 wiki 标记！让人感觉他们在写代码，而不是文档.嗯，好吧，我喜欢.Word文档?无尽的挫败感，尤其是代码片段和 API 之类的东西.Wiki 通常非常非常好地处理代码和结构化格式.

For developer documentation, a wiki is much better, as you can easily interlink documents, and even if for the sole reason that developers tend to LIKE the wiki markup! Makes it feel like they are writing code, not a document. Well, ok, I like it. Word documents? endless frustration, especially for code snippits and things like API's. Wikis' usually handle code and structured formatting really, really well.

但这是我发帖的要点:

如果您可以托管 ASP.NET - 如果您拥有 SPS，您就已经可以了！- 然后只安装它们.创建一个新的 IIS 虚拟主机，将 STW 放入其中('cos SPS 将位于它自己的虚拟主机中)*.稍微按摩一下 DNS(这样你就可以点击 http://wiki 或其他东西)，然后就去做.

If you can host ASP.NET - and if you have SPS you can already! - then just install BOTH OF THEM. Make a new IIS virtual host, put STW in that one ('cos SPS will be in it's own virtual host)*. Massage the DNS a bit (so you can hit http://wiki or something), and just go for it.

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

As it's all internal to your company, and STW has windows security and versions, security isn't a huge issue. Each page can be linked to from anywhere - it's an HTML page after all - so you can link to it from the SPS wiki if you really want to. There is some lock in, I guess, but not a lot.

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

Here at BBC Worldwide, we use a number of technologies:

• 某些项目的 Atlassian Confluence (WIKI).我喜欢这个 wiki，但它是一个大型企业系统.
• 搞一些部门内的事情.
• 跟踪其他一些东西(其他人在我们的源代码库中使用 SVN 进行了设置，因此使用了一些 - 很好，我更喜欢它，但设置起来很麻烦)
• 用于文档管理的 SPS/WSS.

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

there are links between the STW, Trac and SPS - eg we try not to store docs as attachments in trac, rather link to them in SPS, etc.

效果很好.

至于弹药:如果 SPS 适合您想要做的事情(或者您可以适合它的功能)，则它运行良好.如果没有，你要么被搞砸了，要么需要做很多开发，这真的是一回事:)

As for ammo: SPS works well if it fits what you want to do (or YOU can fit what IT does). If not, you are either screwed, or need to do a lot of dev, which is really the same thing :)

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

But aside from management getting all funny about it, I can't see a problem with installing both. STW is free after all. You have server(s).

而且它得到了开发者的写作文档，这很少是坏事.好吧，如果真人必须阅读它是一件坏事，但其他开发人员的文档?一切都很好.

And it gets dev's writing docs, which is seldom a bad thing. Ok, it's a bad thing if real humans have to read it, but docs for other dev's? All good.

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

*note: virtual HOST. Not virtual DIRECTORY.

这篇关于开发人员文档:Sharepoint 文档管理与ScrewTurn Wiki的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！