Stackoverflowメガマニュアルローンチ

Stackoverflowは、新しい野心的なプロジェクトの立ち上げを発表しました。これは、既存のすべてのテクノロジーのドキュメントハブです。 スタックに存在する各タグについて、ドキュメントセクションを作成し、このセクションに既存の質問と回答のパラダイムに似ているがドキュメントのセクションであるトピックを投稿できると想定されています。 Stackは、オープンソースコミュニティにとって、ドキュメントの標準プラットフォーム(たとえば、ソースコードのGithub)と同じになることが判明する場合があります。



Jeff、Kevin、およびサイトのその他の創設者の考えによれば、これにより、ユーザーは特定の技術の作者が頻繁に提供するよりも優れたドキュメントを自分で作成できます。 そうなると、プログラマーはStackウェブサイトを離れることができなくなり、日々の問題を解決するために多くの時間を費やすことになります。 ユーザー校正、投票、コード例、単一の検索、評判の動機-これらすべてが、より優れたより関連性の高いドキュメントを作成し、すべてのテクノロジーを一度に作成するのに役立つことを期待しています。



著者は特にコード例に依存しています。 確かに、スタック上のコードの有用な例の数は、あらゆる技術に関する公式文書を上回っています。 これは、例を書くのが非常に難しく、それぞれが多くの思慮と時間を必要とするという事実によるものです。 Stackにできるだけ多くの例を書くと、何千人ものユーザーしか作成できず、この中の優れたドキュメント作成チームでさえ、きちんと組織された群衆と競争することはできません。



多くの場合、製品がリリースされるとドキュメントが公開され、有用なコード例の数は、少なくとも製品の次のバージョンまで、開発者がドキュメントを更新するまで変更されません。 スタックは論理的に、絶えず更新されるドキュメントが開発者の生活を改善できることを示唆しています。



創設者はまた、ほとんどのプロジェクトで使用されているドキュメント形式は時代遅れである、つまりユーザーインターフェイス自体が古いと主張しています。 プログラミング言語、ライブラリ、およびAPIのほとんどのドキュメントシステムは、20年前にJavadocのアイデアを継承します。 このようなシステムのリンクは通常ローカルであり、バージョンによって失われます。 スタッカーは、両方の問題を解決し、永遠のグローバルリンクと、質問と回答のメインサイトのインターフェイスから継承され、何百万人ものユーザーによってロールインされる最新のユーザーインターフェイスを作成することを約束します。 彼らは、彼らのyuy / yuiksが世界で最高になると脅されています。



実際、スタック内の人々は非常に実用的であり、まったく異なる順序を考慮しています。 Stack問題のユーザーと所有者を絶えず苦しめることは、あまりにも広範でトピックから外れています。 コメントでは、人々は「一般的に」質問をしたいので、長年にわたって戦いが続いています。例えば、「あなたは何を読むことをお勧めしますか」。 別個のプログラマーハブが作成されましたが、特に人気があるわけではなく、「トピック外」および「tブロード」の流れは弱まりません。 そのため、これらの問題のほとんどは、それらと戦うのではなくドキュメントに組み込まれ、ネットワークの有用な部分になるという希望があります。



Stackoverflowの記事自体は、Stack自体のドキュメントにリンクできるようになりました。 これにより、リンクの破損という非常に深刻な問題が解決されます。 ドキュメントへのリンクには膨大な数の質問と回答が含まれており、公式のドキュメントは常にコンテンツを変更したり、リンクを介して移行したりするため、「ビート」の割合は時代遅れになります。



統計によると、一般的に、スタックに関する多くの質問は、公式のドキュメントに特定のトピックに関する情報がないか、質が低いという事実によってのみ発生します。 さらに、そのような質問は何十回も何百回も尋ねられる可能性があり、モデレーターとコミュニティ全体の時間とリソースを費やして何度も削除する必要があります。 そのような場合、コミュニティがドックに適切な記事を作成して対応し、これらの複製のフローが減少し、コミュニティの創造力がより有用なものに解放されることが期待されます。



結果として改善される可能性のある別の重要な問題は、利益を得る能力です。 現在、Stackを使用している多くの人は、他の人にとって有用な何かを書きたいと思っています。 これはスタック上にあり、評判を追求するために、人々は最高速度で応答するために急いでいます。多くの場合、さまざまなトリックを使用して答えを先頭に置きます。 これで、膨大な数のトピックに関するドキュメント用のトピックをゆっくり作成し、ところで、評判に投票することが可能になります。



創立者はまだこの努力の成功を確信していません、多くの野心的なプロジェクトはこの世界で失敗します。 そのため、プライベートベータのみが開いている間、それらはゆっくりと起動します。プライベートベータには、フォーム、検索、ディスプレイなど、すべてのテクノロジが組み込まれています。



これまでの考え方は次のとおりです。Stackoverflowの既存のタグからタグが取得され、そのためのページが作成されます。正式名称は「トピック」です。 各トピックには、タイトル、例、メモ、およびオプションのセクションがあり、任意の数にすることができます。 もちろん、主な重点は例です。 これはトピックを説明する明確で説明的な例であるため、これは開発者がドキュメントで探しているものです(ほとんどの場合、したがってStackの人気は見つかりません)。



例は、「折りたたみ」(折りたたみ)にすることができます。グローバルリンクは、トピック全体だけでなく、別の例にもつながる可能性があります。 アンケート回答者のエディターに似ていますが、一般的にエディターは新しくなります。 MacDown、バックライト、大きな窓。 ところで、トピックに加えて、リクエスト(リクエスト)を作成したり、それらに投票したり、訪問者にトピックを書いてもらいたいトップリクエストを作成したりすることができます。 これらすべてが具体的に評判にどのように影響するかはまだ明らかではありません。 ただし、サイトの質問部分の評判とドックの評判は一般的です。



もちろん、動機には混乱があります。 一方で、創設者は「すべてを支配するための1つのリング(ドキュメント)」の精神でフレーズを急いでいますが、一方では、優れた既存のドキュメントと競合する必要はなく、高品質のドキュメントがない場合にのみ機能すると言います。 これはすべて人々に多くの質問を引き起こします。



別の質問が発生します。質問と問題を今すぐ新しいトピックリクエストまたは古いアンケートに投稿する場所はどこですか。 これはかなりの混乱を引き起こす可能性があります。たとえば、「Javaで2行を折りたたむ方法」は、質問と回答の中でこれですか、それともドック内の新しい記事のリクエストですか? このトピックに関するガイド(ルール)はプッシュされていますが、まだ明確ではありません。



既存のドキュメントから記事をインポートすることは禁止されています。 ライセンスポリシーがありますが、この記事は入門なので、ここでは説明しません。



幅広い議論が展開されており、幅広い反響を受けた多くの質問をします。



彼らは尋ねます:プロジェクトに良いドキュメントがある場合、スタック上でこのプロジェクトのドックを作成する必要はありませんが、ドックがスタック上に作成され、プロジェクトに独自のドキュメンテーションがある場合はどうでしょうか? この場合、スタックのドキュメントは消去されますか?



質問はややこしいですが、ケビンは論理的に説明しました。彼らが言うには、投票システムを作成し、コミュニティに消去するものと残すものを決定させます。



別の質問は、多くのバージョンがあり、それぞれ独自の大きなドキュメントがある.NETのようなシステムで何をするかです。 答えは、技術バージョンも特別な手段で考慮されるということです! これまでのところ、それがどのようになるかについての詳細な情報はありません。



プラスの最大の束は、3つのスクリーンショットのコミックを投稿した人のコメント(技術的にはこれが答えです)によって受け取られました。ファイルへの書き込みの人気のある例がすぐにスローされ、Node.jsの公式ドキュメントの3ページ目では、このリソースでサポートされている関数の典型的なリストがあり、次に何を読むべきかは完全に不明です。 つまり、人々は例を探しています。 ただし、これだけでは新しいサイトの必要性は証明されません。



人々は、公式文書とStack上の文書が混同されることを非常に心配しています。 「最強の生き残り」だと信じる人もいれば、公式文書は筋金入りの労働者とスタック用のドックを書く人だけのものであり、ほとんどが後者を使用するだろうと考えている人もいます。創業者自身は公式ドックを公式に移行するのが最善であると考えていますスタックプラットフォーム! 統一されたグローバルな実行ユーザーインターフェイスと巨大な公開校正と編集機能を備えていると、テクノロジークリエーターにとって便利なはずです。 オープンソースプロジェクトの作成者は、おそらくこの機会を最初に利用するでしょう。



1つのリソースにすべてのドキュメントを集中すると、スタックがEvil Corporationになる可能性があると心配する人もいます。 しかし、他の人は、本質的にスタックは単なるホスティングであり、スタック上のすべての力は社会と投票メカニズムに属し、これがどのように悪であるかは不明です。



多くの人々は、ドキュメンテーションは過度に広い概念であると考えており、Stackが単に例に集中していることを示唆しています。 また、まれな例ではテキストの伴奏がまったくないため、深刻な問題が発生します。 さらに、この例は新しいプロジェクトのキラー機能ですが、トピック外や大規模なリンク、壊れたリンク、今はできない人を説明する機能、その他の完全に実用的な機能もあります。



また、チュートリアルとオーのサイトを作成することも推奨しています。



また、ドキュメント、特に公式ドキュメントは究極の真実として認識されるべきであり、スタック上では議論の主題になり、特に開発者が1つのことを書いて、現実が異なっていて、書くとき、それが現実に対応するという保証があるのではないかと心配していますたとえば、コンパイラにわき柱があることがわかっている場合でも、ドキュメントでコードを使用することをお勧めします。 それに対して人々は神聖主義で対応し、間違い、混乱、非実例などのない公式文書がほとんどないことを正しく指摘します。 ある人は、そのようなことを言ってプロをつかみました。ドキュメントが聖書のようなものである場合、CDからMSDNをインストールできます。



多くの開発者がサイト内を巡回しているというコメント(「戦争と平和」を書いているタイプライターの悪名高い想像上のサルを思い出した)は、高品質のドキュメントを作成することはありません。 、実行し、タスクの複雑さと責任を認識します。 とりわけ、ドキュメントはプログラミングスタイルと問題解決パターンのソースであり、問​​題を解決する方法を示すだけでなく、技術開発者の観点から提起された問題の解決方法を説明するようなドックを作成することは、この技術の開発者と緊密に連携するプロのドキュメントにすぎません。 この質問に対する一般的な回答はありませんでしたが、何千人ものプログラマーがこのテクノロジーを使用し、それに関連するあらゆる種類の問題を解決すると、このテクノロジーの他のユーザーが必要とするのと同じようにドックを作成することを示しました。開発者の本当に必要と密接に連絡しているプロの作家。 おそらく、この問題はプロのドグラグラファー自身にとってより心配なことです。なぜなら、彼らはたくさんあり、彼らはお金を得るからです。 ところで、彼らの仕事は消えないかもしれません、彼らは単に「スタックに座っている」ために支払われます。



1人の人は、スタックで絶えず殺されているトピック以外のトピックの例に非常に満足していますが、「誰もが知っておくべき」であり、サイトで場所を見つける必要がある人、そして、存在しないかもしれない多くの質問につながる人、 「scanfを使用しない」、「型ベースのエイリアシングルールは非対称です」(翻訳が難しい)、「シェルスクリプトでこの問題を解決しようとしているのは無駄です」という基本的なことを知っています。



オープンソースプロジェクトのドックを書いた人々は、「そこにあるいくつかのフォーラムやウィキ」よりもはるかに優れた公式ドックを書くという精神で話しました。例えば、オープンソースプロジェクトの作者は質問の明確化。 しかし、どういうわけかそれは私を本当に納得させません。



英語の公式ディスカッションスレッドはMetaにあります。誰でも参加できます: meta.stackoverflow.com/questions/303865/warlords-of-documentation-a-proposed-expansion-of-stack-overflow?cb=1



これが状況です。開発を待っています。 私にとっては、良いか悪いかはまだ決めていませんが、確かに言えることの1つは、それがどうなるか非常に興味があります。 英語圏のコミュニティの意見をロシア語圏の人たちの意見と比較するのは面白いでしょう。恥ずかしがらずにコメントを残してください! それでも、結論として、読者の皆さん、あなたは小さな調査に招待されています:



All Articles