- Do we use a company wiki?
- how about you save the technical documents as part of source control and then have links to them from various source files (to understand how this works see article ... in directory...)
我们使用公司维基吗?
如何将技术文档保存为源代码控制的一部分,然后从各种源文件中链接到它们(要了解其工作原理,请参阅目录中的文章......)
what are the pros and cons of these and other methods? any good tools for this purpose?
这些和其他方法的优点和缺点是什么?为此目的的任何好工具?
If you recommend a wiki, what Wikis would you recommend to use? internal? hosted? free? paid?
如果你推荐一个wiki,你会推荐使用什么样的Wiki?内部?托管?*?付费?
18 个解决方案
#1
20
I'd recommend using a wiki. It works extremely well as a central documentation source and has built-in revision control. Also you can reference the docs in the code via URLs.
我建议使用维基。它作为*文档源非常有效,并具有内置的版本控制。您还可以通过URL引用代码中的文档。
#2
9
People are the most effective knowledge container in your company. And the most effective way to transfer knowledge is from people to people. Wiki's and documentation are useful too but unless your employees are great technical writers written documentation is a terrible way to transfer all but the most trivial knowledge. Writers take years to write a book so you can't expect developers to write quality documentation in a couple of hours.
人是您公司中最有效的知识容器。转移知识的最有效方式是从人到人。 Wiki和文档也很有用,但除非您的员工是伟大的技术作家,否则书面文档是传递除了最琐碎知识之外的所有知识的可怕方式。作家花了数年时间写一本书,所以你不能指望开发人员在几个小时内写出高质量的文档。
The best way to keep knowledge in your organization is to have people work together. Make sure no one works alone. Have people pair-program and review each others code. Organize technical sessions etc.
保持组织知识的最佳方式是让人们一起工作。确保没有人独自工作。让人们配对并审查彼此的代码。组织技术会议等
If you really want to store the knowledge somewhere try to enrich the data. Make it easy to add pictures of whiteboards etc to the wiki. Another problem with written documentation is that people seem to think long winded abstract text is 'professional'. Make sure you keep documentation short, clear and to the point so people will actually read it.
如果你真的想在某个地方存储知识,试着丰富数据。可以轻松地将白板等图片添加到维基。书面文档的另一个问题是人们似乎认为长篇大论的抽象文本是“专业的”。确保您保持文档简短,清晰,以便人们真正阅读它。
#3
6
If you can muster the support, a social medium that has reputation (like this very site) can work extremely well on an intranet. People need a bit of an incentive to feed the knowledge base.
如果您能够获得支持,那么具有声誉的社交媒体(如此网站)可以在Intranet上非常好地工作。人们需要一点动力来养活知识库。
#4
3
I would recommend the MindTouch Deki. It's far more than a wiki, with integrations into a number of other sources, including the ability to integrate it into custom data sources in your organization.
我会推荐MindTouch Deki。它不仅仅是一个wiki,还集成了许多其他来源,包括将其集成到组织中的自定义数据源的能力。
#5
2
Wiki's work well, but we supplement the Wiki with Ignite and Camtasia screencasts. These save time when depicting configuration, etc. Screencasts are easy to do, quick, and you don't have to worry whether you have captured the right detail for your audience in that they rewind / replay the sections that they need to review.
Wiki的工作做得很好,但我们用Ignite和Camtasia的截屏补充了Wiki。这些节省了描述配置等的时间。屏幕录像很容易做到,快速,您不必担心是否为您的受众捕获了正确的细节,因为他们回放/重播他们需要查看的部分。
We've tried knowledge base articles and it makes people lazy - "I don't understand this section" means you'll rewriting a whole bunch. Give a person a screencast and they can make their own notes.
我们已经尝试过知识库文章,它让人们变得懒惰 - “我不明白这一部分”意味着你将重写一大堆。给一个人一个截屏视频,他们可以自己做笔记。
#6
2
The single most important thing about retaining knowledge in a company, regardless of solution, is to enforce people use the system. Wikis are my favorite, but without enforcement from management or team leaders, its hard to maintain that level of useful knowledge -- people hate documenting it seems, especially when it makes them easily replaced.
无论解决方案如何,保留公司知识的最重要的一点是强制人们使用系统。维基是我的最爱,但如果没有管理层或团队领导的强制执行,很难维持这种有用的知识水平 - 人们讨厌记录它,特别是当它很容易被替换时。
#7
2
Wikis are good, but one of their biggest advantages hasn't been mentioned yet. Very often the flaws in documentation are not found by the person who wrote it, because the author doesn't need or read the documentation. Flaws are found when the author is on vacation or out sick, and someone else tries to follow the documentation and part of it doesn't work. Using a Wiki, whatever poor fellow ends up discovering the flaw in the docs can correct it immediately, rather than having to email the author, where it gets buried in the other thousand emails the author got while on vacation, or trying to remember to tell the author after the author gets back.
维基是好的,但他们最大的优势之一尚未被提及。编写者通常不会发现文档中的缺陷,因为作者不需要或阅读文档。当作者休假或生病时会发现缺陷,而其他人则试图遵循文档,其中部分内容不起作用。使用Wiki,任何可怜的家伙最终发现文档中的缺陷都可以立即纠正它,而不必通过电子邮件发送作者,将其隐藏在作者在度假时获得的其他数千封电子邮件中,或者试图记住告诉作者回来之后的作者。
Also, make sure that at least two people know how to do everything, and maintain staffing levels. When someone leaves, it can be very tempting to not replace them if you already have other people who can do everything that they did, but if you now have multiple pieces of infrastructure or code that are each only understood by one person then you are vulnerable. Knowledge transfer from one person to another takes time and hands on work. It isn't easy, but it is infinitely easier than trying to learn an infrastructure or code base from docs alone.
此外,确保至少有两个人知道如何做所有事情,并保持人员配备水平。当有人离开时,如果你已经有其他人可以做他们所做的一切,那么你可能很难取代他们,但如果你现在拥有多个基础设施或代码,每个人只能被一个人理解,那么你就很脆弱。从一个人到另一个人的知识转移需要时间和工作。这并不容易,但它比仅仅从文档中学习基础结构或代码库要容易得多。
#8
1
I've used both methods in the past, and found the wiki format to be the most readily accepted. Storing documents in source control can have impacts around merging versions (obviously dependent upon the source control software in use and methodologies applied). The same is true of wiki-based solutions, but for some reason it has never seemed to present a massive problem in the implementations I've used.
我过去曾使用过这两种方法,并发现wiki格式是最容易接受的。在源代码管理中存储文档会对合并版本产生影响(显然取决于使用的源代码控制软件和应用的方法)。基于wiki的解决方案也是如此,但由于某些原因,它在我使用的实现中似乎从来没有出现过大问题。
The searchability of major wikis is another major factor for its success. It is far easier to look up a search term in a wiki than it is to find a reference to a document in a potentially unrelated piece of code.
主要维基的可搜索性是其成功的另一个主要因素。在维基中查找搜索词比在可能不相关的代码段中查找对文档的引用要容易得多。
<2c />
#9
1
I like wikis. I even use them for my own hobby projects, documenting how I got around nasty problems I don't want to have to deal with again, or maintaining a list of references to relavant resources.
我喜欢维基。我甚至将它们用于我自己的爱好项目,记录我如何解决我不想再次处理的令人讨厌的问题,或维护一份对相关资源的引用列表。
Having many people contribute to such a wiki is even more powerful, however a possibility for discussion is also very important.
让很多人为这样的wiki做出贡献甚至更强大,但讨论的可能性也非常重要。
#10
1
I've actually begun a side project that addresses it. It's still in the planning phases, but I've identified a few areas where technical knowledge is kept in organizations. Now, this this doesn't apply to every organization, but every organization uses at least one of these.
我实际上已经开始了一个解决它的副项目。它仍处于规划阶段,但我已经确定了一些技术知识保存在组织中的领域。现在,这不适用于每个组织,但每个组织至少使用其中一个组织。
- People
- Static Web (Internet and Intranet) Sites
- Books (a company library)
- Books (an individual's books)
- Dynamic Web (Internet and Intranet) Sites
- Databases and Repositories
静态Web(Internet和Intranet)站点
书籍(公司图书馆)
书籍(个人书籍)
动态Web(Internet和Intranet)站点
数据库和存储库
Exactly how you utilize each of these is different, but a key is to get the People to use Static and/or Dynamic Web Sites to capture information, or at least identify where it is in books and repositories. If the people aren't feeding the knowledge houses, then it doesn't matter what technology you use. The knowledge must be current, accurate, and in-depth or it's futile, from what I've been able to gather.
确切地说,如何利用这些中的每一个都是不同的,但关键是让人们使用静态和/或动态网站来捕获信息,或者至少确定它在书籍和存储库中的位置。如果人们没有喂养知识屋,那么使用什么技术并不重要。从我能够收集的知识来看,这些知识必须是最新的,准确的,深入的,或者是徒劳的。
Another key concept that is important, as Vinko Vrsalovic pointed out, is the ability to link the data/information/knowledge back to it's reasoning. A common practice in requirements analysis is the ability to trace the requirement to its source. The same should be said for knowledge. Everyone in the organization can know everything in the world. However, if no one knows WHY that knowledge is useful or WHERE/WHEN to use that knowledge, it's wasted.
正如Vinko Vrsalovic指出的那样,另一个重要的关键概念是将数据/信息/知识与其推理联系起来的能力。需求分析中的常见做法是将需求跟踪到其来源的能力。知识也应如此。组织中的每个人都可以了解世界上的一切。但是,如果没有人知道为什么知识是有用的或何时/何时使用这些知识,那就浪费了。
If I'm missing any, feel free to edit this post or reply as a comment. I think this question will help my project efforts.
如果我遗失任何内容,请随时编辑此帖或回复评论。我认为这个问题将有助于我的项目工作。
EDIT 1: Added Vinko Vrsalovic that it's not just about the knowledge, but linking the data back to the production issues that the knowledge pertains to.
编辑1:添加了Vinko Vrsalovic,它不仅仅是关于知识,而是将数据链接回知识所涉及的生产问题。
#11
1
I've seen that a lot of knowledge discussions happen within email within an organization. This knowledge stays within the email for long and eventually get lost and is not accessible to others who were not part of the original discussion.
我已经看到在组织内的电子邮件中发生了很多知识讨论。这些知识会长时间保留在电子邮件中,最终会丢失,并且不属于原始讨论的其他人无法访问。
Using tools like http://grexit.com can help you move these knowledge out of you inbox to a coomon shared repository within your organization. Currently this works only for Gooogle Apps but its worth the try.
使用http://grexit.com等工具可以帮助您将这些知识从您的收件箱中移到组织内的coomon共享存储库中。目前,这仅适用于Gooogle Apps,但值得一试。
#12
0
Definitely a wiki. We use TWiki and make use of some excellent plugins.
绝对是一个维基。我们使用TWiki并使用一些优秀的插件。
Edit: I forgot to add that you might like to consult the answers for this question on documents and version control.
编辑:我忘了添加您可能想查阅有关文档和版本控制的此问题的答案。
#13
0
Use a wiki, but ensure that someone has editorial ownership of what goes in. That person needs to ensure naming standards and document herarchy are adhered to - it's very easy for a company wiki to become a sprawling mess.
使用维基,但要确保某人对所发生的内容拥有编辑所有权。该人需要确保命名标准并遵守文档层次结构 - 公司维基很容易成为一个庞大的混乱。
#14
0
I'll give you some drawbacks of Wiki's, or where some extra thought maybe required:
我会给你一些Wiki的缺点,或者可能需要一些额外的想法:
- If the technical knowledge/documentation is shared with customers or organisations which do not have access to your Wiki
- Documentation associated with a particular version of software often lives better with the source associated with the release. Often Wiki's contain the most up to date information but it might be hard (depending on the care of editors) to map documentation to older releases
如果技术知识/文档与无权访问Wiki的客户或组织共享
与特定版本的软件相关联的文档通常与发布相关联的源更好。 Wiki通常包含最新的信息,但将文档映射到旧版本可能很难(取决于编辑的注意)
#15
0
I think, the tool you use is not so important. The real important thing is, that all members on your team aggree upon one way and one place for the documentation.
我认为,你使用的工具并不那么重要。真正重要的是,您团队中的所有成员都会在文档的一个方向和一个位置上进行聚合。
You can use a wiki or a notes database or a self-brew application.
您可以使用Wiki或笔记数据库或自酿应用程序。
I personally prefer that all things are in one place. So for technical documentation, the source control system will be the right place. For documentation, which is used by non developers, source control is definitly the wrong place. For accross-the-board docs, maybe a sharepoint server is the tool you should use. It has some kind of version control and is accessible without special client-applications.
我个人更喜欢所有东西都放在一个地方。因此,对于技术文档,源代码控制系统将是正确的位置。对于非开发人员使用的文档,源代码控制肯定是错误的。对于全面的文档,也许sharepoint服务器是您应该使用的工具。它具有某种版本控制,无需特殊的客户端应用程序即可访问。
#16
0
We use a combination of project blog and wiki.
我们使用项目博客和wiki的组合。
I think people felt a bit put off by a wiki - that they felt they needed to enter a few paragraphs at the least to justify the entry - so we started a blog which is useful for capturing little things or things that happen in real-time, e.g, 'I changed column field length from 40 to 50' or 'purged audit table data older than last week'.
我觉得人们觉得维基有些推迟了 - 他们认为至少需要输入几个段落来证明这个条目是合理的 - 所以我们创建了一个博客,它可以捕捉实时发生的小事或事情。例如,'我将列字段长度从40更改为50'或'清除过去一周的审核表数据'。
I expect (hope) that some blog entries will become the source material for longer wiki entries as the project progresses.
我希望(希望)随着项目的进展,一些博客条目将成为更长的wiki条目的源材料。
#17
0
As an alternative to a wiki, consider using SharePoint. It allows you to handle events (like meetings), tasks, and documents. It works very will with the non-technical crowd, which may allow technical writers and managers to take a look at what's going on. It's also part of Windows 2003, so you may not need an additional license for it.
作为Wiki的替代方案,请考虑使用SharePoint。它允许您处理事件(如会议),任务和文档。它非常适合非技术人群,这可能让技术作家和管理人员看看正在发生的事情。它也是Windows 2003的一部分,因此您可能不需要额外的许可证。
On the downside, I can almost guarantee that there will be a luddite who blames you for every minor UI quibble. The higher-ups will probably love it though.
在不利方面,我几乎可以保证会有一个luddite会因为每个小的UI狡辩而责备你。高层可能会喜欢它。
#18
0
You can probably take a look at Associativy. It stores pieces of knowledge as nodes of a graph where edges represent associative (in a human sense) connection. The graph is searchable and explorable in multiple ways, given a set of search terms the software is able to "think" about a suitable association.
你可以看看Associativy。它将知识片段存储为图形的节点,其中边缘表示关联(在人类意义上)连接。该图可以通过多种方式进行搜索和探索,给定一组搜索术语,软件能够“思考”合适的关联。
I's open source and runs on the Orchard CMS, an open source project as well.
我是开源的,也可以在Orchard CMS上运行,这也是一个开源项目。
This was a shameless plug (Associativy is my project), sorry.
这是一个无耻的插件(Associativy是我的项目),抱歉。
Edit: just recognized how old this question is....
编辑:刚认出这个问题有多久了....
#1
20
I'd recommend using a wiki. It works extremely well as a central documentation source and has built-in revision control. Also you can reference the docs in the code via URLs.
我建议使用维基。它作为*文档源非常有效,并具有内置的版本控制。您还可以通过URL引用代码中的文档。
#2
9
People are the most effective knowledge container in your company. And the most effective way to transfer knowledge is from people to people. Wiki's and documentation are useful too but unless your employees are great technical writers written documentation is a terrible way to transfer all but the most trivial knowledge. Writers take years to write a book so you can't expect developers to write quality documentation in a couple of hours.
人是您公司中最有效的知识容器。转移知识的最有效方式是从人到人。 Wiki和文档也很有用,但除非您的员工是伟大的技术作家,否则书面文档是传递除了最琐碎知识之外的所有知识的可怕方式。作家花了数年时间写一本书,所以你不能指望开发人员在几个小时内写出高质量的文档。
The best way to keep knowledge in your organization is to have people work together. Make sure no one works alone. Have people pair-program and review each others code. Organize technical sessions etc.
保持组织知识的最佳方式是让人们一起工作。确保没有人独自工作。让人们配对并审查彼此的代码。组织技术会议等
If you really want to store the knowledge somewhere try to enrich the data. Make it easy to add pictures of whiteboards etc to the wiki. Another problem with written documentation is that people seem to think long winded abstract text is 'professional'. Make sure you keep documentation short, clear and to the point so people will actually read it.
如果你真的想在某个地方存储知识,试着丰富数据。可以轻松地将白板等图片添加到维基。书面文档的另一个问题是人们似乎认为长篇大论的抽象文本是“专业的”。确保您保持文档简短,清晰,以便人们真正阅读它。
#3
6
If you can muster the support, a social medium that has reputation (like this very site) can work extremely well on an intranet. People need a bit of an incentive to feed the knowledge base.
如果您能够获得支持,那么具有声誉的社交媒体(如此网站)可以在Intranet上非常好地工作。人们需要一点动力来养活知识库。
#4
3
I would recommend the MindTouch Deki. It's far more than a wiki, with integrations into a number of other sources, including the ability to integrate it into custom data sources in your organization.
我会推荐MindTouch Deki。它不仅仅是一个wiki,还集成了许多其他来源,包括将其集成到组织中的自定义数据源的能力。
#5
2
Wiki's work well, but we supplement the Wiki with Ignite and Camtasia screencasts. These save time when depicting configuration, etc. Screencasts are easy to do, quick, and you don't have to worry whether you have captured the right detail for your audience in that they rewind / replay the sections that they need to review.
Wiki的工作做得很好,但我们用Ignite和Camtasia的截屏补充了Wiki。这些节省了描述配置等的时间。屏幕录像很容易做到,快速,您不必担心是否为您的受众捕获了正确的细节,因为他们回放/重播他们需要查看的部分。
We've tried knowledge base articles and it makes people lazy - "I don't understand this section" means you'll rewriting a whole bunch. Give a person a screencast and they can make their own notes.
我们已经尝试过知识库文章,它让人们变得懒惰 - “我不明白这一部分”意味着你将重写一大堆。给一个人一个截屏视频,他们可以自己做笔记。
#6
2
The single most important thing about retaining knowledge in a company, regardless of solution, is to enforce people use the system. Wikis are my favorite, but without enforcement from management or team leaders, its hard to maintain that level of useful knowledge -- people hate documenting it seems, especially when it makes them easily replaced.
无论解决方案如何,保留公司知识的最重要的一点是强制人们使用系统。维基是我的最爱,但如果没有管理层或团队领导的强制执行,很难维持这种有用的知识水平 - 人们讨厌记录它,特别是当它很容易被替换时。
#7
2
Wikis are good, but one of their biggest advantages hasn't been mentioned yet. Very often the flaws in documentation are not found by the person who wrote it, because the author doesn't need or read the documentation. Flaws are found when the author is on vacation or out sick, and someone else tries to follow the documentation and part of it doesn't work. Using a Wiki, whatever poor fellow ends up discovering the flaw in the docs can correct it immediately, rather than having to email the author, where it gets buried in the other thousand emails the author got while on vacation, or trying to remember to tell the author after the author gets back.
维基是好的,但他们最大的优势之一尚未被提及。编写者通常不会发现文档中的缺陷,因为作者不需要或阅读文档。当作者休假或生病时会发现缺陷,而其他人则试图遵循文档,其中部分内容不起作用。使用Wiki,任何可怜的家伙最终发现文档中的缺陷都可以立即纠正它,而不必通过电子邮件发送作者,将其隐藏在作者在度假时获得的其他数千封电子邮件中,或者试图记住告诉作者回来之后的作者。
Also, make sure that at least two people know how to do everything, and maintain staffing levels. When someone leaves, it can be very tempting to not replace them if you already have other people who can do everything that they did, but if you now have multiple pieces of infrastructure or code that are each only understood by one person then you are vulnerable. Knowledge transfer from one person to another takes time and hands on work. It isn't easy, but it is infinitely easier than trying to learn an infrastructure or code base from docs alone.
此外,确保至少有两个人知道如何做所有事情,并保持人员配备水平。当有人离开时,如果你已经有其他人可以做他们所做的一切,那么你可能很难取代他们,但如果你现在拥有多个基础设施或代码,每个人只能被一个人理解,那么你就很脆弱。从一个人到另一个人的知识转移需要时间和工作。这并不容易,但它比仅仅从文档中学习基础结构或代码库要容易得多。
#8
1
I've used both methods in the past, and found the wiki format to be the most readily accepted. Storing documents in source control can have impacts around merging versions (obviously dependent upon the source control software in use and methodologies applied). The same is true of wiki-based solutions, but for some reason it has never seemed to present a massive problem in the implementations I've used.
我过去曾使用过这两种方法,并发现wiki格式是最容易接受的。在源代码管理中存储文档会对合并版本产生影响(显然取决于使用的源代码控制软件和应用的方法)。基于wiki的解决方案也是如此,但由于某些原因,它在我使用的实现中似乎从来没有出现过大问题。
The searchability of major wikis is another major factor for its success. It is far easier to look up a search term in a wiki than it is to find a reference to a document in a potentially unrelated piece of code.
主要维基的可搜索性是其成功的另一个主要因素。在维基中查找搜索词比在可能不相关的代码段中查找对文档的引用要容易得多。
<2c />
#9
1
I like wikis. I even use them for my own hobby projects, documenting how I got around nasty problems I don't want to have to deal with again, or maintaining a list of references to relavant resources.
我喜欢维基。我甚至将它们用于我自己的爱好项目,记录我如何解决我不想再次处理的令人讨厌的问题,或维护一份对相关资源的引用列表。
Having many people contribute to such a wiki is even more powerful, however a possibility for discussion is also very important.
让很多人为这样的wiki做出贡献甚至更强大,但讨论的可能性也非常重要。
#10
1
I've actually begun a side project that addresses it. It's still in the planning phases, but I've identified a few areas where technical knowledge is kept in organizations. Now, this this doesn't apply to every organization, but every organization uses at least one of these.
我实际上已经开始了一个解决它的副项目。它仍处于规划阶段,但我已经确定了一些技术知识保存在组织中的领域。现在,这不适用于每个组织,但每个组织至少使用其中一个组织。
- People
- Static Web (Internet and Intranet) Sites
- Books (a company library)
- Books (an individual's books)
- Dynamic Web (Internet and Intranet) Sites
- Databases and Repositories
静态Web(Internet和Intranet)站点
书籍(公司图书馆)
书籍(个人书籍)
动态Web(Internet和Intranet)站点
数据库和存储库
Exactly how you utilize each of these is different, but a key is to get the People to use Static and/or Dynamic Web Sites to capture information, or at least identify where it is in books and repositories. If the people aren't feeding the knowledge houses, then it doesn't matter what technology you use. The knowledge must be current, accurate, and in-depth or it's futile, from what I've been able to gather.
确切地说,如何利用这些中的每一个都是不同的,但关键是让人们使用静态和/或动态网站来捕获信息,或者至少确定它在书籍和存储库中的位置。如果人们没有喂养知识屋,那么使用什么技术并不重要。从我能够收集的知识来看,这些知识必须是最新的,准确的,深入的,或者是徒劳的。
Another key concept that is important, as Vinko Vrsalovic pointed out, is the ability to link the data/information/knowledge back to it's reasoning. A common practice in requirements analysis is the ability to trace the requirement to its source. The same should be said for knowledge. Everyone in the organization can know everything in the world. However, if no one knows WHY that knowledge is useful or WHERE/WHEN to use that knowledge, it's wasted.
正如Vinko Vrsalovic指出的那样,另一个重要的关键概念是将数据/信息/知识与其推理联系起来的能力。需求分析中的常见做法是将需求跟踪到其来源的能力。知识也应如此。组织中的每个人都可以了解世界上的一切。但是,如果没有人知道为什么知识是有用的或何时/何时使用这些知识,那就浪费了。
If I'm missing any, feel free to edit this post or reply as a comment. I think this question will help my project efforts.
如果我遗失任何内容,请随时编辑此帖或回复评论。我认为这个问题将有助于我的项目工作。
EDIT 1: Added Vinko Vrsalovic that it's not just about the knowledge, but linking the data back to the production issues that the knowledge pertains to.
编辑1:添加了Vinko Vrsalovic,它不仅仅是关于知识,而是将数据链接回知识所涉及的生产问题。
#11
1
I've seen that a lot of knowledge discussions happen within email within an organization. This knowledge stays within the email for long and eventually get lost and is not accessible to others who were not part of the original discussion.
我已经看到在组织内的电子邮件中发生了很多知识讨论。这些知识会长时间保留在电子邮件中,最终会丢失,并且不属于原始讨论的其他人无法访问。
Using tools like http://grexit.com can help you move these knowledge out of you inbox to a coomon shared repository within your organization. Currently this works only for Gooogle Apps but its worth the try.
使用http://grexit.com等工具可以帮助您将这些知识从您的收件箱中移到组织内的coomon共享存储库中。目前,这仅适用于Gooogle Apps,但值得一试。
#12
0
Definitely a wiki. We use TWiki and make use of some excellent plugins.
绝对是一个维基。我们使用TWiki并使用一些优秀的插件。
Edit: I forgot to add that you might like to consult the answers for this question on documents and version control.
编辑:我忘了添加您可能想查阅有关文档和版本控制的此问题的答案。
#13
0
Use a wiki, but ensure that someone has editorial ownership of what goes in. That person needs to ensure naming standards and document herarchy are adhered to - it's very easy for a company wiki to become a sprawling mess.
使用维基,但要确保某人对所发生的内容拥有编辑所有权。该人需要确保命名标准并遵守文档层次结构 - 公司维基很容易成为一个庞大的混乱。
#14
0
I'll give you some drawbacks of Wiki's, or where some extra thought maybe required:
我会给你一些Wiki的缺点,或者可能需要一些额外的想法:
- If the technical knowledge/documentation is shared with customers or organisations which do not have access to your Wiki
- Documentation associated with a particular version of software often lives better with the source associated with the release. Often Wiki's contain the most up to date information but it might be hard (depending on the care of editors) to map documentation to older releases
如果技术知识/文档与无权访问Wiki的客户或组织共享
与特定版本的软件相关联的文档通常与发布相关联的源更好。 Wiki通常包含最新的信息,但将文档映射到旧版本可能很难(取决于编辑的注意)
#15
0
I think, the tool you use is not so important. The real important thing is, that all members on your team aggree upon one way and one place for the documentation.
我认为,你使用的工具并不那么重要。真正重要的是,您团队中的所有成员都会在文档的一个方向和一个位置上进行聚合。
You can use a wiki or a notes database or a self-brew application.
您可以使用Wiki或笔记数据库或自酿应用程序。
I personally prefer that all things are in one place. So for technical documentation, the source control system will be the right place. For documentation, which is used by non developers, source control is definitly the wrong place. For accross-the-board docs, maybe a sharepoint server is the tool you should use. It has some kind of version control and is accessible without special client-applications.
我个人更喜欢所有东西都放在一个地方。因此,对于技术文档,源代码控制系统将是正确的位置。对于非开发人员使用的文档,源代码控制肯定是错误的。对于全面的文档,也许sharepoint服务器是您应该使用的工具。它具有某种版本控制,无需特殊的客户端应用程序即可访问。
#16
0
We use a combination of project blog and wiki.
我们使用项目博客和wiki的组合。
I think people felt a bit put off by a wiki - that they felt they needed to enter a few paragraphs at the least to justify the entry - so we started a blog which is useful for capturing little things or things that happen in real-time, e.g, 'I changed column field length from 40 to 50' or 'purged audit table data older than last week'.
我觉得人们觉得维基有些推迟了 - 他们认为至少需要输入几个段落来证明这个条目是合理的 - 所以我们创建了一个博客,它可以捕捉实时发生的小事或事情。例如,'我将列字段长度从40更改为50'或'清除过去一周的审核表数据'。
I expect (hope) that some blog entries will become the source material for longer wiki entries as the project progresses.
我希望(希望)随着项目的进展,一些博客条目将成为更长的wiki条目的源材料。
#17
0
As an alternative to a wiki, consider using SharePoint. It allows you to handle events (like meetings), tasks, and documents. It works very will with the non-technical crowd, which may allow technical writers and managers to take a look at what's going on. It's also part of Windows 2003, so you may not need an additional license for it.
作为Wiki的替代方案,请考虑使用SharePoint。它允许您处理事件(如会议),任务和文档。它非常适合非技术人群,这可能让技术作家和管理人员看看正在发生的事情。它也是Windows 2003的一部分,因此您可能不需要额外的许可证。
On the downside, I can almost guarantee that there will be a luddite who blames you for every minor UI quibble. The higher-ups will probably love it though.
在不利方面,我几乎可以保证会有一个luddite会因为每个小的UI狡辩而责备你。高层可能会喜欢它。
#18
0
You can probably take a look at Associativy. It stores pieces of knowledge as nodes of a graph where edges represent associative (in a human sense) connection. The graph is searchable and explorable in multiple ways, given a set of search terms the software is able to "think" about a suitable association.
你可以看看Associativy。它将知识片段存储为图形的节点,其中边缘表示关联(在人类意义上)连接。该图可以通过多种方式进行搜索和探索,给定一组搜索术语,软件能够“思考”合适的关联。
I's open source and runs on the Orchard CMS, an open source project as well.
我是开源的,也可以在Orchard CMS上运行,这也是一个开源项目。
This was a shameless plug (Associativy is my project), sorry.
这是一个无耻的插件(Associativy是我的项目),抱歉。
Edit: just recognized how old this question is....
编辑:刚认出这个问题有多久了....