[EGD 2023 Cofest] Galaxy help forum integration

[ElectronicBlueberry]

Adds relevant posts from the Galaxy Help forum to the tool form.

Pressing "ask a new question" pre-fills the title and tags with the tools name and id respectively.

Thanks to @nomadscientist for her input and feedback!

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[lldelisle]

Would be super great. Thanks for the PR.

[wm75]

@bgruening suggested some tag-based filtering. Not every thread in the help forum is of high quality and Galaxy tool related - your screenshot is, in fact, a case where the thread is not about the Galaxy, but the command-line tool.

If help forum members with the right to add tags would be trained to use a tool-help (or some other agreed upon name) tag, we could filter out a lot of noise/spam.

[martenson]

@wm75 whoever wants to have permissions to do this and does not have it yet please let me know your GHelp username

edit: the post created by this integration could likely also benefit from having the tool-help tag that Wolfgang mentioned

[bgruening]

@martenson maybe you can help us here. What concept can we use in GHelp that allows moderators to "mark" a question as good, that can not be done by users, only moderators. I understood that tags can be used by users, so they are not helpful.

[martenson]

@bgruening Not much afaik, mostly tags and category come to mind as tools for this and they are both user-editable. However I wouldn't be discouraged by that as I expect the exploitation rate would be low.

details
https://meta.discourse.org/t/understanding-user-statuses-roles-and-permissions/35171
https://meta.discourse.org/t/trust-level-permissions-table-inc-moderator-roles/224824
https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/

[bgruening]

Ok, good to know. They we go via tags I guess.

[wm75]

iiuc, then users can also only set a tag when they create a topic or as long as they can edit their post?
If that's so (it's just my vague understanding of the docs), then at least moderators can correct stuff eventually.

[ElectronicBlueberry]

The Help Forum section now only shows topics containing both a tag with the tools id, and a "tool-help" tag.
Pressing "Ask a new question" will add these tags

[bgruening]

Pressing "Ask a new question" will add these tags

I would not add the "tool-help" when you press this button. I think the curator should add this tag, at least for the start and see how it goes. I would only show this button for registered users.

[bgruening]

Maybe I'm a bit overprotective here... I don't know.

[ElectronicBlueberry]

Both of these approaches offer little security benefits at the cost of a worse user experience. Sacrificing UX for security can be worth it, but I do not think the trad-off is warranted here.

My thoughts on these approaches are as follows:

Not adding the tag

UX impact

This would add an additional maintenance burden onto the help forum curators, and is a step which could be forgotten, causing some useful questions to potentially never show up in the tool form. Additionally users may be confused by their questions not showing up on the tool, and may think this is due to a slow/faulty system, or that their question has been removed.

Security Benefit

The security benefit is minimal, since bad actors can add this tag manually during post creation.

Hiding the new question button

UX impact

Having divergent UIs for logged in and anonymous users leads to confusion, as seen in #10418
This could be solved in the same manner as #14419, by greying the button out and requiring a log-in, but this would exacerbate the second UX issue:

Since the galaxy help forum has it's own account system, we are then requesting from a user to log in twice to use this feature, and in the worst case, to create two accounts, while only one is needed. It is a frustrating user experience to be asked to log in/create an account to access a feature, just to have to do it again.

Hiding / disabling the button would also decrease this features advertising effect for the help forum.

Security Benefit

The security benefit is minimal, because the button is just a link to the help forum. Bad actors can circumvent it by posting to the help forum directly.

[bgruening]

Hiding the new question button

True, I forgot that you either way need to login.

UX impact
This would add an additional maintenance burden onto the help forum curators, and is a step which could be forgotten, causing some useful questions to potentially never show up in the tool form. Additionally users may be confused by their questions not showing up on the tool, and may think this is due to a slow/faulty system, or that their question has been removed.

A question needs to be answered to be useful, so there is always a burden by the community and the topic maintainers of the help forum. Adding the correct tags is already done by topic maintainers to keep the questions organised and useful.
I don't think its a good idea to show questions in the tool form by default without any curations. Duplicates, questions with wrong answers or without answers will be shown. I don't think that is desireable, its degrading UX and expecation of a user from this features will not be meet - that is my fear.
I agree that the additional tag is not safe - see above - we haven't found a better way at the moment how we can "mark" a questions as "tool-form-compatible". If we would have a better way we should not use tags. Until then I would be fine to use "tool-help" (after curation) and see if this gets abused actively.

[wm75]

@bgruening's "needs to have a useful answer" argument is the most important one I'd say.
Ideally this new part of the tool interface would be more like a curated faqs section and less like a timeline of every post that has ever mentioned the tool. Even if we miss some useful topics with a good answer that way, it's still better than now as long as we manage to tag a few things correctly.
As a compromise, maybe, underneath the suggested, tagged topics we could have a link saying sth like "Alternatively, you may want to view all Galaxy help forum topics that mention {toolName}"? that takes you to the search results page of the help forum?
Regarding just using toolName there, there is the additional problem of sometimes very short tool names, like "Compute", "Cut", etc., which really don't produce very tailored search results. Maybe we should at least detect cases where the tool name is a single word without interior caps (Replace, Compute, Concatenate, but not MultiQC) and append the tool description (or parts of it, if that's very long) to the search term? For example, "Compute" is almost always called "Compute on rows" when talking about it, and we use "Replace parts of text" to distinguish this tool from all the other Replace tools.

---

Having the link there for anonymous Galaxy users seems just fine since, as you're saying @ElectronicBlueberry, it's just a link to the help forum with it's own account system and all.

---

I'm not that convinced of using the tool id as a tag. That's easy to do from Galaxy of course, but for other questions this does increase the burden on help forum members because they now need to look up the tool id every time they want to tag a topic as relevant for a tool's help.

[ElectronicBlueberry]

Update after some async discussion:

Searching for tools by means other than the tool_id is not viable, as tool names can be strange, or overlap with other tools in unforeseen ways. While this does add an maintenance burden, tagging tool questions with tool ids can be useful for more than this feature in the future so it may well be worth doing anyways.

Additionally only solved topics will now be shown. This makes the section on the tool form very curated, as three criteria need to be met for a topic to appear in the galaxy UI:

• a tag matching the tool id needs to be present
• a tag called "tool-help" needs to be present
• the topic/question needs to be solved

This way, if an answer is outdated, removing the "tool-help" tag will hide the topic from the tool form, allowing for better answer curation. Only showing questions which were solved also helps users more. Finally, requiring the tool_id in the tags guarantees that all the topics shown are relevant to the tool in question.

[davelopez]

This way, if an answer is outdated, removing the "tool-help" tag will hide the topic from the tool form, allowing for better answer curation. Only showing questions which were solved also helps users more. Finally, requiring the tool_id in the tags guarantees that all the topics shown are relevant to the tool in question.

Thank you for giving more thought to it! I think this is a great solution with the tools that we have (no pun intended) 😆

[hechth]

Hi all - I can leave my 2cents here.

For the tool tagging - I'd rather see EDAM ontology topics or operations used as tags than the tool id - plenty of tools come as suites where you would want to have the same tag on the Help forum. Also, scientifically close topics should be in the same category - hence the EDAM annotations. Of course the problem with that is that almost no tools have EDAM annotations - but this would also reduce the forum integration to the tools about which people actually care (hopefully - correct me if you think I'm wrong).

Also, should all questions be displayed? If so, I'd vote against that - this would make the tool form awfully long and I think having like max 5 questions displayed or so would be good. Can even be the most recent ones I think - this would also show people if some bug is already known and they get already directed to that question.

[ElectronicBlueberry]

In this features current state, it displays the 5 newest, solved topics.

Regarding questions which are relevant to more than one tool: Several tool_ids can be added to a discourse topic, and it will show up in all tagged tool forms once it is solved.

I do not think searching via EDAM is a good idea, as like you already mentioned, many tools lack EDAM annotations. In addition I fear that it may clutter some tools with questions which are not helpful, because a tool-specific question was asked for a different tool with the same EDAM topic / operation. Adding EDAM topics / operations as tags to tools may still be useful though, and is something that can be added to the "Ask a new question" button, though I'd like to hear some more feedback on that idea before adding it to this feature.

[dannon]

LGTM in terms of integration, especially considering it's opt-in. Test failures unrelated. Thanks for taking care of the rebase/rebuild of the schema.

My one concern here is that, even with the tool form feature off (which it is by default) the internal search API is exposed and has a default target configuration -- so someone could potentially spam searches the default configured help server (which again, is us by default and maybe not a big deal). Might be a more cautious approach to just no-op/error that API endpoint if the search integration isn't enabled on the server?

[davelopez]

Might be a more cautious approach to just no-op/error that API endpoint if the search integration isn't enabled on the server?

Good point, I can push that change to the API if you are not already on it @ElectronicBlueberry

[ElectronicBlueberry]

Good point, I can push that change to the API if you are not already on it @ElectronicBlueberry

I am not, go ahead

[dannon]

Test failure unrelated to David's latest tweak and it passed before. Going to get this in, thanks everyone!

[github-actions]

This PR was merged without a "kind/" label, please correct.

[jennaj]

Hi @ElectronicBlueberry See this is merged but not sure where to tell people (and you!) about this or discuss it more on the practical side .. but I've been writing up more "complete" and updated replies at the Ghelp forum ...and for a few, I think they are good for the tool-help tag, so I've added that tag. You can search and see if those are what you want or not, and I'll do more.

And, I think once we have more tagged, I can create a separate "read-only" category to group these directly at the forum, too. A type of browsable listing of topics promoted to the cross-link into tool forms, all in one place. I have another dedicated category I'm using for this but we can merge it all together.

FWIW -- the best place to reach me is on our lab Slack! I can miss Github/Matrix pings. I couldn't find your handle there but maybe you can find me :)

[bgruening]

Awesome thanks a lot @jennaj!

[jennaj]

Update: I have seen what look to me like new cross posts to the forum from tool forms! Whoop!

Here is a newer question with an answer marked as solved. I had to add in the tool_id as a tag. I suspect the creation of new tags for the tool_id part is not quite working yet -- we could discuss why -- probably permissions issue we can solve.

Seems to be working!! <3

https://help.galaxyproject.org/t/customprodb-troubleshooting/12173