我在一个复杂的应用程序上工作，其中不同的团队在各自的模块上有一定程度的重叠。前一段时间，我们在部分提示下设置了一个Mediawiki实例。我很难让人们真正使用它，更不用说贡献了。

在共享信息方面，我可以看到很多好处。这至少可以减少我们重新发明轮子的时间。

Wiki的结构不是很好，但是我不确定这是一个问题，只要我们可以搜索所需的内容即可。

有什么提示吗？

解决方案

回答

将使用Wiki的想法出售给开发人员。我们已经确定了一些好处，可以与开发者分享。如果他们看到自己将从中得到一些有价值的东西，那么他们将开始使用它。

什么是维基的示例优势

• 非常适合记下快速的想法或者更长的想法，使我们有更多时间进行正式的写作和编辑。
• 立即协作，无需通过电子邮件发送文档，从而使组保持同步。
• 可通过Web连接从任何地方访问(如果我们不介意以Web浏览器文本形式编写)。
• 归档文件，因为每个页面的修订版本都会保留。
• 令人兴奋，直接和授权-每个人都有发言权。

回答

如前所述，Wiki是非常无组织的。

但是，如果这是开发人员的唯一论点，请投入一些精力来创建一个简单的索引页并保持更新(我们自己动手或者要求人们将他们的贡献链接到索引)。这样，Wiki可能会成长为非常不错且非常全面的文档集，可用于所有工作。

回答

找到团队似乎一次又一次地创建的"粘性"项目(低于3页的文档/图表/等)，并将其发布在Wiki上。确保每个人都可以访问Wiki，并在可能的情况下知道那里的通知机制。幸运的是，下一次他们必须访问而不是从版本控制或者他们的机器中挖掘出来时，他们应该访问Wiki。
如果他们仍然不这样做，请尝试查看团队是否有足够的闲暇时间来实际使用Wiki Subtler的问题，这可能是他们不愿意的原因。

回答

我们不能强迫开发人员做一些他们没有动力去做的事情。不幸的是，像文档这样的Wiki(事实上，Wiki是文档)对于开发人员来说几乎没有任何"酷"的价值。此外，他们已经深入开发工作-我们真的可以通过Wiki来打扰他们吗？

话虽如此，推动Wiki的人员(例如，我们)应该主要负责更新它，如果我们认真对待它，确实会为我们节省很多工作。

我们也可以尝试ff：

• 我们说的结构不是很好-许多人都被结构不良(难以搜索/浏览)的Wiki拒之门外。所以也许你可以先解决
• 也许我们可以要求首席开发人员/项目经理为他们填充问题所在：诸如代码约定和特定项目的API设计之类的内容
• 以身作则：认真记录系统部分。树立先例可能会鼓励其他人也这样做

回答

我做了一些销售，甚至还参加了一些培训课程。我认为某些人由于缺少所见即所得的编辑功能以及从Word或者Outlook中粘贴格式化文本的能力而被关闭。我知道有一些工具可以解决这些问题，但它们仍然是障碍。

在某些区域中，Wiki被用于记录某些区域，但是更新这些区域的人并未对其进行任何其他操作。

我将使用Wiki记录我的专业领域，无论它是方便的大脑扩展。当开始一个新的开发时，我将其用作记事本，以备随其发展而扩展的想法。

即使管理层没有强制要求，也可以在管理层的支持下提供帮助。

回答

我们一段时间以来一直在使用某种形式的Wiki，但是人们加入它确实需要一段时间。我们可能会发现自己将是一段时间以来唯一的一篇写作文章，但是如果忍受，最终其他人也会加入。

如果有人发送包含与项目有关的信息的电子邮件，则可以帮助他们将其指向Wiki的方向，并继续这样做，他们应该获得提示。

我们有一个SharePoint门户，并从那里使用我们自己的品牌自定义的Wiki，以便它"看起来很重要"，我真的觉得这有助于提高它的使用率。

确保每个人都知道Wiki比电子邮件更具非正式性..因为会有一个"恐惧因素"，人们可能会认为自己添加到Wiki的任何内容都会被过度分析。

回答

我认为，到目前为止，大多数答案都出在我们自己插入的内容越多，有用信息的范围就越大，因此，缓慢但肯定地人们会自然地开始使用它。

我们可以使用的另一种方法是：建议每次有人问另一个团队成员有关该项目的问题时，他们都应该像平常一样回答该问题，还应将答案添加到Wiki的一部分中。这可能需要花费几分钟，但是这意味着下次有人提出相同的问题时(他们不可避免地会问)，我们可以通过将他们指向Wiki来节省时间。反过来，这应该可以帮助人们开始使用Wiki作为第一信息来源，并有助于整体使用。

回答

在http://www.ikiw.org/上查看建议

回答

只是为了增加此处提供的一些出色建议...

作为一家小型公司的开发人员，他主要负责6-24个月的合同工作，我发现我的时间通常在开发和编写状态报告之间(在那儿编写文档，情况更糟！) Wiki能够随着我们的前进而散乱无序的思想和注释，使编写报告的痛苦减轻了很多(虽然没有痛苦，但仍然更好)。

此外，如果我们已经进入Mediawiki领域，则可能需要查看SemanticMediawiki。它允许我们通过语义上的标记将数据的组织提升到另一个层次。我知道，这本身并不意味着什么，但是(例如)我可以告诉我们，它可以极大地提高搜索返回的数据的相关性。绝对值得一看。

回答

一些技巧：

每当有人通过电子邮件发送实际上应该在Wiki中的信息时，请为该主题创建一个页面，然后添加他们在电子邮件中添加的内容。然后回复"感谢我们提供该信息，我将其放在此处的Wiki中，以便将来查找。"

同样，如果我们需要共享应该在Wiki中的信息，请将其放在此处，然后仅发送带有链接的电子邮件，而不是向人们发送电子邮件。

当我们要求人们提供信息时，请在其上加上措辞，以便将此类文档放入Wiki中视为默认或者标准："我在Wiki中进行了搜索，但我找不到它。我们是否已将该信息放在此处？"

如果我们是" Wiki冠军"，请确保其他人知道如何使用它，例如"我是否经历过如何与我们一起创建新页面？"

编辑侧边栏以确保它与工作相关。

在相关页面上使用"导航框"样式模板可简化导航。

在首页上放置{{Special：NewPages / 5}}之类的内容或者最近的更改，以便人们可以看到活动。

每隔几天或者每周观察一下最近的更改，如果我们发现某人添加了一些信息而又不致被诱使，请给他们发送电子邮件或者顺便给他们一点赞美。

回答

I have a hard job getting people to actually use it, let alone contribute.

让人们为Wiki做出贡献的最简单方法之一是实际上使他们以Wiki合适的方式提供内容，即，以便他们使用其通常的交流渠道(新闻组，邮件列表，论坛，问题跟踪者)发布任何内容(聊天)，基本上适合包含在Wiki中。

这样其他人(用户/志愿者)可以简单地获取这些内容并将其放在Wiki上。

这听起来比实际要复杂得多，它主要是概括问题和答案，因此它们不一定是对话的一部分，而是可以以独立的方式理解，有意义和有用。

例如，如下所示的问题：

how do I get git to clone a remote repository???

可以这样回答：

Hello,
  Just use git clone git://...

但是，也可以用不太个人化的方式回答问题：

In order to clone a git repository, you will want to use the clone parameter to git:
  git clone git://....

我要说的是，项目中的大多数讨论可以并且应该很容易最终用作文档。通过这种思维方式，文档实际上可以快速增长。我们只需要让人们记住，理想情况下，应该以适合Wiki包含的方式提供有用的信息。

我目睹了几个实例，其中开源项目开始在某种程度上使用这种方法，而有些人(主要是新用户)抱怨答案不是很个人化，但是文档的数量却在稳步增长，因为其他人只是监视着这种讨论，并且开始将此类回复复制/粘贴到Wiki。

基本上，这是让人们为Wiki做出贡献的最简单方法之一，而无需他们自己实际使用它，唯一需要的是思想上的转变。

回答

如果开发人员仍然需要维护"真实的"文档(例如Word文档)，则我认为没有办法在Wiki上进行有意义的复制。

• 人们写两次是没有意义的
• 任何重复的数据都很快会变得不同步。

我目前的客户所做的就是将所有这些转移到Wiki。因此，我只记录一次，并且在Wiki上进行记录。

没关系使用Wiki比使用Word更为繁琐，但是至少该文档是在线的，其他文档可以与它混合使用。

另一个可行的解决方案(imho)是在Subversion上将文档与源一起存储。但是，合并系统还需要能够处理富文本格式等。我不知道是否存在任何解决方案(使用HTML或者LaTex除外，这实际上不是坏选择)。

回答

这里的建议一般。我想补充：

• 我们确实需要一个拥护者-有人将其推向开发人员和管理人员(而不是急躁的-这是一个挑战！)，并在可能的情况下提供支持和教程。此人还需要成为同行(因此是一名开发人员，而不是远程IT部门中的某个人)，并且要真正以客户为中心，即可以根据要求进行更改。
• 说到变化，这里的一些人说维基是非结构化的。我不同意。我们的MediaWiki安装是使用类别进行结构化的，特别是具有两个扩展名：WarnNoCategories(要求用户在保存页面时添加类别)和CategoryTree，以显示所有类别的组合方式(可以从侧边栏链接到)。如果我们有兴趣，我还有更多关于如何保持较低阈值的提示。