作業、プロセス、環境をどのように文書化していますか？
Wiki形式を使用していますか？もしそうなら、どの製品ですか？ （MediaWiki、Confluence、Sharepointなど）
知識ベースを作成しましたか？ （問題/ソリューション指向の短いドキュメント。）
機能するドキュメントを作成するときにどのような課題を見つけますか。休暇に出かけたときに電話を受けられませんか？
私にとって、ドキュメントの作成に関わる組織的な「慣性」がある程度あることがよくあります。それは、タスクを実行できる別の種類の人のようです。次に、howについて考えます。彼らはタスクを実行してそれを説明し、他の誰かがそれを実行できるようにします。誰もがそうすることに抵抗があるわけではない。
更新
これまでの回答には
- 合流
- フレックスウィキ
- フォグバグ
- Mediawiki（fckeditorなどのプラグインを使用）
- 共有ポイント
- TWiki
- Word/Excel/Visioドキュメント
- 文書化されたスクリプト
編集： 監視システムを使用してネットワークを暗黙的に文書化していませんか？ Nagiosは常に、ネットワークの構造を反映するためにparentsディレクティブの使用を推奨しており、notes_urlディレクティブは、wikiまたは他のブラウザベースのドキュメントにリンクできるように設計されています。したがって、ここでは「ドキュメント」は、監視システムの「生きているドキュメント」と、wiki内のより詳細なオフラインドキュメントに分割されています。私はNagiosをじっと見つめるのに多くの時間を費やしているので、できるだけ有益なものにするために努力することは理にかなっています。
ツールに関するコメント。
私たちはオンラインwikiを試しましたが、個人的な好みかもしれませんが、ドキュメントの構造を含み、最も重要なことにはドキュメントサーバーに接続する必要があるいくつかの制限を見つけました。
オフラインまたはオンサイトの場合、接続されていることは重大な問題です（明らかに、セキュアなSSL接続などでオンサイトを軽減できます）。
現在の文書化プロセスは次のとおりです。
- 静的HTMLジェネレーター
- マークダウン構文
- 分散バージョン管理システム
ドキュメントの「正式な」レイアウトがあり、メニューの構造（および視覚的なスタイリングなどの関連するCSS）を提供します
静的HTMLジェネレーター
cubictemp と他のいくつかのツールに基づく社内静的HTMLジェネレーターを使用します： pygments 、 docutils 。
私たち/私たちのシステム管理者/プログラマーのほとんどが美的に美しいものを知っているが、そのようなものを構築するための調整がまったく不足しているため、生成されたページは明らかに醜く見えます。
しかし、設定ファイル、サンプルスクリプト、pdfなどを含めることができます。これは、htmlのフォーマット設定を台無しにしたり、ダウンロード用の「サーバー」のどこにあるかを心配したりする必要はありません。
HTMLでない場合は、フォルダにドロップして、URLリンクを追加します。
HTMLはレイアウトの「潜在的な」構造を提供し、知識/コンテンツアイテム間の「リンク」を提供します（また、メニューやコンテンツのテーブルなどを作成できるなどの基本構造メカニズムも）HTMLを使用すると、各ユーザーはlighttpdか小さなものか、ApacheやIISで完全に動作するかに関係なく、マシン上で小さなWebサーバーを実行します。
私たちのすべてのマシンには、基本的なhtmlサービングのうなり声があり、十分に機能します。
MARKDOWN構文。
MARKDOWN、Textish、および reStructuredTEXT の粗悪なバージョンを使用して、HTMLを気にすることなく「クリエイティブ」ジュースにドキュメントを記述させます。
また、ここでは他のユーザーがvi/vimを使用している間、誰もがお気に入りのエディター（WindowsではScintillaと* Nixを使用）を使用できるようになります。
分散バージョン管理システム。
Git を使用して、ユーザー間でドキュメントを「配布」します。ああ、それもバージョンの容量を使用しています。
私たちの主な利点は、サーバーに接続しなくても、また「完成した」作品を公開しなくても、すべてのドキュメントを更新できることです。私たちは全員、ドキュメントの同じ部分または異なる部分で作業することができます。あるいは、情報を消費することもできます。
個人的には、wikiはもちろんのこと、ブログを更新するためにサーバーに縛られるのが嫌いです。 Gitはうまく機能します。
ワークフローへのコメント
Wikiは知識の普及/体系化の「ファッション」のようですが、他の場所でコメントされているように、すべてのプロセスを維持することが困難になり、チームのニーズを最もよくサポートし、持続可能なツールの組み合わせを見つけるには時間がかかります。
より優れたソリューションは、最終的に発見され、義務付けられることはありません。
DokuWiki を使い始めました。
Dokuwikiのウェブサイトから：
DokuWikiは標準に準拠しており、簡単に使用できるWikiであり、主にあらゆる種類のドキュメントの作成を目的としています。開発者チーム、ワークグループ、および小企業を対象としています。シンプルでありながら強力な構文を備えているため、データファイルがWikiの外部でも読み取り可能であり、構造化テキストの作成が容易になります。すべてのデータはプレーンテキストファイルに保存されます-データベースは必要ありません。
データベースを必要とせず、セットアップも簡単だったので、Dokuwikiを実装するのが最も簡単だと思いました。また、既存の Active Directoryアカウントログオン を使用できるようにするアドインモジュールもありましたが、全員のアカウントを作成する必要はありませんでした。また、誰がどこに投稿したかを確認できる一般的なバージョン管理があり、必要に応じて以前のバージョンに簡単にロールバックできます。また、カスタマイズ可能なホームページも含まれており、環境に最適なコンテンツの種類を簡単に変更できます。
適切なプラグインがあれば、 Trac はチケットとwikiシステムの組み合わせになります。これにより、チケットからWiki記事へのリンクが簡単になります。
私が好きなプラグインのカップル：
- プライベートチケットプラグイン 。 Tracは、すべてのチケットとその応答が公開されるバグベースとして構築されています。これはITチケットシステムには適切ではありませんが、このプラグインはそれを修正します。
- Trac WYSIWYGプラグイン 。それに直面しましょう、ほとんどの人はあなたを幸せにするためにwikisyntaxを学ぶつもりはありません。これにより、チケットとWikiページの両方に対して、「見たとおりの結果が得られます」エディターが提供されます。
Tracにはかなりの数の more カスタマイズがあります。 Tracシステムを好みに合わせてセットアップしてカスタマイズするのは難しくありません。
Doku Wiki または、グラフに収まる他のもののSharepoint。
ウィキへの投稿にかなり早く慣れ、構文はそれほど複雑ではありません。情報を整理し、後で他の人が見つけやすくすることは非常に簡単です。
私はVisioを使用してグラフを作成し、説明を明確にしています（JPEGとしてエクスポート）。
ウィキを使用しています。実際、私たちはMediaWikiを使用しています。 MediaWikiの上に Semantic Mediawiki extension がインストールされています。これにより、実際にMediaWikiが緩やかに型付けされたデータベースになり、カテゴリ、タイトル、コンテンツなどでクエリできるようになります。
たとえば、クラスターFを経由するすべてのネットワークcnameを表示したいとします。必要なのは、Special：Askページを使用して[[Category：cname]] [[destination :: cluster_f]]をクエリすることだけです。 。そして、宛先がcluster_fであるcnameとして分類されているすべてのページを返します。
私たちは数百の非常に異なる顧客をサポートしているので、そのドキュメントを中央の場所に置くこと（そして、特別なケースが文書化されて全体に結び付けられるように相互にリンクさせること）は非常に便利です。明らかに、私たちのドキュメントは維持する必要がありますが、大規模なデータセットを最新に保つためのmediawikiツールキットはすでにかなり成熟しているため、メンテナンスにはより多くの「庭師」アプローチをとることができます。
以前の作業ではTwikiを使用しました。それはかなりうまくいきました。
その次に、ほとんどのタスクを自動化し、スクリプトを文書化する傾向があります（常に多くの熱意をもっているわけではありませんが、それでも...）。スクリプトの文書化は、スクリプトの設計プロセスで簡単に実行できるため、実際のオーバーヘッドはありません...
両方の組み合わせ（およびスクリプトのバージョン管理を使用）は、かなりうまくトリックを行いました。
JIRA、Confluence、Wordドキュメントの組み合わせ。
知識の制度化
ドキュメントから始めました。次に、それらの一部をSharepointライブラリに格納しました。その後、最近、Sharepoint wikiに移動しました。 Sharepointのwikiは、グラフィックスのサポートやテーブルなどのフォーマットのサポートで望まれるいくつかのものを残していますが、私はwikiの低摩擦アプローチが好きです。テキストは問題なく、組み込みのエディタは、いくつかの基本的なHTMLフォーマットと順序付き/順序なしリストを許可します。 Sharepointの他の低コストの代替品があります。
ヘルプデスクソフトウェアのNumaraのTrack-Itには、サポートチケット用の非公式なナレッジベースもあります。完璧ではありませんが、動作します。
制度化された知識を使用するためのスタッフの取得
知識を制度化することは戦いの一部に過ぎないというあなたの評価に同意します。組織と人々が「最初に調査し、次に質問する」ことに慣れていない場合は、古い方法が普及していることがわかります。誰もが公式および非公式の教祖に答えを求め、一部の人々にとっては常に簡単に尋ねることができます。自分で検索するよりもあなたの隣にいる人。
これに対処するには、変更管理が必要になります。小さなチーム以上に影響を与える最も成功した変更イニシアチブと同様に、経営陣の承認とサポートを得るのに役立ちます。あなたは本当に2つの方向で新しい行動を築く必要があります。誰かが知識を取得する必要があり、人々はそれを使用する必要があります。さらに難しいのは、人々がそのデータを最新に保つ必要があることです。
ただいくつかのアイデア：おそらく解決されたチケットと問題がクローズされたと見なされる前にナレッジベースまたはwikiに文書化される必要があると述べる正式なポリシーの形で励ましが必要になるでしょう。さらに、通常は質問を受けるナレッジリーダーは、必ずしも要求に応じて回答を提供するだけではありません。彼らは人々にウィキを紹介し、最初にそこをチェックすることに慣れる必要があります。もう1つのことは、ユーザーがデータをセルフヘルプで利用できるようにすることです。そうすることで、技術スタッフが対応しなければならない別の項目になる前に問題を解決できる可能性があります。
ヘルプデスクシステムがStackOverflowやServerFaultに似たシステムを備えているのは何がいいでしょうか。質問を入力すると、検索エンジンが同様のアイテムを見つけて提供するので、ユーザーは質問を送信する前でもそれらを見ることができます。
最後の2か所の作業では、SharepointのWikiと、Wikiドキュメントとして簡単に作成できない特定のドキュメント（DRPや1回限りのアップグレードプランなど）を含むドキュメントライブラリを併用しました。これらのドキュメントには、Wiki内からのリンクが含まれていました。 Wikiには、この領域で多くの利点があります。多くの人が編集できるため、バージョニングが組み込まれており、検索やアクセスが簡単です。メモやアイデアをすばやく書き留めるために、OneNoteまたはホワイトボードを使用します。
以前にいくつかのナレッジベースをフォーラム形式（Lotus NotesとMS Sharepointの両方）で作成しましたが、特定の問題が既に解決されているかどうかを確認するために、ほとんどの人がそれらを介して見ているとは言えません。このようなソリューションは、非常に強力で効果的な検索エンジンを備えた初日から生まれるものでなければなりません。
休暇中に使えるドキュメントを作成したい場合は、両親に教えるように書いてください。これは100％フールプルーフではありませんが、ときどき役立ちます。誰がそれを読んでいるかによります。
Sharepointは素晴らしいです。
その検索機能は、ほぼすべてのタイプのドキュメントにインデックスを付ける機能を備えているため、ドキュメントの検索が非常に簡単になります。
テンプレートを作成することもできます。たとえば、構築するサーバーごとに標準の情報シートがあると、作業が簡単になります。
また、ドキュメントのバージョン管理もできるため、ドキュメントの変更履歴を監査できます。
さらに、ドキュメントライブラリに含まれているファイルには、Web、Outlook、またはunc共有を介してすぐにアクセスできます。
私たちは数年前からMediaWiki（fckeditorを使用）を使用してきましたが、画像（スクリーンショット）の処理が簡単だったらいいと思います。そして、検索機能を備えていることは不可欠ですが、MediaWikiの検索ではページが見つからないことがよくあります。おそらくそれは、より良い検索方法を学ぶことの問題です（これは、他の人があなたの仕事をするための簡単な方法を持つという目的を打ち負かすものです）
現在、すべてをMS Sharepointに移動することについて話し合っていますが、必ずしもwikiに移動する必要はありません。 Sharepointはドキュメント全体の検索を使用してWikiの利点の一部を無効にすることができるので、これがどこにあるかを見ていきます。
（しかし、現在のすべてのドキュメントを移植するプロセスを楽しみにしています:)）
ウィキを使用しています。構文に慣れるまで少し時間がかかりましたが、使用している構文（twiki）では、そのデータを完全にテキストファイルとして保存しています。これにより、災害発生時に簡単に読み取ることができます。どこにでも復元でき、コマンドラインからgrepを介して検索し、好きなテキストエディターで読み取ることができます。
すべてのサーバーにはページがあり、変更管理情報、起動/シャットダウン、構成メモ、およびDNS、ファイアウォール、アセット情報のサブページの標準コレクションがあります。
私が働いているNGOでは、重要な手順のためにフォルダーに配置されたテキストファイルを使用しています。個人的にはシステム管理者/ Web開発者のハイブリッドとして、ツリーディレクトリに散らばったテキストファイルのナレッジベースを使用してきました。これは、私の Memex であり、その上にあるほとんどすべてのもの（個人、仕事など）をダウンさせます。このスキームは、テキスト処理用の実際のスイスアーミーナイフ Jedit を使用して管理するのが非常に簡単です。アウトラインプラグイン、コードの折りたたみ、ハイパーサーチを見つけました不可欠な機能。これらすべては、rsyncによってsshアクセス可能なリモートサーバーに安全にバックアップされます。
これを Makelink Firefox拡張機能 と組み合わせると、完璧なブックマークマネージャーができます。
SharePointサーバーのいくつかのバージョンに移行して、3つのサーバーに分散しているWord文書とフォルダーの数がわかっているWord文書の混合を回避する準備をしています。現在、そこに記述されているドキュメントへのハイパーリンクを含む大規模なExcelスプレッドシートがあります。
最善の方法ではありませんが、会社が設立されたとき、社内ドキュメントの処理方法を計画することはなく、各グループに任せて、自分のドキュメントを適切に並べ替えて保存する方法を決定していました。現在、Sharepoint製品の1つを中心とする統合システムに統合しようとしています。
この質問は this one の複製であり、私はそこに私の回答を移動しました。
別の質問 と答える前に、この質問を見なかったが、ここに行く。
私たちは多くのツールと方法を使用しています。
- 機能仕様 インフラストラクチャコンポーネントおよびソフトウェア用。
- 2つ Confluence Wiki 。 1つは社内のドキュメント（ポリシー、手順、内部インフラストラクチャとITなど）用であり、もう1つはオープンソースソフトウェア製品用です。
- RSpec および Cucumber テスト。私たちのソフトウェアは主にRubyで書かれており、 [〜＃〜] bdd [〜＃〜] / [〜＃〜] tdd [〜＃〜] を練習しているので、仕様テストは実際のコードを駆動し、文書化も行います。
- インラインコードドキュメント。コードのコメントでは RDoc マークアップを使用します。
- 宣言的な構成管理（ Chef ）。すべてのサーバーはChefで管理されています。Chefは、レシピやクックブックに記述されたリソースを通じて「自己文書化」します。
Confluenceは非常に柔軟で強力で機能が充実しているため、気に入っています。さらに、好きなチケット管理ソフトウェア Jira と連携しています。
私が働いていた以前の会社では、さまざまなツールと方法を使用しており、多くの人がすべてに対して単一のキャッチオールリソース（Wikiなど）にとどまろうとしました。それに関する問題は、そのトピックをカバーするのに特に適していない単一のツールでさまざまなトピックを文書化することであり、情報を移行することが難しいため、多くのことはまったく文書化されません。 Unix/Linuxオタクとして、各タスクには特定のツールが必要であり、そのツールはそのタスクに非常によく適合するはずです。
コンテンツにはSharePointを使用し、ドキュメント/画像の保存にはSharePointを使用しています。
いくつか興味深い点があります ここ -私は金庫のパスワードについてのものが好きです。
私が使用したドキュメンテーションシステムではなく、seenを使用して、私が非常に良いと思うもので答えます： http： //stackexchange.com/
stackexchangeは、serverfaultの下で実行されるQ＆Aプラットフォームです（厳密には、厳密には同じではありませんが、ここでは、同じ目的であると想定できます）。
Fogbugz 使用 。
興味深い ブログの投稿 があり、Fogbugzの従業員がこれらの引用を見つけました。
製品仕様以外の目的のために、企業のWikiとディスカッションフォームは致命的な打撃を受けたと思います。
...
サポートプラットフォームとしてFogBugz.StackExchange.comを使い始めて以来、同じ質問に2回答えたことはありません。公開されていないQ＆Aに使用する内部SEサーバーもあり、同じ原則がそこで適用されます。
彼らは顧客向けのナレッジベースと内部ナレッジベースにstackexchangeを使用します。
このような知識交換Q＆Aプラットフォームが企業のWikiに取って代わるかどうか興味があります。
ドットネットとオープンソースである flexwiki を使用します。
えっと...フォッグバグズは？ :)
私は私の会社のドキュメントのほとんどを行い、ここで作業を開始したときに確立された形式は、編集可能なオリジナルのMS Wordで、PDFに読み取り専用の一般リリース用にエクスポートされました。 1人だけがドキュメントを更新しているプロジェクトの場合もそうです。その人は通常私なので、経営陣は変更の必要性を感じていません。
コードレビューに「ピアレビュー」拡張機能を使用しながら、バグと今後のタスクを Trac で文書化し始めました。共同作業が簡単で、ナビゲートも簡単なため、チームからは大きな支持を得ています。他の数人のチームメンバーは、仕様、テスト手順、およびマニュアルとのコラボレーションを開始したいという要望を表明しているため、PDFにエクスポートされたDocBook/XMLでマニュアルなどの公開ドキュメントを探しています。 Trac WIKIページには、仕様やテスト手順などの内部ドキュメントがあります。
私の考えでは、ドキュメント形式を選択する際の最大の問題は次のとおりです。
- 作成は簡単ですか？
- メンテナンスは簡単ですか？
- 他の誰かが書いた場合、メンテナンスは簡単ですか？
- 手間をかけずに他の形式にエクスポート/変換できますか？
1〜3は私の人生を楽にし、狂ってしまうことなくドキュメントをすばやく作成するために重要です。 4つ目は、フォーマットが絶えず変更されるため、顧客側で最も重要だと思います。 Microsoft Word 2003形式が永久に存在するわけではなく、現在のPDFの実装もそうではありません。私は、OSやドキュメントの読者がどんなものであっても、すべてのお客様がドキュメントを読めるようにする必要があります。
テキストファイルの組み合わせを使用して、grepですばやく検索します。さらに詳細なドキュメント（Visio図など）のより整理されたコレクション用のSharePoint。
Google Apps（Enterprise）クライアントとして、GoogleはWikiの「フレーバー」であるGoogleサイトをそのまま使用します。使いやすく、管理者や開発者からの大きな採用がありました。
私たちは、SemanticMediaWikiを含むさまざまなプラグインでMediaWikiを使用しています。 SMWは、私たちのMediaWikiインストールを、自由に照会できる大きなフリーフォームのリレーショナルデータベースに変えるので、素晴らしいです。ウェブサイトがどのサーバー上にあるかを知る必要がありますか？そのページをご覧ください。サーバーでホストされているWebサイトを知る必要がありますか？クエリを実行すると、各Webサイトのページの適切なタグに基づいてページ名が選択されます。
職場で、Windows開発サーバーの1つにScrewTurn Wikiをドロップし、SQLサーバーに接続しました。それは本当にうまく機能し、実行が速く、主にドキュメント作成の邪魔になりません。導入から2週間で、すでに約60ページの情報が追加されており、これは私たちのチーム（〜10人）のみを対象としています。
これまでのところ、現在および過去のプロジェクトに関する情報を保持しており、ゼロからアプリケーションを構築する方法、URL、および開発者のチームにとって新しいその他の重要な情報など、アプリケーションに関する情報の追加を開始しています。
ウィキで私のお気に入りのページの1つは、ツールとライブラリのページです。そこでは、私たちがよく使用するお気に入りの生産性向上ツールやライブラリに関する情報を追加し始めました。その例として、Windowsでのテキスト検索用のgrepWinがあります。
利用可能なwikiの全範囲をチェックして、意図した使用法、機能、および展開環境に適したものを見つけることをお勧めします。使いやすいので、ScrewTurnを選択しました。ローカルのWinServerには無料の部屋がたくさんありましたが、YMMVでした。
Redmineをお試しください。大学のプロジェクトだけでなく、業界のプロジェクトにも使用しました。
Wiki、ドキュメント、メモ、svn（gitで作業していると思います）、機能リクエスト、高度なバグ追跡のサポートが含まれ、ガントチャートにすべてが自動的に追加されて、開発を監視します。
これは非常に優れたプラットフォームであり、さまざまなレベルのユーザー（開発者、オブザーバー、ユーザーなど）を追加して、たくさんの情報を全員で共有できます。
場合によっては、ドキュメントのwikiと共有ポイントとしてConfluenceを使用しています。この情報を非常に広く共有する必要がある場合や、ドキュメントが頻繁に編集および更新される場合に重要なのは、オンラインWiki形式の方が好ましいと私は考えています。だから私はナレッジベースの記事はウィキに置くほうがいいと思います。
現在、ネットワーク全体に広がるさまざまなドキュメントから2つの場所に情報を移動しています。
- イントラネットで利用できるwiki
- そのサーバーの/ rootディレクトリにある特定のサーバーに関連する情報のコピー。
ネットワーク図の場合、 ネットワークメモ帳 。
また、何を記録するときに、何かがそのように構成されている理由を記録することを忘れないでください。これは、良いアイデアのように思われるアイデアが間違いになるのを防ぐのに役立ちます。
MindTouch Deki （別名DekiWikiまたは "MindTouch"）は、いくつかの理由により、ここで選択します。
- 見た目も機能もすぐに使えるだけでなく、拡張機能、スクリプト、テンプレートを使用して簡単に拡張できます。
- wYSIWYGエディターを使用しているため、ユーザーは「ウィキテキストを学びたくない」ということを文書化しない言い訳として使用することはできません。
- すべてのデータはXMLで保存されます。つまり、すべてのページをXML Webサービスとして操作できます
- REST（標準のHTTP動詞）で操作される使いやすいAPI
- 素晴らしいスクリプト言語 DekiScript 、マッシュアップを簡単にする
- 絶対に美しい PDFを使用して出力 Prince 、CSSの作者によるHTML/CSSエンジン
どうやって使うの？完全なナレッジベースとして、各部門のセクションに分かれており、その下にページがあり、それに関する情報の保存が必要な場合があります。
ネットワーク監視システムについては、 Zenoss/MindTouch Deki mashup をダウンロードして、ZenossインストールからMindTouch wikiページにライブデータを配置し、構成メモやその他の将来のマッシュアップなどを確認できます。
オープンソース版は「コア」として販売されており、商用版のアドオン機能には、SugarCRMやSalesforceなどのサービス用のコネクターや、Microsoft SQL Serverなどのデータベースが含まれます。商用のお客様は、Windowsコネクタ（Outlook/Wordなど）やwikiを操作するためのデスクトップアプリケーションにもアクセスできます。
IISへのインストールは、MySQLをインストールしてからMSIをインストールするのと同じくらい簡単です。MSIは技術的にはエンタープライズ版専用ですが、オープンに使用するための 回避策 があります。ソースビルド：代替方法は、VMアプライアンスをインストールすることです（特に、既にVMwareサーバーインフラストラクチャがある場合）。この場合、構成はまったく必要ありません。
MediaWikiは遅い出発点であることがわかりましたが、ITの外部の人々がコメント、変更、編集などを簡単に追加するのがいかに簡単であるかを知ったら、それは不可欠になりました。開発者は、内部ドキュメント、施設部門にそれを使用しています。通知を投稿するためなど。それは単なるITドキュメンテーションツールではありません。
以前の雇用主では、フォルダーにまとめられたWord、Excel、Visioのファイルを使用していました。すべてのハードコピーが私の机のバインダーに保管されていました。 IT担当者は私だけだったので、他の誰かが情報にアクセスする必要はほとんどありませんでした。
私の現在の雇用主では、Exact SoftwareのMacola ESを使用していますが、組み込みのドキュメントエディターを使用するよりも、Wordでドキュメントを作成し、添付ファイルとしてMacolaにアップロードすることを好みます。
MediaWikiもここにあります。私が勤務している会計事務所の唯一のITサポートなので、現時点ではコラボレーションについて心配する必要はありません。それでも、定期的に行うような迅速な変更には、wikiが驚くほどうまく機能することがわかりました。
私が抱えている問題の1つは、機密情報（パスワードなど）はWikiの外部のより安全なストレージに保存されるということですが、すぐに利用できるようにしておくのは良いことです。