[WIP] User support

[oscarguindzberg]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

Problem

When a user creates a support issue, the developer providing support has 2 goals in mind:

1. Help the user solve her problem.
2. Prevent other users from facing the same problem.

Sometimes both goals are achieved by doing just one task, e.g. solving the bug. Sometimes there is a quick workaround for the user but the bug is difficult to reproduce/fix.

Then, there are some other challenges:

• Developers tend to help user use a workaround (e.g. do a restore from seed for a corrupted wallet) and skip finding the bug that caused the problem. Developers are reluctant to try to find the bug that caused user problem because many times it is a dead end or it can take a huge effort to reproduce the bug.
  • Eg Withdrawal not propagating, funds not accessable per cmd-e bisq#2778
• User bug report is generally not exhaustive: they usually write something like “I have a problem buying bitcoin” while the developer expects a step-by-step list of what they did and what they got, the logs, the bisq version she is using, etc.
• The user is just interested in getting her problem solved and sometimes are not very eager to cooperate to fix the bug.
• On most cases, the user takes hours/days to reply and the developer can’t talk to the user over the phone.
• The user usually reports the problem after trying several times, that makes it difficult to find the original cause.
• There are plenty of things logged as ERROR on the logs. Most of them are not real errors (mostly connection problems), which makes it hard to discover the real errors.
• Full stack trace not always present in the logs.
  • Sometimes the full stack trace is not present on the logs because code like this is used:
    • e.printStackTrace() - prints to the console, not the log file.
    • throw new CryptoException("Signature verification failed" + e.getMessage()) - just prints the original message, not the stack trace.
• Some developers are specialists in some part of bisq and don't know how the rest of the app works so it is difficult to solve bugs that are outside their domain.
• User confidential information. The developer might need the latest few lines of the user log, the entire user log and/or the user's bisq data dir to reproduce the bug. Sharing that info means to the user exposing her privacy.

Proposals

• Create issue templates for user bugs - similar to the ones used in the support github project (See https://github.com/bisq-network/support/issues/new?assignees=&labels=&template=reimbursement-template.md&title=Fee+reimbursement+for+trade+XXXXX).
• The developer should not provide the user a workaround until the user has provided the developer all the information needed to reproduce the bug.
• Improve the log
  • Replace log.error() by log.warn() for connectivity problems that are not bugs.
  • Replace e.printStackTrace() by log.warn("Some text", e).
  • Replace throw new SomeException("Some text" + e.getMessage()) by throw new SomeException("Some text", e)
• Design a procedure for devs to get help from other devs when solving issues.
• Design a procedure for user sending confidential information. Here is an idea: User uploads to dropbox (or any other app) the last few line of the logs, the entire logs and/or the bisq data dir and sends an email to the developer working on the case with a link to the confidential information. User should be able to distinguish a real developer vs a fake one just trying to get user’s private data. User is still exposing private info to the developer. Developer should help the user withdraw her btc balance before doing that. Problem: BSQ balance can not be withdrawn.
• Have support layers.
  • Level 1
    • Helps the user if the problem is not a bug but the user does not know how to use bisq.
    • Otherwise, helps the user to complete the issue in a more thorough way and assigns the issue to the relevant developer.
  • Level 2
    • Developers with experience in some bisq areas investigate and fix the bug.
• Design clear compensation incentives for different support tasks.
  • Providing a workaround to the user.
  • Investigating the issue but not being able to reproduce the bug.
  • Investigating the issue and being able to reproduce the bug and document it.
  • Fixing the bug.

[devinbileck]

Create issue templates for user bugs

Absolutely agree!

The developer should not provide the user a workaround until the user has provided the developer all the information needed to reproduce the bug.

While I agree it is ideal to get as much information while the application is exhibiting symptoms of the issue, we can't block the user from using the application. Yes the first step should be to request for additional details if necessary, but if they are unable (or unwilling) and there is a workaround, we should be able to provide it.

Improve the log

Agreed!

Design a procedure for devs to get help from other devs when solving issues.

I find slack is sufficient for communicating with other devs and asking for help, as long as you are asking the right person (or the right person sees the message). But perhaps we need to publish the areas of expertise of each dev to determine who to contact? As we are a fairly small group currently, it is fairly easy to remember who is familiar with what, but that could change in the future.

Design a procedure for user sending confidential information.

I agree in some situations this may be necessary, but hopefully only as a last resort after all other attempts to reproduce the issue are unsuccessful and only if the user is willing to help identify/resolve the issue. And as long as the user fully understands what they are handing over. And perhaps inform them which sensitive information to remove from the log before sending it over, if they are concerned.

[MwithM]

Closing as superseeded, although parts of this proposal have been implemented (support template), others have been superseeded (improve support) and others remain stalled.