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

问题描述

背景信息

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

这似乎是这是对我的一个维基的理想工作，而且由于我们公司只能承载ASP.NET应用程序，所以我设置了研究可用的ASP.NET维基。 ScrewTurn Wiki 似乎是最合适的一个，它是非常全面的功能，有几个可用的插件，将是对于我的情况，包括语法高亮和AD集成是有用的。

然而，在开始将ScrewTurn部署到我们的内部网络的过程中，突然间记得， 2007年有一个wiki，既然我们已经建立了Sharepoint，我们不能只使用它？我对Sharepointwiki进行了一些评估（引用原因是因为它几乎没有资格），并且能够证明它不适合，因为它有许多缺陷，我不在这里列出。 >

现在在这一点上，有人建议，也许我根本不需要维基，我们不能只在Word文档中做所有事情，而是使用Sharepoint的文档管理功能？

实际问题

所以我要找的是一些额外的弹药，最好是有经验的人。在内部开发人员文档的上下文中，Sharepoint将是困难或不可能的事情的例子？什么是维基更好？我是开放的，什么是Sharepoint更好？

什么将使得部署wiki值得，而不是简单地使用我们已经有？

解决方案

我希望这将是一些使用 - 额外的积分或不是： p>

如果您正在使用Office文档，则SharePoint Server（SPS）或Windows SharePoint Services（WSS）非常好 - 您可以进行版本，签到/共享，搜索等。我不认为市场上有什么东西靠近这个功能（它也定制清单和东西很好）。

但是你指出，WIKI对于开发人员的文档来说，一个wiki可以很好地互相链接文档，甚至是因为开发人员的唯一原因倾向于喜欢wiki标记！感觉他们正在编写代码，而不是文档。好的，我喜欢Word文档？无休止的沮丧，特别是对于代码片段和API这样的东西。维基通常会很好地处理代码和结构化格式。

但是，这里是我发布的要点：

如果您可以托管ASP.NET - 如果您有SPS，您可以已经！ - 然后只是安装他们的两个。做一个新的IIS虚拟主机，把STW放在那个（'COS SPS将在它自己的虚拟主机）*。按一下DNS（所以你可以点击 http：//维基或某些东西），然后去找它。

由于这是公司内部的所有内容，STW具有Windows安全和版本，安全性不是一个巨大的问题。每个页面都可以从任何地方链接 - 它是一个HTML页面，所以你可以从SPS维基中链接到它，如果你真的想。有一些锁定，我猜，但不是很多。

在BBC Worldwide，我们使用了许多技术：

$一些项目的b $ b

• Atlassian Confluence（WIKI）。我喜欢这个维基，但它是一个大型企业系统。


• 螺旋转向部分内部的东西。


• Trac for other other东西（别人用SVN在我们的源代码上设置好了，所以使用了一点 - 很好，我宁愿喜欢它，但是这样做是安全的）


• SPS / WSS文件管理

STW，Trac和SPS之间有链接 - 例如，我们尽量不将文档存储为trac中的附件，

运行良好。

至于弹药：SPS可以正常工作它适合您想要做的（或者您可以适应IT的功能）。如果没有，你要么搞砸了，要么需要做很多开发工具，这真的是一样的：）

我无法看到安装这两个问题。毕竟，STW是免费的。你有服务器。

它得到开发人员的写作文档，这很少是一件坏事。好的，如果真正的人类必须阅读它，但是其他开发者的文档是件坏事？所有的好。

*注意：虚拟HOST。不是虚拟DIRECTORY。

Background Info

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.

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.

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.

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?

The actual question

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?

What will make it worthwhile to deploy a wiki instead of simply using what we already have?

解决方案

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

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).

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

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.

But here's the main point of me posting:

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.

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.

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

• Atlassian Confluence (WIKI) for some projects. I love this wiki, but it IS a big enterprise-y system.
• Screw Turn for some intra-department stuff.
• Trac for some other stuff (someone else set it up with SVN on our source repo, so it's used a little - it's nice, I rather like it, but it's a a*se to setup)
• SPS/WSS for documentation management.

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.

Works well.

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 :)

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屋！