たとえ悪い場合でも、オープンソースプロジェクトのドキュメントパターンに従う必要がありますか？
いろいろな言語やその他のオープンソースのもののためにモジュールなどを作ることを考えました。ドキュメントが指定されていないが、共同のデファクトスタンダードまたは完全にアドホックである場合。信頼できるソースからの優れたドキュメントであると私が学んだことと一致しない場合は、コードでその標準から改善しようとする必要があります（コード完了et al）？
それとも、品質に関係なく、すべてにわたって一貫性を維持する必要がありますか？
プロジェクトの一貫性は、ソースコード自体とドキュメントの両方にとって非常に重要です。 プロジェクトに携わる人々は、長年使用していた標準を使用することに慣れています、および失われるコードの一部またはドキュメントの一部の前で、あなたの意見では、より良いですが、それは残りのコードベースやドキュメントとは何の関係もありません。
また、あなたが何かが悪いと思っているからではなく、それが悪いことを意味していることに注意してください。 Code completeを参照しても、何も変わりません。あなたが批判するかもしれないことは、プロジェクトに関連するいくつかの要素にその源があるかもしれません、そしてコードコンプリートはそれが悪いと言っていますが、何年もプロジェクトに取り組んだ人は誰でもこの特定のケースではそれが唯一の選択であることに同意するでしょう。
既存のオープンソースプロジェクトのドキュメントを改善したい場合は、このプロジェクトに参加している他の人からフィードバックを集めてください。実際のドキュメントが悪すぎることに全員が同意している場合は、書き直してください。ゼロから、ベストプラクティスに従い、同時に一貫性を維持します。
一貫性を維持することはおそらく最初に行う方が良いでしょうが、私はプロジェクトの所有者に連絡して、彼らのドキュメントの改善を提案できるかどうか尋ねます。彼らが同意する場合は、あなたの提案を正当化し、例を提供してください。
「悪い」は見る人の目にあります。あなたの「悪い」は彼らの「美しい」かもしれません。あなたが重要な貢献者になるまで、そしてそうでない限り、あなたは確立されたスタイルに従うべきです。