🖋️: トラブルシュートに情報が溜まっていくような仕組みが必要なのでは？

[tani-takanori]

StackOverFlowのようにQとAが溜まっていくような仕組みがあったほうがトラブルシュートに情報が集まるのでは？

[tani-takanori]

トラブルシュートはStackOverFlowを目指しているわけではない。

[tani-takanori]

StackOverFlowなどのQAサイトをサルベージして利用頻度、参照頻度が高いものをガイドしてもいいかもしれない

[in-a-paddy]

StackOverFlowなどのQAサイトをサルベージして利用頻度、参照頻度が高いものをガイドしてもいいかもしれない

「トラブルシュート」のページを用意するのではなく、自分たちのところに来た質問などからよくハマりがちな罠を具体的に検知して、それらをまとめたページとする方が良いのでは、と思います。なお現時点での対応は、「トラブルシュート」というページ名を変更するのみで充分と考えています。

トラブルシュートは各々がトラブルに陥った時に、React NativeとExpoの公式サイトやIssue、ソースコードを自分たちで確認してもらうのが良いかと。コンテンツはトラブルを起こさずに進めやすくするためのものと考えているので、そもそも「トラブルシュート」という考え方があまり相応しくなかったのかな、とも思いました。

このIdeaからは少し話題がそれますが、トラブルシュートの際に誤った情報にたどり着きがちなのでそれをどうやって回避するかは検討したほうが良いと思います。特に、環境構築周りで犠牲者が目立ちます。

[in-a-paddy]

QAをDiscussionでためておくのはどうだろうかと思い、いくつか転記してみました。
でも、これを突き詰めていくとみんなにStack Overflow（or 社内の情報共有システム）で質問してもらえばいいという話になりそうな気がしてきました。

• 🤔: サンプルとしてFirebaseを使っている理由が知りたいです #111
• 🤔: 「プッシュ通知をしたいかどうか」は、ネイティブアプリ採用の根拠になりますか？ #112
• 🤔: sdkmanagerでライセンスに同意しようとするとNoClassDefFoundErrorが発生する #121

[tani-takanori]

#237

[creature-water-valley]

• ✨ : トラブルシュートではなく落とし穴に変更 #237 で「ハマりがちな落とし穴」に変更
• 📝: キャッシュに関するトラブルシュート作成 #1266 で「トラブルシューティング」に変更
  • トラブルシューティング関連のコンテンツしか追加されなかったため
  • 「ハマりがちな落とし穴」だと英語表記がわかりづらく、そのページを表示する人が少ないそうと思ったため