下記に示した例のように、そこでの使用法があります。
それが良い考えかどうかはわかりません。結局のところ、私たちユーザーはバグを修正することはできません。それはDiscourseのコードを変更することによってのみ可能であり、それにはチームメンバーの関与が必要です。それが不要な場合、バグはおそらく適切なカテゴリではありません。
ユーザーが回避策を解決策としてマークすることを心配しています。しかし、その場合でもバグは修正されません。したがって、それは役立つよりも混乱を招くでしょう。あなたの例では、すでにバグレポートがあるので、問題は解決されていません。この場合、トピックをマージするのが最善だと思います。そうすれば、ユーザーは最初にフォローしていたトピックに関係なく、修正があったときに通知されます。場合によっては、一方のトピックをもう一方への参照で閉じるのが理にかなっていますが、その場合、閉じられたトピックをサポートしていた「いいね」が失われます。これは、影響を受けるユーザーが「いいね」によって決定される場合には残念です。
Bug カテゴリでは、fixed タグのみを使用します。重複しているという投稿は、役に立つにもかかわらず、何も解決しないため、そこでも良い使い方はできなかったと思います。
なぜ一部のカテゴリでは fixed を使用し、他のカテゴリでは solved-plugin を使用するのかというと、おそらく Moin がすでに述べたことによるものだと思います。タグは使用において少し厳格であるため、修正されたと判断できるのはチームのみです。
ご提案ありがとうございます!カテゴリの設定方法を常に確認することは良いことです。ご検討いただき、このトピックを開始していただき感謝いたします。
MoinさんとCharlieさんが指摘されたように、私たちのチームは、バグが修正されたことをコミュニティに伝えるために、#fixedとトピックのクローズ(私たちにしかできない操作)に依存しています。これはかなりうまく機能しており、修正が必要なバグの明白なバックログを維持する方法となっています。
バグカテゴリでは、解決済みのプラグインが有効になっているカテゴリのように、解決策を提供できる人がそれに対してクレジットを得られないのは残念なことです。バグカテゴリでは、バグを報告した人は、Discourseチームのメンバーによって好かれた場合にバッジを獲得できます。しかし、再現手順の提供、重複の指摘、解決策の提案などで協力した他の人はクレジットを得られません。これは検討すべき点です。
この場合、Moinさんがレポートが重複していることを指摘したことに対してクレジットを付与できればよかったのですが、トピックを維持することは、チームがすべてのオープンなバグレポートを解析するのを少し難しくする余分なノイズも生み出します。そのため、削除のタイマーを設定しましたので、ご容赦ください。
トピックを残しておくと、オープンなバグレポートの解析が少しトリッキーになる余計なノイズも発生します。そのため、気にしないでいただけると幸いですが、削除するためのタイマーを設定しました。
@tobiaseigen、ロック機能はそのためにあるのではないでしょうか?削除すると、それにリンクしている外部URIの一部が404エラーになり、理想的ではありません。
すべてを保存しているわけではありません!
404についてはあまり心配しないでください。
私たちは単に fixed タグを使用しています。
しかし、これは余分な作業なので、全く一貫して実践していません。修正してクローズする際に自動タグ付けするメリットがあると思いますが、修正しない例外的なケースでは特別なタグで編集できます。
ただし、新しい自動化が必要になります。
それを削除すると、それにリンクしている外部URIが404エラーになるため、理想的ではありません。
情報を見つけようと何度も試みたのに、興味深いリンクをクリックしたら404エラーになり、非常に不快な思いをしたことがあります。
この場合、投稿をフラグ付けし、モデレーターが編集または削除します。
これを防ぐには、トピックを削除する前に、最初の投稿のリンクセクションを確認します。
そして、それらのリンク参照を削除することで予防的に対応するのが最善ですが、それにはより多くの作業が必要になります。
固定タグで自動タグ付けすることにメリットがあると思います。クローズ時に、修正しない例外的なケースは特別なタグで編集できます。
私は@tobiaseigenに逆に提案しました。fixedタグを追加する際に、解決済みと同様に自動的にクローズするようにします。
はい、そして?トピックを閉じたり(または閉じる予定を立てたり)する際に、それが閉じられた場合にすぐに#fixedタグを追加する自動化はどうでしょうか。同様に、#uxで#fixedおよび#completedタグを使用することもできます。
#bugトピックを#fixedタグを追加せずに閉じる場合がありますか?タグが付いていない閉じられたバグトピックがたくさんあるようです。今日は少し時間をかけて調査します。
私がsolvedプラグインの動作で気に入った点は、解決策が選択されると、最後の返信から30日後にトピックが自動的に閉じられるようにスケジュールされることです。これは突然ですが、それでも必要だと感じる人がフォローアップできるようにするため、便利です。また、人々が再オープンを求めるためにフラグを立てる必要がなくなるため、作業を節約できる可能性もあります。
クローズされた場合にすぐに#fixed::タグを追加し、#fixed::タグが付いている場合にトピックをクローズ(またはクローズをスケジュール)する自動化はありますか?
クローズされたら自動的にタグを追加するという方法が好ましくない理由は、修正されなかった場合や、今後も修正されない(wont-ever-fix)というユースケースがあるためです。タグを追加するという1つのアクションを実行し、その後30日後にトピックが自動的にクローズされるように設定するのが最適だと考えます。
この件について少し時間をかけて確認したところ、@chapoiさんの考えが正しいことがわかりました。ここでは、修正されたアイテムに#fixedタグを付ける習慣を身につけ、その後、solvedプラグインのように自動的にクローズするタイマーを設定する自動化を作成するのが良いと思います。必要であればトピックをすぐにクローズすることもできますが、場合によっては、人々がテストして問題がまだ発生しているかどうかを報告する機会を与えるために、しばらくの間そのままにしておくのが良いと考えています。
例えば、Rendering 'TypeError' with theme components after update のようなトピックは、OPで報告されたバグが修正されていないため、#fixedタグを付けるべきではないと思います。この例では、修正を試みたエンジニアからの再現はありませんでした。
また、After deleting a topic, the delete button shows up instead of the restore button のように、重複としてクローズされたトピックもあります。Deleting a topic cannot be undone が修正されたら、両方に#fixedタグを付けてクローズできると思いますか?しかし、それを確実に実行するにはどうすればよいでしょうか?
Bug の中には、クローズされているものの fixed タグが付いていないトピックがたくさんあります。これらを遡って確認する必要があります。
ここのユーザビリティが問題です。エンジニアにはワンクリックで解決できる方法を提供したいです。
- トピックアクションまたは管理トピックアクションで「修正済み」をクリックします。
- マジックが発生します:
- 1営業日後に閉じるトピックタイマーが作成されます。
- 「修正済み」タグが付けられます。
「トピックにタグを付ける」だけのUXは、非常に手間がかかるため、あまり好きではありません。
- トピックの先頭に移動します。
- タイトルをクリックします。
- タグボックスをクリックします。
- 「修正済み」を検索します。
- 「修正済み」を追加します。
- チェックボックスをクリックします。
これは非常に手間がかかります。
このフローを追加できるのは嬉しいですが、テーマコンポーネントまたはこのUI(これも便利です)を導入する何らかの自動化が必要になります。
おっしゃる通りです!私も「yes, and」を提案した際にユーザビリティについて考えていました。現在、Bug トピックは修正されたら閉じるという習慣が身についています。これは、内部的に TODO を処理する方法とも一致しています。
「修正済み」ボタンをワンクリックで操作できるというアイデアは気に入っています。
エンジニアには、ここにワンクリックで解決できる方法が欲しいです。
そしてコミュニティがそれを実現しました ![]()
Summary Add tags to a topic with a click of a button
Repository GitHub - NateDhaliwal/quick-add-tags
Install Guide How to install a theme or theme component
New to Discourse Themes? Beginner’s guide to using Discourse Themes Install this theme component This is a component that adds tags to a topic with a button in the topic footer. It also provides the option to auto-close the topic after x days (minimum 0). …
素晴らしい!個人のサイトでNateさんのテーマコンポーネントを試してみましたが、期待通りの動作をしました。非常に良い出来で、実装も早かったです!![]()
ここで使用するには、カテゴリに制限できる必要があります。このアプローチがうまくいくと判断した場合、複数のボタンを作成できるようにしたいとも考えています。
FYI、Samも自動化を使用した、異なる、より柔軟な実験的な実装に取り組んでいます。
メタではこの変更がかなり役立つと思います。サムの実験的な実装を自動化で使用するか、ネイトのテーマコンポーネントをフォークしてここで使用するかどうか、内部でフォローアップしました。
ネイトのコンポーネントは実質的に同じことを行っており、非常に優れていますが、メタにはサードパーティのコンポーネントやプラグインをインストールしないため、フォークする必要があります。![]()
Nateのコンポーネントは実質的に同じことを行い、非常に優れていますが、metaにサードパーティのコンポーネントやプラグインをインストールしないため、フォークする必要があります。
もしそうするのであれば、HackerOne経由で特定されたサイバーセキュリティリスクに対して行うように、Nateに感謝の金銭的報酬を提供することが、誠実な対応となるでしょう。
このトピックは、コミュニティがNateのテーマコンポーネントのようなものを使用することから恩恵を受けるかどうか、に焦点を当てましょう。もしそうであれば、Nateと協力して仕組みを整理します。
もしよろしければ、オープンソースの貢献者が一般的にどのようにその仕事に対して報酬を得るかについて、別のトピックを立ち上げることもできます。
