IUC tool or not?

[nomadscientist]

I want to predominantly use IUC tools, because they are sustained best by the community.
Determining whether a tool is an IUC tool or not is not trivial, however - there can be false positives if following a link to a toolshed, and also we should not have to follow a link to a toolshed.

Workflows have a nice IUC label on them, can tools?

xref https://matrix.to/#/%23galaxy-iuc_iuc%3Agitter.im/%24nz27FuLJn1HY3X4iYustDt5MjuB3F6eXqCaaKZAYpgo

[wm75]

I share your feeling about this to some extent, and if there was a nice way of identifying the repo owner quickly, that'd be an improvement. My favorite way of learning more about a tool would currently be "View tool source", which lists the toolshed address at the very top, which in turn contains the repo owner.

otoh, this is also simplifying things too much: there are definitely better and worse wrappers even among the iuc ones, and there can be very good wrappers that are not iuc ones.
imo, the training material, iwc WFs, and to some extent the Help forum are all better ways to learn about recommended tools than just relying on who wrote a wrapper, and eventually, a visit of the toolshed repo is necessary anyway for a full picture (like when has the wrapper been updated last time, where is the code getting developed if not in tools-iuc, etc.).

A good place for the owner and possibly other toolshed info could be next to the requirements, references and co section (currently at the bottom of the tool interface). And we should maybe discuss whether that section shouldn't be more discoverable.

[nomadscientist]

Ok, you've already helped me with the view tool source thing (although is that error prone?) because I didn't see the title above the actual source text, so had never noticed its home repo. Thank you!

[nomadscientist]

But yeah fair - either tool owner, or # of people who have committed to a tool, or latest date of tool release, or how often a tool has been updated, how often a tool has been run successfully vs errored out... these are all different metrics that could make it easier to distinguish good and bad tools. And therefore, for a user to figure out if it's their fault, or the tool's fault. But I don't know how much of this should be shown.

[nomadscientist]

It's already awesome that you can see at the bottom if it's in a tutorial or not, so perhaps that's the magic there

[nomadscientist]

Sometimes, when I'm looking for mini projects for undergrads / interns, I try and find tools that don't yet have a tutorial / workflow associated with them. However, it's then very hit-or-miss whether those tools work properly, and then whether they are IUC or not has a big impact - IUC tools, we can shout at all tool devs for help. When it's a single repo, you don't get that level of community support.

[nomadscientist]

^^But that's not a standard activity, so perhaps changing the UI to allow that use case is a bit much.