Document and publicize clear Multi-Channel Support Model

[BigLep]

Done Criteria

A user of filecoin.cloud finds clear directions on the various avenues to get help:

• Real-time help (chat)
  • Slack (e.g., #fil-foc, or a dedicated #fil-foc-help).
  • For “I’m stuck right now” troubleshooting, faster back-and-forth.
• Bug reporting / persistent issues
  • GitHub issues, not the Fillout form:
    • Public and searchable.
    • Others can see existing bugs and comments.
    • Better for persistent, reproducible problems vs product feedback.
    • Should get better with Create and implement plan for users to easily file "FOC problems" tpm-utils#17
• Status & incident communication
  • Status page for critical outages.

Why Important

Different issues warrant different communication means. We want to make sure users know about the avenues available to them and what to use one.

User/Customer

Anyone seeking "support" with FOC (e.g., bug, getting stuck, wondering if service is down).

Notes

[rjan90]

Status & incident communication

• Status page for critical outages.

I think this part of the acceptance criteria is covered by the status-link on the website:

[rjan90]

PR #311 has been opened to address the remaining parts of this ticket.

Current status against the done criteria:

• Real-time help/chat: added clearer guidance pointing users to the #fil-foc channel on Filecoin Slack for “I’m stuck right now” troubleshooting.
• Bug reporting / persistent issues: added guidance pointing reproducible or persistent FOC problems to the public FilOzone/foc-problems GitHub issue form, rather than the Fillout feedback form.
• Status & incident communication: kept the existing status page link and added it into the same support guidance so users know to use it for outages or active incidents.

The PR also surfaces these paths in the homepage resource cards, not only in the FAQ.

Open question in the PR: the floating “Give feedback” button still points to the Fillout form. I think that may still be fine for general product feedback, but we should decide whether to clarify/rename it so users do not confuse product feedback with persistent bug/problem reporting.