Create and implement plan for users to easily file "FOC problems"

[BigLep]

Done Criteria

If a conversation moves beyond quick back and forth in #fil-foc, we want to have an easy way where FOC users can report problems (e.g., bug, something not working as expected). We don't want to lose track of the issue (hence the reason to have it in GitHub vs. slack) but there are also a lot of repos to navigate. As a result, lets have an easy dumping ground where a select set of people will triage (i.e., deduplicate, request more info, and move to the right place). This shared place should also request some of the right information up front (e.g., what version of synapse using, what SPs failed, what was the pieceCID).

The FilB feedback form (https://forms.fillout.com/t/2ZrChwnCqAus ) should also be updated to to link to this place/process for filing a bug or user problem.

Why Important

We want to remove any friction from customers helping us help them so they can be successful.

Notes

• I do think we should be lightweight and scrapy here, but lets also design this a little before we implement. I assume we're creating a new repo (e.g., foc-issues) but maybe we shouldn't be exposing GitHub as the primary interface for reporting? Maybe an AI chatbot interface would be more effective for gathering info and triaging...

[rjan90]

Suggested plan:

Make the primary intake a lightweight form, not GitHub directly. GitHub can be the triage/system-of-record layer, but the user-facing path can be low friction and structured info capture.

Proposal:

1. Create a private FilOzone/foc-problems triage repo.
2. Add a structured issue template there for internal/manual filing.
3. Create a feedback form to link users to a “report a FOC problem” flow.
4. Have form submissions create issues in the triage repo, with fields like:
   • product/component
   • user/contact
   • urgency/blocker status
   • Synapse/version info
   • expected vs actual behavior
   • repro steps
   • pieceCID / provider IDs / relevant job or deal IDs
   • logs/screenshots
   • Slack thread link, if the problem started in #fil-foc
5. We can then route the ticket accordingly, either transfer/create a sanitized issue in the destination repo and link back, or close the intake issue with the resolution/routing note.

[BigLep]

Thanks for proposing the plan @rjan90 .

One thought on the user-entry point: what are you thinking are the downside of using github's issue forms: https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms ? I guess the biggest issue is that everyone will be able to read everyone else's issues (i.e., there is no way to allow someone to create issues without also giving them the ability to read issues). That said, I wonder to start though how big of a deal that is. If it becomes an impediment, we maybe add a facade layer?

If you think we need a facade/non-github-entry to begin with, what are you thinking to use?

[rjan90]

Implemented the GitHub issue forms MVP path discussed above.

What is now in place:

• Created public intake repo: https://github.com/FilOzone/foc-problems
• Issues are enabled; wiki and discussions are disabled.
• Added a structured issue form for reporting FOC problems: https://github.com/FilOzone/foc-problems/issues/new/choose
• Added public-safety guidance so reporters do not include secrets, credentials, sensitive data, or security vulnerability details.
• Added a short triage runbook: https://github.com/FilOzone/foc-problems/blob/main/TRIAGE.md
• Added labels for needs-triage, needs-info, blocker, routed, duplicate, not-reproducible, out-of-scope, security-do-not-use, from-slack, and user-report.

This follows Steve's suggestion: start with GitHub issue forms as the user-entry point, keep the implementation lightweight, and only add a facade/non-GitHub form later if public visibility or GitHub friction becomes a real blocker.

Suggested next steps:

1. Update the FilB feedback form to link users to https://github.com/FilOzone/foc-problems/issues/new/choose for FOC problem reports.
2. Add the same link to the relevant #fil-foc Slack bookmark/topic or pinned guidance.
3. Run a short MVP pilot and watch whether public visibility or GitHub login requirements actually block useful reports.

[BigLep]

Nice work @rjan90 ! Looking good to me. A few miscellaneous things coming to mind:

• Do we want to auto-add these items to the FOC Board so we make sure they don't get missed?
• Alternatively or in addition to, I think having a weekly reporting of the "foc-problems" activitly in our weekly report will be key for making sure this doesn't fall through the cracks. I think we'll want to know in the last week:
  • What new came in?
  • What updates were made to issues in the last week?
  • (I assume scripting/AI can automate most of this.)
• For TRIAGE.md
  • If it's a duplicate, how about we use the "close as duplicate" functionality.
  • Maybe we make clear that we aren't tranfering issues out of foc-problems repo. Instead we create a new issue and formally add a relationship and then close the foc-problems issue?
• https://github.com/FilOzone/foc-problems/issues/new/choose lists two security report items
•