You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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:
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.
The text was updated successfully, but these errors were encountered: