Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

meta: Should we use the discussion forum for support requests? #7394

Open
cdecker opened this issue Jun 14, 2024 · 3 comments
Open

meta: Should we use the discussion forum for support requests? #7394

cdecker opened this issue Jun 14, 2024 · 3 comments
Assignees

Comments

@cdecker
Copy link
Member

cdecker commented Jun 14, 2024

We currently don't have a non-ephemeral medium for longer discussions and support inquiries, that don't have a well-defined start and end (i.e., pressing the Close button on an issue). We have several ephemeral ones in the form of chat rooms, but I'd like to de-emphasize those for longer support inquiries, as stitching together the context across days of scroll back is very painful, and it always feels awkward to ask users for information someone had already asked some days ago, but we simply didn't see it, and it's likely also very irritating for the users, as the feedback cycle is very long and winded.

The discussion feature on GitHub could be the canonical place for lengthy discussions, non-actionable support requests (i.e., those that don't end up becoming code changes), and maybe most importantly they are searchable, allowing users to self-diagnose and fix their issue if has already been discussed before.

However, it's yet another platform we add to our zoo. So I'd propose this structure for support:

  • Chats: quick one-off questions that likely can be resolved in a couple of minutes. If something becomes longer and tracking context becomes burdensome, move.over to discussions, by summarizing the chats that have happened so far.
  • Discussion: anything that doesn't have a well-defined start and end, where keeping context is useful, and searchability is helpful for users to get a quick solution.
  • Issues: actual issues that will eventually end up becoming code changes. This can be feature requests (maybe after discussing whether they are sensible first) and bugs that need to be addressed

Distinguishing the discussion from issues can be tricky, since we exit very loudly when operator intervention is required (can't sync blocks, connection loss due to protocol violations by the peer, ...) and these look a lot like crashes due to the traceback. It'd be the maintainers job to direct users to the correct place for their request.

I myself am worried about having to monitor an additional place, but can see the usefulness, and so I wanted to ask the community whether this makes sense before diving in 😊

⏩ In order to keep an overview of sentiment, please 👍 or 👎 on this post.

@cdecker cdecker self-assigned this Jun 14, 2024
@cdecker
Copy link
Member Author

cdecker commented Jun 14, 2024

And yes, I'm aware of the irony of posting a metà discussion on the issue tracker, but this also highlights the need for a non-ephemeral platform for these kinds of discussion.

@cdecker
Copy link
Member Author

cdecker commented Jun 14, 2024

One more thing, regarding the non-well-defined start and end of this "discussion", I will close this issue 7 days from opening and tally the votes.

@cdecker
Copy link
Member Author

cdecker commented Jun 23, 2024

Ok, looks like we have a quorum to enable the discussions feature. I will do that tomorrow, and start setting up a couple of categories, taking inspiration from the Discord room structure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant