Update user support section

[kabilar]

• In the last Scientific Core meeting, we discussed trying to funnel user support requests to GitHub Discussions, since emails are not publicly indexed. We decided that when a user sends us an email, we will ask them permission to convert it to a GitHub Discussion or Issue and continue the discussion there.
• This pull request changes our documentation to accompany the aforementioned change in the process flow.
• Pull requests to dandi/helpdesk and dandi/dandi-archive will follow.

cc @satra @yarikoptic @waxlamp

[CodyCBakerPhD]

Someone should really setup a deploy preview for these docs - I like the idea of having a dedicated top-level tab for 'Support' though

[yarikoptic]

Point to discussions?

[yarikoptic]

We also have discussions which is more prominently used than issues. It is a bit unclear what should be an issue vs discussion, what about:

Suggested change

	| ✨ [GitHub Issues](https://github.com/dandi/helpdesk/issues) | Report bugs and request features |
	| 🤔 [GitHub Discussions](https://github.com/dandi/helpdesk/discussions) | Ask questions and propose/discuss potential new features |
	| ✨ [GitHub Issues](https://github.com/dandi/helpdesk/issues) | Report bugs |

[h-mayorquin]

The link to discussions is on the top but I agree that maybe we can expand on what should go to each section.

Perhaps here we can clarify that issues are for infrastructure, technical and software errors and in the top add a bullet point with the list of things are welcomed in the discussions:

• I don't know how to do x.
• Does dandi support format y?
• I am getting an error when trying to upload my data.
• I have questions about the dandi archive
• Questions about embargo policy.

[CodyCBakerPhD]

Adding examples could be helpful as long as there aren't "too many" per section. Above all I think we should strive to keep things minimal since the docs are already overwhelming to many users

We can always (and often do) transfer issues to their appropriate destinations without the user needing to worry about that, too (which can inhibit willingness to raise out of concern of not raising in the right place)

[h-mayorquin]

I think 3 to 6 short bullet points as above can give a flavor of the type of questions that make sense for the help channel without being too many. The idea is to help the user orient themselves among the many available help channels. That is, to answer the question: where should I go with problem x.

I do agree that it can be overdone to the point of being intimidating rather than helpful. It is a fair point.

[kabilar]

Thanks @h-mayorquin, @CodyCBakerPhD. I agree with Cody and would prefer to keep things minimal here, and we can transfer as needed.

Regarding Where should I go with problem x?, I would say that everything should go to GitHub Discussions. And we can triage from there. So the user does not have to make any decision and can just post their question.

[h-mayorquin]

Makes sense.

[kabilar]

Point to discussions?

Hi @yarikoptic, I have a link to the discussions at the top of the page:

For questions and support, we recommend using GitHub Discussions 🙏

I was opting to take the user directly to the New Discussion button to reduce friction since https://github.com/dandi/helpdesk/discussions can be overwhelming for non-GitHub users.

[h-mayorquin]

LGTM

[yarikoptic]

Frankly, I would have preferred to keep that in the table. Placing it first and dedicated actually makes it less 'visible' since table is IMHO "more visible". But I do not feel strongly about that . So if you like it more like it is now -- fine with me.

[kabilar]

Frankly, I would have preferred to keep that in the table. Placing it first and dedicated actually makes it less 'visible' since table is IMHO "more visible". But I do not feel strongly about that . So if you like it more like it is now -- fine with me.

Thanks. That's fair. Let's keep it as is for now and if we get more Issues filed than Discussions then I will refactor.