I guess from the thread here, maybe the way to go about it is to tackle it<br>
in different fronts:<br>
<br>
Knowledge Base<br>
Email Support for high touch problems (i.e. the cases we had with the<br>
corrupted wallets where arbitrators needed to manually sign multisigs)<br>
social media low touch problems.<br>
<br>
<br>
The KB functionality is currently done in github itself, but searching<br>
there is pretty annoying. Example: I had Brazilians with a problem and they<br>
found a solution, I couldn't find the tickets that described the initial<br>
problem and there was no place to publish it to live on (it became part of<br>
the workflow, then a bug fix and now will probably be fixed in the app) so<br>
we can point at it when the same issue appears again.<br>
<br>
KB usually converges into a wiki, which usually ends up being a ghost town.<br>
How can we prevent that?<br>
<br>
On Thu, 21 Nov 2019 at 08:27, Steve Jain <notifications@github.com> wrote:<br>
<br>
> From my research, it looks like there is no magic bullet solution. I<br>
> looked at a variety of privacy-focused services, and their support<br>
> solutions seem to vary quite a bit.<br>
><br>
> - Some use email, plain and simple. Many times, emails forward to a<br>
> back-end ticket manager.<br>
> - AirVPN appears to use its own forum-like format for tickets, where<br>
> each ticket is opened with a web form. Tickets are only visible to users<br>
> who open them.<br>
> - ProtonMail uses ZenDesk, where tickets are opened by a web form.<br>
> ProtonMail is transparent about this and also gives users the option<br>
> to email them for support <https://protonmail.com/support-form>, which<br>
> is nifty since all data would then remain in their (presumably) secure<br>
> email environment.<br>
> - Njalla <https://njal.la/contact/> offers encrypted email and XMPP<br>
> along with a web form and some kind of "support system" that I cannot see<br>
> because I don't have an account.<br>
><br>
> Special requirements for Bisq, as I see it:<br>
><br>
> -<br>
><br>
> Regardless of how support is "officially" handled, Bisq communication<br>
> platforms are destined to be disparate, especially as it grows around the<br>
> world, and people will inevitably reach out on all of them. Therefore any<br>
> solution will need to handle support requests coming in from a changing<br>
> array of channels. It seems to me that *a designated group of people<br>
> following a designated array of channels* (adjusted and adapted as the<br>
> user base changes) is the only way to conquer this. These people should<br>
> follow these channels, respond where possible, and redirect any unsolved<br>
> cases to the ticketing system.<br>
> -<br>
><br>
> Security and privacy requirements are high, so plain email won't work.<br>
> But not all users can be required to set up GPG keys to get support. Maybe<br>
> we offer Keybase as a more friendly fallback when secure communication is<br>
> required. Question is if/how Keybase can integrate with a ticketing<br>
> system...with email it's straightforward, but with Keybase it's not.<br>
><br>
> Ultimately, I see the solution being a combination of tools:<br>
><br>
> 1.<br>
><br>
> Informal replies/knowledge base. Designated group of 2-3 support<br>
> agents to watch Twitter, forum, Keybase, etc (exactly which ones need to be<br>
> discussed) and answer minor questions quickly and decisively. Refer users<br>
> to knowledge base where appropriate to avoid reinventing the wheel.<br>
> 2.<br>
><br>
> If support agents cannot resolve the issue in the channel, they should<br>
> suggest opening a support ticket. Exact flow for this would be determined<br>
> by ticketing software, but would ideally be through a web form where user<br>
> can detail problem as well as Keybase identity or GPG key for secure<br>
> response.<br>
><br>
> Support agents should correspond monthly to update the knowledge base so<br>
> it remains current and useful.<br>
><br>
> DAO elements of roles, bonds, etc would need to be determined too (as<br>
> Fabio mentioned above) since it seems these support agents would have<br>
> privileged access to the ticketing software.<br>
><br>
> I'm not sure there's a way to avoid that, unless mediators and/or<br>
> arbitrators were put in charge of handling tickets. Sounds far-fetched at<br>
> first, but might be doable if we can get on-the-ground support and<br>
> knowledge base really good...tickets should be relatively rare.<br>
><br>
> —<br>
> You are receiving this because you commented.<br>
> Reply to this email directly, view it on GitHub<br>
> <https://github.com/bisq-network/growth/issues/164?email_source=notifications&email_token=ABEY5S4WV6RGRV4VPR6L3L3QUYZ65A5CNFSM4JI45OZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEZHWWI#issuecomment-556956505>,<br>
> or unsubscribe<br>
> <https://github.com/notifications/unsubscribe-auth/ABEY5S5RZ4RIC3636JRIRBDQUYZ65ANCNFSM4JI45OZQ><br>
> .<br>
><br>
<br>
<br>
-- <br>
*Fábio Krauss Stabel*<br>
<br>
+45 93 93 21 31<br>
<br>
PGP keys<br>
<https://keys.mailvelope.com/pks/lookup?op=get&search=0xE5058064B3E7342F><br>
<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/bisq-network/growth/issues/164?email_source=notifications&email_token=AJFFTNQART7M5OMPMA7H7KDQUY7YFA5CNFSM4JI45OZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEZLKCA#issuecomment-556971272">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNQCESKJLG76WHBPXALQUY7YFANCNFSM4JI45OZQ">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AJFFTNVYPXXLH42RI7XPFH3QUY7YFA5CNFSM4JI45OZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEZLKCA.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/growth/issues/164?email_source=notifications\u0026email_token=AJFFTNQART7M5OMPMA7H7KDQUY7YFA5CNFSM4JI45OZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEZLKCA#issuecomment-556971272",
"url": "https://github.com/bisq-network/growth/issues/164?email_source=notifications\u0026email_token=AJFFTNQART7M5OMPMA7H7KDQUY7YFA5CNFSM4JI45OZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEZLKCA#issuecomment-556971272",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>