これは存在しますか：ファイルシステム構造を文書化する標準化された方法

仕事では、標準のファイルシステムでさまざまなデータをまとめて整理する責任があります。これの一部は、（類似性、必要性、読み取り/書き込みアクセスなどによる）賢明な分類を考え出しますが、より大きな部分は実際にそれを文書化することです。 「少し異なるものについては、.. / .. / other-dirを参照してください」など

現時点では、文書化readmeするすべてのディレクトリにプレーンテキストファイルを使用してこれを文書化しています。誰かがどのディレクトリにあるのかわからない場合は、そのファイルを読み取ります。

これは問題なく動作しますが、重要なディレクトリ構造の管理者が経験しなければならない問題に対して、この原始的なカスタムソリューションがあるのは奇妙に思えます。たとえば、私が知っているすべての会社には、分類のために合意された用語が重要な、ある種の共有ファイルシステムがあります。私の経験では、人々は試行錯誤と実験によって何が何であるかを学ばなければなりません。

ですから、より良い解決策を提案させてください。うまくいけば、それが存在するかどうかを教えてください。任意のファイルシステム上の任意のディレクトリに、という名前の非表示のプレーンテキストファイルを含めることができます.readme。その内容は説明的な人間の言語です。Markdownのようないくつかのマークアップを使用し、他のディレクトリへの太字、斜体、および（相対）ハイパーリンクにすぎません。これで、適切に有効化されたファイルブラウザは.readme、ディレクトリを表示するたびに名前が付けられたファイルをチェックします。存在する場合は、その内容が解析され、ディレクトリパスウィジェットの近くの目立たないペインに表示されます。その中のリンクをクリックすると、ユーザーはそのリンクのターゲットディレクトリに移動します。

そのような標準を実装する努力は、ユーザビリティの向上に何倍もの利益をもたらすと思います。たとえば、Nautilus、Konquerorなどのプラグインがあります。これは、Webサーバーによって提供される標準ファイルリストのディレクトリ情報を表示するために使用できます。等々。

だから、質問：そのようなものは存在しますか？そうでない場合、なぜでしょうか？人々はそれが価値のあるアイデアだと思いますか？

私の知る限り、基準はありません。ここに私の経験からいくつかのアイデアがあります。

設定してください、決して変更しないでください

これはほとんどの企業が失敗したものです。絶えず変化するファイルシステム構造ほど悪いものはありません。一定に保つことができない場合、純粋なファイルシステムは情報を整理するための間違ったコンテナです。データベースまたはコンテンツ管理システムを使用します。

説明的で一貫したディレクトリ名を使用する

.filingファイルなどを読む時間は誰にもありません。ディレクトリ名が自己説明的でない場合、おそらくとにかく失われます。

ディレクトリ構造のドキュメントを書く

すべてのディレクトリの役割を説明するドキュメントを作成します。たくさんの例を挙げてください。あなたの構造で作業する必要があるすべての人が利用できるようにしてください。それはあなたにとってより聖書のようであるべきです。そのようなドキュメントの例を見つけるのは簡単ではありません。企業がそれらを公開していないからです。オープンソースソフトウェアの例は、ファイルシステム階層標準です。

これが少しネガティブに聞こえるなら、そうです。5人を超えるユーザーが実際に長期的に作業しているファイルシステムに基づく重要なリポジトリを見たことがありません。問題は、設定するカテゴリが何であれ、人々はそれらについてまったく異なる考えを持つことです。最終的にあなたの質問に答えるために：

そのようなものは存在しますか？

いいえ、そうは思いません。

そうでない場合、なぜでしょうか？

私の意見では、数人のユーザーがいる小さな静的階層では、やりすぎです。多数のユーザーがいる大きな変化する階層の場合、カテゴリ（=ディレクトリ、フォルダ）の概念が拡張されないため、機能しません。

人々はそれが価値のあるアイデアだと思いますか？

うーん、面白いアイデアですね。人々がそれを使用するかどうかを確認するには、誰かがそれを実装する必要があります。.filingファイルの代わりに、その情報を別のデータストリームに格納できます（そうです、フォルダにもADSを含めることができます）。LinuxおよびOSXで拡張属性を使用できます。最大の問題は、おそらくファイルブラウザにパッチを当てることです。

わさびは一見の価値があります。プロジェクトのルートでは、プレーンテキストのソースが確実なプロジェクトの概要として機能し、同じドキュメントをブラウザーにスローして、より洗練された結果を得ることができます。

確かに、これはファイルシステムベースのソリューションではありませんが、周りのすべてのファイルシステムが一般的なものをサポートするまでは、わさび（またはそれを独自に実装したもの）が最善の選択肢になる可能性があります。

あなたのアイデアにはいくつかのメリットがありますが、私は、このようなものが必要なときに、より構造化されたものが必要であることを本当に恐れています。つまり、CMSは、おそらく軽量なものですが、テキストファイルだけではありません。

特に、特定のドキュメント（およびそのドキュメントを含むフォルダー）の書き込み（またはアクセス）をユーザーベースのサブセットに制限したい場合。

OSを指定することはありませんが、現在の設定よりも優れたサービスを提供できるalfrescoなどの優れた（そして無料の）製品があります。

ここにアイデアがあります。ファイルに関するさまざまな質問をユーザーに尋ねるスクリプトを記述し、ファイルの内容自体でいくつかのマッチングを実行し、ファイルを配置する場所またはファイル自体を配置することを推奨します。スクリプトは、必要に応じて単純にすることも複雑にすることもできます。

スクリプトは、ファイル管理システム、意思決定支援システム、およびファイルシステム階層の最新のドキュメントとして機能します。Linux Filesystem Hierarchy Standardは、ディストリビューション間で非常に大きな差異があるため、考えれば少し神話です。ただし、システムにインストールされているさまざまなソフトウェアが標準化された方法で階層を管理するために存在するため（パッケージマネージャ、構成ツールなど）、ほとんどのLinux / Unixユーザーは実際にファイルシステム階層について学ぶ必要はありません。さまざまなアプリケーションフレームワークは、ディレクトリを管理するためのスクリプトも作成します。たとえば、djangoには、新しいプロジェクト、新しいアプリモジュール、スカッシュマイグレーションファイルなどを作成するための管理コマンドがあります。

これには、ファイルを複数の方法で検索する必要がある場合にスクリプトがさまざまなシンボリックリンクを作成できるという追加の利点があります。たとえば、ファイルの作成者や作成日、またはビジネスルールに基づくインデックスなどです。シンボリックリンクでタグ付けをシミュレートできます。タグはtagsディレクトリからのシンボリックリンクなのでtags/mytag/myfile、へのシンボリックリンクになる場合がありますactual/myfile。

さらに、ユーザーインターフェイスを変更せずにファイルシステムの階層構造を変更することもできます。

ファイルシステムはデータベースです。リレーショナルデータベースではなく、階層型データベース。それをデータベースの管理のように考えてください。実際に関係構造を学習する必要があるのではなく、アプリケーションがユーザーに必要なさまざまなタスクとしてユーザーに提示することを望んでいます（たとえば、毎月XYZレポート、すばらしいです。それをこのフォルダーに入れて、このシンボリックリンクを作成します。次に、今月のレポートを行ったことを記録するために、別のファイルを変更する必要があります。