Questions tagged «wiki»

我公司正在寻求改善其市场研究数据管理。 当前的数据管理风格： “嘿，金宝，我们的WhatZit 2.0的图片在哪里？ “是的，我记得那个家伙发给那家公司的电子邮件，给我几分钟搜索我的Outlook” “谁拥有重要竞争对手产品目录的最新副本？我的是2009年生产的。” ...“ Colleen这样做，而且她正在休产假。您必须打电话给她以获取她的工作站密码...” 所需的数据管理风格： 数据按主题（法律，经济，工业，竞争对手）整理得井井有条 对于每个主题，多种媒体类型存储在一起（公司产品图片，新闻稿，联系信息），但仍按类型整齐地排序 数据编辑历史 公用访问（无数据孤岛） 我当时正在考虑建立一个部门Wiki，以供所有用户访问。它似乎满足了以上四个条件，但是我有点担心它对于更高级的功能（如图像库，文章格式设置等）的用户友好性（阅读：对于非技术人员而言是可以理解的）。 这里有没有人为非IT人士设置的Wiki，并且它没有着火，变成鬼城或像Geocities？ 额外的问题：您能看到选择MediaWiki（或任何其他Wiki）解决此问题时有明显的缺点吗？ （我希望你们中的某些人以前会遇到此问题，并且可以提供一些见解...）

35 documentation  cms  wiki 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 每个人都知道，有据可查的软件开发会带来成功。但是，这通常意味着文档中不仅会涉及纯文本，而且还会涉及二进制内容，例如UML图。我听说很多人都这么说。版本控制系统不适用于二进制文件。我完全理解并同意这个问题。我问了几个经验丰富的开发人员，最好的存储文档的位置应该在哪里，而我得到的答案是“ wiki”。Wiki很好，但是我考虑了另一个潜在的问题。存储在版本控制系统中的源代码如何连接到Wiki中的相关文档？假设有人克隆了git或mercurial的存储库。他/她如何轻松找到文件？还是我只是错过了什么？ 我知道某些Wiki系统具有与源代码控制系统集成的能力。但是我关心的不是集成能力。如果您已经从git仓库中克隆了源代码，并且过了一会儿，那么您将在火车上并希望继续在火车上离线工作（这是DVCS的一大功能）。然后您突然意识到，由于您在火车上离线工作，因此您无权访问文档。另一方面，如果文档存储在git存储库中，则可以访问克隆了存储库的文档。

18 documentation  wiki 

我目前正在使用两个系统编写代码文档（上午使用C ++）： 使用Doxygen格式在代码旁边添加有关方法和类成员的文档。在服务器上，Doxygen在源上运行，因此可以在Web浏览器中看到输出 概述页面（描述一组类，应用程序的结构，示例代码等）被添加到Wiki中。 我个人认为这种方法很简单，因为有关成员和类的文档确实与代码接近，而概述页面确实很容易在Wiki中进行编辑（并且还很容易添加图像，表格等）。Web浏览器允许您查看两个文档。 我的同事现在建议将所有内容都放入Doxygen，因为我们可以创建一个包含所有内容的大帮助文件（使用Microsoft的HTML WorkShop或Qt Assistant）。我担心的是，编辑Doxygen样式的文档要困难得多（与Wiki相比），尤其是当您想要添加表，图像等时（或者Doxygen的“预览”工具不需要您生成）代码才能看到结果？） 大型开源（或封闭源）项目使用什么来编写其代码文档？他们还将Doxygen样式和Wiki分开吗？还是他们使用其他系统？ 公开文档的最合适方法是什么？通过Web服务器/浏览器，还是通过大的（几个100MB）帮助文件？ 在编写代码文档时，您采用哪种方法？

13 documentation  documentation-generation  wiki 

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 我正在寻找一个Wiki或类似Wiki的系统来编写和管理软件项目的规范和文档。 我知道有很多Wiki实现可用，但是是否有一些特别适合此类任务的实现？ 实际上，它不必是Wiki，而仅仅是一个可以轻松编写和浏览规格和文档并支持变更跟踪的系统。

9 specifications  wiki 

我正在研究改善需求管理的方法。当前，我们在网站上发布了Word文档。不幸的是，（据我所知）我们无法查看从一个修订版到下一个修订版的更改。我非常希望能够做到这一点，就像使用Wiki或VCS（或两者，就像Wiki在bitbucket上一样！）。 而且，每个文档都描述了开发人员在给定的截止日期之前预期会遇到的变更。在任何地方都没有记录到的累积应用程序功能集合，因此，在尝试快速修复旧版应用程序时，有时很难区分错误和（设计不良）功能。 所以我有一个想法想要得到反馈。关于什么： 使用Wiki，以便我们可以跟踪谁更改了什么时间（主要是查看自上次查看以来是否进行了任何编辑）。 每个产品只有一个Wiki页面，而不是每个截止日期只有一个Wiki页面，以跟上产品的所有功能，而不是应实施的更改。这样，我可以查看页面的特定版本，以查看应用程序在给定时间点应执行的操作，并且可以查看 自上次发布以来对页面的更改，以在下一个截止日期之前实现要求。 Waddayathink？

9 documentation  project-management  wiki  requirements