Discourseのドキュメントを改善する

これがまさにDiscourseのドキュメントの問題点です。

トピックを探し回ることが「許容できる」人もいるかもしれませんが、それはドキュメントではありません。ユーザー、さらに悪いことには管理者/モデレーターが情報を探し回る必要があるということです。

「いいね!」 1

いいえ、そうではありません。そして、それがDiscourseの最大の欠点であり、依然として欠点です。私が今失礼すぎるのかどうかはわかりませんが、ここの傾向は開発者中心すぎます。知らない場合は、GitHubでソースを読むことができます。CDCKは、ユーザー(もちろん管理者も含む)向けの優れたドキュメントの構築にあまり意欲がありません。なぜなら、彼らのターゲットは大手企業だからです。そのため、彼らにとっては最低限のレベルと、フリーライダー(バグハンターやUX提案の大部分を行っている人々 ;))のコミュニティの助けで十分でした。タグをもっと自由に使えるようになれば別ですが…

十分だったは、単なるタイプミスや低い英語力ではありませんでした。CDCK/チームは、より良いドキュメントの構築を開始しました。そして、しばらくすると、このようなサイドトピックは過去の残響になるだろうと確信しています。

「いいね!」 4

開発者/ユーザーコミュニティとして、Discourseは平均をはるかに上回っています。エラーは迅速に修正されるようで、機能リクエストは無視されるだけでなく、特に合理的なユースケースがある場合は、さらに対応されます。また、オンラインスタッフ(有給かボランティアか、どちらか区別がつきませんが)は、私たち新参者に辛抱強く指導してくれるので、かなり良いです。

確かに、ドキュメントには改善の余地がありますが、良いドキュメントを書くのは費用と時間がかかります。さらに、開発者は、ユーザーが見るように製品を見ていないため、良いドキュメントを書けないことがよくあります。コードに近すぎることも製品テストの問題ですが、多くのオープンソースプロジェクトでは、ユーザーコミュニティがテストをうまく行っています。

「いいね!」 5

確かにそうです。良いコードを書くのも同様です。質の高い人間の仕事は、しばしば高価です。しかし、コードとドキュメントは結びついており、誰もそれをやらない場合にのみドキュメント作成が高価になります。そうでなければ、コーディング、テスト、デザイン、UX/UIなどと同様に、製品の重要な部分です。しかし、開発者はしばしばドキュメントを嫌います。なぜなら、彼らはそれをやりたくないだけで、セクシーなところは何もなく、さらに彼らはしばしばそれに非常に悪いからです :wink: しかし、会社のオーナーや他の監督者は、同様の開発者であるため、人々がやることとやらないことを取捨選択していることなど気にしません。

しかし、今私はトピックから外れすぎている一般的なことまで話しています。そこで、今進化している#documentationに言及して、私は去ります。

「いいね!」 1

私もこれには完全に同意します。私は20年以上の経験を持つ開発者であり、近年はプラットフォームエンジニアリングに転向しました。

これは、提案を求めたときに、開発者(推測ですが、タイトルからディスコース自体の一部であることがわかります)が来て、彼らがそう決定したからそうではなく、今後もそうならないと教えてくれるときによくわかります。

ここからは脱線します。

私はすでにこれを言いました。技術スタックで意見を主張することと、製品で意見を主張することの間には違いがあります。製品は、合理的な範囲内で、ユーザーのユースケースに対応すべきであり、「私のボールであり、他の人が気に入らなければ他の場所に行けばよい」というものであってはなりません。

すでに5つの新しいプロジェクトを開始しましたが、幸いなことに、私たちのコミュニティにはRubyについて少し知っている人がいて、今後数日間でディスコースのフローの基本を説明してくれるので、必要な機能を提供するプラグインの作成を開始できます。特に、カテゴリモデレーターをジョークにしないことです。

Users are receiving emails even when everything is set up to not send email notifications のサポートトピックが少し進化していたので、それぞれが息抜きできるスペースを与えるために、他のカテゴリにいくつか新しいトピックを分割しました。:+1:

「いいね!」 2

製品のユーザーにとって生活を楽にするようなことではなく、自分たちが興味のあることに取り組む傾向のあるオープンソースプロジェクトを一つ思いつきます。ユースケースは常に視点の問題であり、製品のユーザーは開発者とは異なるユースケースの見方をしています。開発者は、ユーザーが行うことを「単なるデータ」と見なしがちで、わずかな変更が使いやすさに大きな違いをもたらすことに気づかないことがよくあります。(私もシステム開発にはかなりの時間を費やしてきましたし、そのような態度をとったこともあったはずです。)

今のところ、Discourseの開発でそのような態度を見たとは言えませんが、まだ1ヶ月しか経っていません。

製品に近すぎるということについてですが、現在、Ruby開発に関する本の演習を行っています。昨日、単純な「hello world」アプリを動作させるのに3時間かかりました。これは、その本が私がまだ持っていなかったAWS IDE(cloud9)環境に精通していることを前提としていたため、ほとんどが、私が10分かけて入力した変更を元に戻してしまうようなことをクリックしていたからです。

そして、動作中のアプリのプレビューをブラウザに表示させる際に問題が発生しました。これは、本が最後に更新されてからFirefoxとChromeがブラウザに設けたセキュリティ制限によるものと思われます。1時間ほどウェブで解決策を検索した後、ラップトップとデスクトップのIPアドレスをホワイトリストに登録することでうまくいきましたが、プレビューを表示させるためにはまだ追加の手順を踏む必要があります。

「いいね!」 1